GitLab AI Gateway 漏洞突破沙箱并实现命令执行

研究人员发现了一条通往任意命令执行的路径后，GitLab 已修复一个评分为 9.9（满分 10 分）的 GitLab AI Gateway 漏洞。该缺陷影响自托管网关，攻击者须是已通过身份验证且拥有 GitLab Duo Agent Platform 访问权限的用户。特制的自定义流程可逃逸提示词模板沙箱，并以网关进程的权限运行命令。

这起事件的影响范围比可远程利用、影响所有 GitLab 部署的漏洞更为有限。GitLab 托管的网关已由公司完成修补，使用这些服务的客户无需自行更新网关。运行自托管 AI Gateway 的组织则需立即承担修补责任。

这一差异构成了核心矛盾。自托管让组织能更好地控制 AI 处理、基础设施和数据路径，同时也将补丁管理、监控和遏制责任转移给客户。在本案中，部署在可信环境内的组件成为了命令执行的攻击目标。

该漏洞编号为 CVE-2026-90970。GitLab 于 2026 年 10 月 2 日发布了 AI Gateway 19.2.4、19.3.2 和 19.4.1 版本。公司敦促受影响的运营方立即更新，但其公开公告未说明缓解措施，也未提供详细的入侵检测指引。

GitLab AI Gateway 漏洞需要立即更新

紧急情况很简单：受影响的自托管网关需要升级至已修补的 AI Gateway 版本，而不只是更新 GitLab 应用程序。

GitLab 的关键补丁公告列出了三个已修复版本：19.2.4、19.3.2 和 19.4.1。相关版本号属于 AI Gateway 组件，不应与所连接 GitLab 实例的版本混淆。

受影响范围始于 AI Gateway 18.1.6，包括早于 19.2.4 的版本、19.3.2 之前的 19.3 版本，以及 19.4.1 之前的 19.4 版本。运行较旧受支持分支的组织必须选择相应的已修补版本。

对于使用 18.x 和 19.1 系列版本的安装环境，公告措辞同样值得注意。GitLab 在 10 月公告中未列出低于 19.2.4 的已修复网关版本。运营方不应认为继续使用较旧分支就能获得保护。

自托管 AI Gateway 作为独立服务运行，通常通过容器或 Helm 部署。更新主 GitLab 应用程序并不能自动证明网关镜像已被替换。管理员必须检查网关部署本身，并确认其正在运行的镜像标签。

GitLab 表示，其在发布公告前已联系自托管网关客户。公司还称，修复已部署至 GitLab 托管网关。这保护了 GitLab.com、GitLab Dedicated，以及连接到 GitLab 托管网关的自管理实例。

这一范围使资产识别成为首要运营挑战。安全团队可能知道组织在使用 GitLab Duo，却不知道其采用的是哪种网关模式。该服务既可由 GitLab 运营，也可部署在客户环境中。

团队应通过部署记录、容器清单、Helm 版本和 GitLab Duo 配置来核实这一差异。不应仅凭 GitLab 产品名称推断网关所有权。自管理 GitLab 实例仍可能使用 GitLab 托管网关。

CVE 记录在其 CVSS 3.1 向量中，将该漏洞的机密性、完整性和可用性影响均评为最高等级。其评分为 9.9 而非 10，是因为利用需要低权限。攻击不需要用户交互，且易受攻击服务可通过网络访问。

低权限并不意味着无需身份验证。GitLab 表示，攻击者必须已通过身份验证，并拥有 Duo Agent Platform 访问权限。这一要求缩小了初始攻击者范围，但其中包括被攻陷的账户以及潜在的恶意内部人员。

该缺陷在完成初始访问后跨越了安全边界。获准使用 AI 流程的用户不应因此获得在网关上执行操作系统命令的权限。该漏洞将应用层访问转变为对更敏感执行环境的控制。

运营方应将更新视为一项独立变更，并保留独立证据。GitLab 的变更工单已完成，并不能证明 AI Gateway 是安全的。正确的证据应是正在运行的网关版本，以及所有副本均已完成验证的部署。

验证还应覆盖开发、预发布、灾难恢复和临时缩容环境。只要保留网络连接或凭据，被遗忘的网关实例仍然重要。不活跃的接口并不保证服务无法访问。

自定义流程将模板数据变成可执行行为

核心问题并非 AI 模型写出了危险命令，而是模板边界允许精心构造的数据进入可执行的应用程序行为。

GitLab 将该问题描述为自定义流程提示词模板中的不当中和处理。自定义流程是 Duo Agent Platform 内可配置的多步骤 AI 工作流。它可以在 YAML 定义中组合提示词、组件、路由决策和工具。

