GitLab 的 AI Gateway 让精心构造的 Flow 配置突破其提示沙箱

2026 年 10 月 2 日，GitLab 为其 AI Gateway 发布了一个关键补丁版本——该中间件负责在 GitLab 实例与其 Duo 功能所调用的语言模型之间传递请求——并将CVE-2026-90970评为 10 分制中的 9.9 分。用 GitLab 自己的话说，该漏洞可能允许“拥有 Duo Agent Platform 访问权限的已认证用户通过特制的流程配置逃逸提示词模板沙箱，从而在 AI Gateway 上执行任意命令”。只有运行自托管 AI Gateway 的组织需要采取行动：GitLab 已经修复了其为 GitLab.com、GitLab Dedicated 以及使用 GitLab 托管网关的自管理客户所运营的网关，并在公告中说明了这一点。GitLab 的公告没有说明该漏洞曾被利用，而美国网络安全和基础设施安全局同日附在 CVE 记录上的评估将利用情况列为“无”。该发现归功于 HackerOne 上名为 invisiblemeerkat 的研究人员。 GitLab 的公告、NVD 记录以及随后发布的报道，在漏洞是什么以及哪些版本包含该漏洞方面彼此一致；对于未知事项也同样一致，即是否曾有人利用过该漏洞。该记录与AI 事件档案中其他有记录的智能体基础设施漏洞并列，其中每条记录都带有各自的来源、严重性、置信度等级和争议标记。

这份公告实际说了什么，又省略了什么

该安全公告很短。它发布在 GitLab 文档网站上，标题为“GitLab AI Gateway 关键补丁发布：19.2.4、19.3.2 和 19.4.1”，其中列出了一项安全修复，标题为“自定义流程提示模板中的不当中和问题影响 AI Gateway”，并标记为“严重”。公告给出的 CVSS 3.1 向量为 AV:N/AC:L/PR:L/UI:N/S:C/C:H/I:H/A:H——网络可达、攻击复杂度低、所需权限低、无需用户交互、范围变更，并且对机密性、完整性和可用性均有高影响。这个向量值得一读，因为它准确说明了攻击者的情况：权限虽低，但终究是权限。公告称“具有 Duo Agent Platform 访问权限的已认证用户”，然后就戛然而止。它没有说明角色、权限，也没有说明其自身所说的“在某些条件下”指的是哪些条件。

它没有发布概念验证，没有描述精心构造的流配置，也没有为无法立即更新的网关提供变通方案。The Hacker News 在10月2日的报道中指出同样存在这些缺失，并补充了一项在运维层面至关重要的缺失：该安全公告没有提供任何方法来检查网关在被打补丁之前是否遭到攻击。Security Affairs 在次日撰文记录了同样的空白。

该 CVE 所附的通用弱点枚举条目是CWE-1336，即模板引擎中所用特殊元素的中和处理不当。GitLab 的公告从未使用 Jinja 一词。但 AI Gateway 自己的仓库文档却用了这个词：其提示注册表文档描述了提示配置文件，“支持面向用户和系统等多个角色的 Jinja 表达式”，并描述了一个 Prompt 类，“使用 Jinja 以输入参数对提示模板进行插值”。该 CVE 所描述的缺口，正是这类引擎广为人知的问题——用户提供的文本进入了会被求值而不是被打印的模板。

为什么这台特定主机上的某个命令值 9.9

AI Gateway 并不是一个边车（sidecar）组件。根据 GitLab 的自托管文档，它接收来自 GitLab 的请求、组装提示词，并与模型后端通信——后者可以是 vLLM 服务器、A​mazon Bedrock、Azure O​penAI 或外部提供商——而在完全自托管的部署中，正是它让提示词和响应始终留在组织自己的网络之内。GitLab 的 AI Gateway 安装指南还指示管理员生成一对签名密钥，并把这两部分作为环境变量传给该服务，即 AIGW_SELF_SIGNED_JWT__SIGNING_KEY 和 AIGW_SELF_SIGNED_JWT__VALIDATION_KEY（Duo Workflow 也有对应的变量）。Security Affairs 明确道出了其后果：一旦在网关上实现命令执行，攻击者就会落入一台同时存放着 JWT 签名材料、并处于 GitLab 实例与模型基础设施之间路径上的主机。

这就是玩具项目中的沙箱逃逸与生产环境中的沙箱逃逸之间的区别。逃逸不需要触及模型；它需要触及持有用于对模型调用进行签名的密钥的进程。

GitLab 的产品文档（与安全公告分开）指出，在管理项目中创建或编辑自定义流程需要 Maintainer 或 Owner 角色，而运行该流程需要 Developer 或更高角色。该安全公告并未确认这一对应关系，The Hacker News 也指出，除“Duo Agent Platform access”外并未提及任何具体角色。读者在评估自身暴露风险时，应将产品文档视为该产品的权限模型，并将安全公告的沉默就当作沉默本身：这不是矛盾。

已建立，以及未建立

记录自身的字段与上述所有内容保持一致，且没有添加任何公告之外的信息。以下内容是读者无法从一行摘要中得到的细分。

• 已确认：GitLab AI Gateway 中存在一个严重级别漏洞，于 2026 年 10 月 2 日披露，CVSS 9.9，CWE-1336；经过身份验证的 Duo Agent Platform 用户可通过特制的流程配置触达该漏洞，最终导致在网关主机上执行命令。