该公司的自定义流程文档说明，这些定义不只是普通的提示词文本。流程可被创建、测试、发布、为项目启用，并通过 GitLab 活动触发。它们作为围绕代理的应用配置运行。

易受攻击路径涉及提示词模板沙箱。沙箱是一个受限执行环境，旨在防止模板访问不安全的属性或函数。CVE-2026-90970 允许精心构造的流程配置逃逸这些限制。

一份公开的 GitLab 披露工单将问题归因于 Jinja2 模板渲染期间的不安全方法访问。Jinja2 是一种将文本与变量和表达式结合使用的 Python 模板引擎。

根据该工单，对话历史中包含一个 LangChain HumanMessage 对象。模板可以调用该对象上的公共反序列化方法。随后，不安全的序列化载荷会在反序列化期间导致 Python 执行操作系统命令。

反序列化会将存储或传输的数据转换回程序对象。当所选格式能够在重建对象时调用代码，反序列化便会变得危险。Python pickle 数据是一个众所周知的例子，因为加载不可信的 pickle 内容并不安全。

据报告，概念验证使用了一个两步流程。第一次模型交互填充对话历史；后续模板求值则访问该历史对象，并触发危险的反序列化路径。

这一过程使该问题不同于基本的 Shell 注入漏洞。恶意值无需作为直接命令参数传递给 Shell，而是由多项本身各具意义的功能共同构成了执行链。

该流程接受可配置的提示词内容。模板引擎接收应用程序对象。其中一个对象暴露了反序列化方法；被接受的序列化格式可调用代码。这些条件共同击穿了原本预期的沙箱。

模型本身并非可信安全边界。它有助于推动流程在不同状态之间流转，但命令是通过确定性的应用程序行为执行的。仅过滤模型输出无法解决易受攻击的对象与模板关系。

这一差异对于组织对 AI 安全故障进行分类至关重要。提示词注入描述的是通过指令操纵模型的尝试。CVE-2026-90970 则是模型周边系统中的软件漏洞，尽管提示词模板提供了入口。

因此，传统应用安全实践仍然不可或缺。模板输入需要严格验证，暴露的对象应仅提供最小接口，危险的反序列化格式不应处理攻击者可控的数据。沙箱还需要针对其中可用的确切对象进行测试。

据报告，相关命令以 Duo Workflow Service 进程的权限运行。这将即时的操作系统权限限制在服务账户权限范围内。然而，服务层面的执行仍然严重，因为网关处理敏感连接，并位于可信基础设施之中。

实际影响取决于部署架构。采用最小权限、网络受限的容器，比广泛连接的服务拥有更少的后续攻击路径。但两种配置都无法消除修补需求，因为攻击者仍会获得非预期的代码执行能力。

这一机制解释了其接近最高的严重性。攻击者以已通过身份验证、具备 Duo 能力的身份开始，但最终执行会跨入网关的安全上下文。这一权限范围变化是 9.9 评分的核心原因。

自托管将控制权与安全责任一并转移

这起事件揭示了自托管 AI 基础设施背后的权衡：将处理留在近处，也意味着将网关置于客户的运营信任边界内。

GitLab 将 AI Gateway 描述为一项独立服务，用于连接 GitLab Duo 功能和 AI 模型。客户可以使用 GitLab 的托管网关，也可以借助 GitLab Duo Self-Hosted 运行自己的网关。

组织通常选择自托管，以控制数据流动、模型访问、网络路由和基础设施策略。这些优势在受监管环境或具有严格内部控制的部署中可能十分重要。但它们也增加了一项需要客户清点和维护的生产服务。

GitLab AI Gateway 漏洞将这一运营细节转化为主要安全问题。GitLab 可以直接向其管理的网关部署修复程序；自托管客户则必须自行安排、执行和验证升级。

这种模式在数据库、身份服务和 CI 运行器中很常见。不同之处在于，AI 网关连接了过去界限更清晰的系统。它们位于用户、源代码仓库、代理工作流、模型提供商，以及有时的执行工具之间。

因此，遭入侵的网关值得比孤立的聊天机器人界面获得更多关注。根据配置不同，它可能接触提示词内容、工作流状态、服务凭据、提供商连接，或内部开发活动的元数据。

这并不能证明 CVE-2026-90970 暴露了所有已连接的机密信息。GitLab 的公告没有报告已确认的数据窃取或完整的利用后攻击路径。正确的结论是，任意命令执行为进一步访问创造了一条可信路径。

团队应将网关评估为特权集成服务。其进程身份、挂载文件、环境变量、网络路由和附加服务账户决定了爆炸半径。在修补前重建暴露情况时，这些控制措施尤为重要。

容器化只有在边界经过刻意配置时才有助于安全。容器仍然可以访问网络服务、读取挂载的密钥，或向外发送数据。其实际安全性取决于运行时权限和周边策略。

GitLab 的安装指南建议限制 AI Gateway 容器的出站网络访问。出口控制可限制被入侵进程能够联系的目标。它可以降低命令执行的利用价值，但无法消除本地影响。

网络分段提供了另一层遏制。网关需要访问明确指定的 GitLab 和模型端点，但通常不需要在内部网络中拥有不受限制的访问权限。严格的允许列表会让异常横向移动更加困难。

凭据设计同样重要。直接存放在环境中的长期密钥会成为极具吸引力的后渗透目标。短期凭据、隔离的服务账户和范围严格受限的权限，可以在服务遭入侵后减少损失。

安全团队还应检查谁可以创建或修改自定义流程。GitLab 的文档在多个工作流中将流程管理操作授予了 Maintainer 或 Owner 等角色。确切的暴露情况仍取决于产品配置和受影响的具体实现。

该公告使用了更宽泛的“Duo Agent Platform access”表述，而非指定一个普遍必需的项目角色。管理员不应将文档示例视为确定无疑的利用前提条件。他们应审查实际权限和历史流程变更。

自托管仍然是有效的架构选择。这里的教训并不是托管服务总是更安全，而是数据控制、软件控制和事件响应责任会一并到来。

托管网关将信任集中于供应商的运营体系。自托管网关则将信任集中于客户的修补、隔离和监控能力。CVE-2026-90970 使这种交换变得清晰，因为修复边界恰好遵循托管边界。

对于企业采购方，安全审查应同时覆盖产品功能和部署所有权。有关数据流向的问题，应与谁负责修补每个组件的问题一并提出。没有运营所有权的架构图仍然是不完整的。

补丁修复漏洞，但检测问题仍在

更新可阻断已知的易受攻击路径，但公开公告并未告诉运营人员如何证明此前从未发生过利用。

截至 10 月 4 日，GitLab 尚未公开表示 CVE-2026-90970 已在野外遭到利用。这一缺失令人宽慰，但并不能证明每一处受影响部署都未被触及。

公开的技术细节提升了快速打补丁的重要性。披露工单描述了易受攻击的对象关系，并报告在预发布环境中成功实现了命令执行。防御者和攻击者都可以研究这些材料。

GitLab 将负责任披露归功于名为 invisiblemeerkat 的 HackerOne 研究人员。负责任报告为 GitLab 争取了准备修复方案和联系受影响客户的时间。但对于在发布后仍未修补的部署而言，这并未消除暴露窗口。

身份验证要求应指导威胁狩猎。安全团队应从 Duo Agent Platform 身份、流程管理事件和自定义流程定义变更入手，并将这些记录与易受攻击期间的网关活动关联起来。

异常流程配置值得审查，尤其是访问对话历史对象或调用方法的模板。意外的流程创建、编辑、发布或执行可以提供额外背景。看似正常的流程名称不应掩盖可疑的模板行为。

网关进程活动同样重要。子进程、shell 调用、异常二进制文件、异常文件访问和出站连接，都可能表明存在命令执行。可用数据取决于已启用的容器、主机和云遥测能力。

容器重启可能会清除本地证据。因此，集中式日志和运行时安全遥测比仅检查当前运行的容器更有价值。若怀疑遭入侵，团队应在替换基础设施前保留可用日志。

运营人员应审查网关进程可访问的密钥。轮换决策应基于证据和暴露情况，而非恐慌。若日志显示发生过命令执行，应假定可读取的凭据可能已被访问。

网关与 GitLab 及模型提供商之间的连接值得单独关注。获得命令执行能力的攻击者可能尝试复用令牌、检查配置或访问已连接服务。公开记录并未证实此类活动已经发生。

一旦存在可疑证据，补丁不应成为调查的终点。更新会移除已知代码路径，但不会撤销被盗凭据，也不会恢复在其他位置所作的变更。事件响应流程仍然必不可少。

保持谨慎还有历史原因。安全报道发现了 2026 年更早的一项 AI Gateway 问题，即 CVE-2026-1868，其同样获得 9.9 的评分，并属于同一 CWE-1336 弱点类别。该漏洞同样涉及精心构造的流程内容以及可能的代码执行。

两个高严重性模板引擎问题并不意味着每个自定义流程都不安全。但它们确实有理由促使人们更仔细审查模板、应用程序对象和序列化如何在代理系统中交汇。