• 已确定：受影响范围——所有 AI Gateway 版本：18.1.6 起至 19.2.4 之前、19.3 起至 19.3.2 之前，以及 19.4 起至 19.4.1 之前——以及修复版本 19.2.4、19.3.2 和 19.4.1。

• 已确认：GitLab 托管的网关已在发布前完成修补，其客户无需采取任何行动；自托管运营方已在发布文章前被直接联系，GitLab 在公告中对此作出了说明。

• 已确认： 报告者署名归功于 invisiblemeerkat，且没有任何在野利用的声明。

• 尚未确定：是否有人利用了该漏洞。NVD 记录中可见一份日期为 2026 年 10 月 2 日的 CISA SSVC 评估，其中将利用状态评为“无”，可自动化性评为“否”，技术影响评为“完全”；在我直接核查过的 CISA 已知被利用漏洞目录 2026 年 10 月 20 日修订版中，并未列出 CVE-2026-90970。FIRST 的 EPSS 模型在 2026 年 10 月 21 日给出的未来 30 天内被利用概率为 0.94%——很低，但并非为零。

• 尚未确定：存在多少个自托管网关、其中多少个曾被暴露，或在打补丁之前是否有任何网关遭到攻击。本记录中没有任何来源给出数量，且 GitLab 的公告未提供检测方法。

受影响的范围，以及未列出修复的版本

版本号的计算并不像三个已修复版本所显示的那样整齐。受影响范围从 18.1.6 开始，而在低于 19.2.4 的任何版本线上都没有发布修复版本。因此，从 18.1.6 到 19.1 系列的所有网关都处在所述受影响范围内，却没有为其指定任何修补版本。Hacker News 指出了同样的后果以及随之而来的问题：GitLab 的安装文档要求管理员运行版本与其 GitLab 次版本相匹配的网关镜像，而公告既没有说明 19.2.4 网关能否用于 GitLab 19.1 或更早版本，也没有说明是否计划为较旧版本线提供修复。正如 The Hacker News 所指出的，GitLab 的支持版本政策目前列出 19.4、19.3 和 19.2——正是获得修复的同样三条版本线。

修复方式是更换容器，而不是打补丁：网关以独立的 Docker 镜像或 Helm chart 形式发布。GitLab 的安装指南描述了停止并删除正在运行的容器、拉取带有 self-hosted-vX.Y.Z-ee 标签的新镜像，并在环境变量保持不变的情况下重新启动它；Helm 部署则在 chart 的 image 字段中设置该标签。安全公告和安装指南均未提供可用于区分受攻击网关与干净网关的签名或指示符。

同一类缺陷，八个月前

这并非 GitLab 首次在 AI Gateway 中针对模板注入发布 9.9 分漏洞。2026 年 2 月 6 日，它针对 CVE-2026-1868 发布了 AI Gateway 18.6.2、18.7.1 和 18.8.1；该公告将其描述为“不安全的模板展开问题”，其中 Duo Workflow Service 组件“容易因特制的 Duo Agent Platform Flow 定义而对用户提供的数据进行不安全的模板展开”，可用于在网关上造成拒绝服务或执行代码。其 CVSS 向量与 10 月那个逐字符完全相同，CWE 也是如此。报告者不同：那个是由 GitLab 团队成员 Joern Schneeweisz 内部发现的。

10月的公告没有提到2月的那份，而The Hacker News明确指出了这一点。这两者是否共享同一个根本原因、同一个未能持续奏效的修复，还是仅仅共享一种语言和一种威胁模型，这两份公开文件都没有回答。有记录在案的是，AI中间件组件中的某个模板引擎如今已在同一年以相同评分产生了两份严重的命令执行公告，而且第二份还需要由外部研究人员发现。

发生了哪些变化，以及运营方还有哪些事项需要决定

具体改动是三个镜像标签和一轮直接外联。GitLab 表示，它在发布前已联系了自托管网关客户，并且安全公告与修复后的镜像在同一天发布。对于其他所有用户——GitLab.com、GitLab Dedicated，以及指向 GitLab 托管网关的自管理实例——修复已在服务器端应用，而且按 GitLab 的说法，无需采取任何操作。

对于自托管运维人员来说，这一决定比常规补丁周期更狭窄，也更不轻松。对于无法立即迁移的网关，没有变通办法。目前也没有已发布的方法可以确定主机此前是否已被攻陷，这意味着唯一的事后选择就是常规做法：将容器视为完整性未经证实的系统，并寻找其正常行为之外的执行迹象。而对于运行 18.x 或 19.1 的网关，公告完全没有指明目标版本——The Hacker News 报道了这一遗漏，而 GitLab 的通知并未对此作出说明。

该档案自身的分类刻意比供应商的分类更窄。它把该条目记为漏洞，置信度为 A，各来源说法一致、无争议，未记录任何实际危害，严重性字段为“high”，而 GitLab 和 NVD 的评级为“critical”。这些回答的是不同的问题：评分描述的是该缺陷可能造成什么，而档案的评级描述的是已知实际发生了什么。就公开记录而言，什么都没发生——没有遭利用，没有受害者，没有事件报告。该条目的价值在于，它以 CVE 编号和修复版本，确切记录了一个提示模板究竟是如何在企业 AI 功能所依赖的中间件中变成一条命令行的。