这种重复出现的情况表明，安全测试需要覆盖组合关系，而不仅是孤立组件。沙箱或许能正确处理字符串，但当丰富的框架对象进入其上下文时可能失效。某一层中安全的方法，在模板能够调用它时可能变得危险。

代理平台会加剧这一问题，因为它们结合了多种灵活机制。提示词、工具、历史记录、路由逻辑、模型响应和应用程序 API 会跨重复步骤相互作用。某一步引入的状态，可能在之后成为可执行输入。

组织应将对抗性自定义流程加入部署前测试。测试应包括方法访问、对象遍历、序列化边界和多步骤状态变化。一次性提示词扫描无法体现所报告的利用链。

它们还应将模板视为接近代码的工件。审查、所有权、变更历史和部署控制应与其潜在影响相匹配。将文件称为“配置”并不会降低它改变运行时行为的能力。

GitLab 尚未公开说明利用所需的每一项条件。这限制了对暴露情况进行有把握评估的能力。团队应将已披露的前提条件视为最低条件，而不应假定未说明的条件就能保证安全。

三个信号将显示响应是否奏效

下一阶段取决于补丁采用情况、真实世界利用的证据，以及 GitLab 对自定义流程隔离的更深入处理。

第一个信号是运行 19.2.4、19.3.2、19.4.1 或更高已修复版本的自托管网关比例。各组织应在每个环境和副本中衡量这一比例。由于这些部署位于客户网络内部，行业范围的数据可能始终无法获得。

快速采用将缩小公开披露后的可触达攻击面。缓慢采用则会延长风险，尤其是在 AI 服务未被纳入既有漏洞管理资产清单的情况下。网关所有权应在补丁仪表盘中可见。

第二个信号是利用状态的任何变化。GitLab、CISA、事件响应公司和受影响客户可能会发布指标或确认案例。一旦报告存在活跃利用，优先级将从预防性修补转向更广泛的事件响应。

防御者应区分公开的概念验证与已观察到的攻击。技术复现证明漏洞能在已记录条件下发挥作用，但并不能证明攻击者已经攻破生产环境客户。

第三个信号是 AI Gateway 的结构性安全改动。狭义补丁可以阻断已披露的方法调用。更广泛的响应可能会减少进入模板的对象、禁止危险序列化，或强化自定义流程周围的隔离。

这种设计层面的响应至关重要，因为所报告的利用链源于功能组合。阻止一种载荷固然有用，但消除不安全的能力边界能为防范变体提供更强保护。

GitLab 未来的发行说明和代码变更应阐明修复落在哪一层。管理员应关注有关流程验证、审计事件、检测查询以及旧版网关分支支持升级路径的新指南。

企业客户现在就可以利用这起事件检验自身的运营模式。重要问题不只是 GitLab 是否出现在软件资产清单中，而是 AI Gateway 是否作为一项独立拥有、修补、记录日志并隔离的服务存在。

创建流程的开发者也应重新审视赋予配置的信任。自定义流程可以跨多个步骤协调工具与应用程序数据。它应受到与自动化脚本和 CI 定义相同程度的审慎对待。

安全审查人员应绘制四类边界：谁可以编写流程、模板能访问哪些对象、流程能调用哪些工具，以及网关进程拥有哪些权限。多个边界上的薄弱环节可能将有限访问转变为对基础设施的控制。

使用 GitLab Duo 的知识工作者无需因为该公告而放弃日常工作。多数人无法自行确定网关所有权。他们应遵循组织指引，并报告异常流程行为，而不是尝试独立测试。

管理员则面临更明确的行动：确定托管模式，确认正在运行的网关版本，部署正确补丁，并在发现可疑活动时保留证据。审查易受攻击期间的流程变更和网关遥测。

完成修补后，应在持久的运营记录中记录结果。记录此前版本、部署时间、受影响环境、验证方法和任何威胁狩猎发现。这些证据可支持未来审计和事件重建。

GitLab AI Gateway 漏洞归根结底是一个警示：AI 应用逻辑会在何处成为传统的可执行软件。故障始于提示词模板，穿过框架对象，最终以操作系统命令结束。

这条路径比单独的“AI”标签更值得关注。模型可以影响工作流，但常规软件边界仍然决定不受信任的输入是否会成为代码。组织需要围绕这两个层面建立控制措施。

如果贵组织运行 GitLab Duo，今天请问一个具体问题：谁拥有处理这些请求的网关？如果答案是您的团队，请对照 GitLab 的已修复版本验证其版本。然后测试您的监控是否能发现异常命令、被修改的流程或出站连接。补丁修复了已披露的 GitLab AI Gateway 漏洞，但持久的安全性依赖于能够经受下一次公告考验的资产清单、隔离和证据。