GitLab AI Gateway沙箱逃逸漏洞：自托管实例面临命令执行风险

GitLab近期修复了一个编号为CVE-2026-90970的严重安全漏洞，CVSS评分高达9.9。该漏洞存在于GitLab AI Gateway组件中，允许具有Duo Agent Platform访问权限的认证用户，通过精心构造的流程配置逃逸提示词模板沙箱，最终在网关上实现任意命令执行。

这个漏洞之所以值得企业安全团队高度重视，不仅在于其接近满分的CVSS评分，更在于它揭示了一个日益普遍的问题：随着开发平台不断集成AI能力，这些AI组件正成为攻击者眼中的新目标，而企业的资产清单往往还未跟上这一变化。

CVE-2026-90970漏洞到底允许什么

GitLab官方对该漏洞的描述简洁而精确，值得逐字理解：在特定条件下，该漏洞「可能允许具有Duo Agent Platform访问权限的认证用户，通过精心构造的流程配置逃逸提示词模板沙箱，从而在AI Gateway上执行任意命令」。

仔细阅读这段描述，可以勾勒出整个事件的轮廓。攻击者必须是经过认证的用户，不涉及任何匿名请求。被操纵的对象是流程配置（flow configuration）——这本是Duo Agent Platform中面向用户的常规内容。提示词模板和多步骤流程本就是开发者被期望去编写的东西。而围绕这些模板的沙箱，正是用于确保已编写流程停留在其应处进程内的控制机制，这个缺陷却让精心构造的配置得以突破限制。

漏洞的严重程度评估与此判断相符。CVSS 9.9配合「范围变更」（scope change）意味着其影响会突破受影响组件自身的安全边界，而非局限在内部，并对机密性、完整性和可用性三要素均造成高度影响。该漏洞的负责任披露由一名HackerOne研究人员完成。

CVSS（通用漏洞评分系统）是业界评估漏洞严重程度的标准化框架，满分为10分。评分由多个维度的基础指标共同决定，包括攻击向量（本地/相邻/网络）、攻击复杂度、所需权限级别、是否需要用户交互，以及对机密性、完整性和可用性的影响程度。「范围变更」（Scope Change）是其中一个关键指标，表示漏洞的影响能够突破受影响组件自身的权限边界，波及其他安全域——例如从应用层逃逸至操作系统层。正因为范围变更会显著放大实际危害，它往往会将评分推向高位。CVE-2026-90970的9.9分之所以接近满分，正是「网络可达、低权限认证用户可触发、影响范围可外溢」这几个高风险因子叠加的结果。

为什么AI Gateway持有特权凭证

位于开发平台与一个或多个模型提供商之间的网关，并非简单的流量转发器。它是一个持有这些提供商凭证、终结来自平台请求的服务。在自托管部署中，它掌控着整条推理路径——任何提示词、代码输入或模型响应都不会离开客户网络，这恰恰是企业选择自托管的原因。

命令执行意味着什么

正是这一设计决策，让该漏洞的意义超越了它的CVSS数字。在网关上执行命令，等同于在持有平台所对接的每一个模型密钥的组件内部执行命令，也等同于在能够看到每一条提示词和每一条响应的组件内部执行命令。所谓「范围变更」，换个说法，就是对安全团队在成功利用发生后不得不去圈定的爆炸半径的描述。

GitLab的文档明确区分了几种部署选项。采用自托管模型的自托管AI Gateway运行在客户自己的基础设施内，对AI路径拥有完全控制；混合配置则按功能将自托管网关与GitLab托管模型组合使用；使用供应商模型的GitLab.com AI Gateway则完全不需要额外基础设施。每种选项都伴随各自的维护义务，而只有前两种会将网关版本置于客户自己的变更管控之下。

GitLab Duo Agent Platform是GitLab内置的AI辅助开发功能集合，允许用户定义多步骤的自动化流程（flow），将代码审查、测试生成、文档编写等任务编排为可重复执行的Agent工作流。其中，提示词模板（prompt template）是这些流程的核心构建块——开发者在模板中定义Agent的行为指令，平台在运行时将变量填充进去再送往模型。沙箱（sandbox）机制的作用，正是对模板的渲染与执行环境加以隔离，防止模板内容越权访问底层系统资源。CVE-2026-90970所揭示的，就是这道隔离边界存在可被绕过的缺陷：精心构造的流程配置可以欺骗沙箱，使其执行原本不应被允许的操作系统级命令。

哪些实例受影响，哪些安全

受影响的版本范围从AI Gateway 18.1.6到19.2.3、从19.3.0到19.3.1，以及从19.4.0开始。对应的修复版本为19.2.4、19.3.2和19.4.1。

关键的分野在于托管方式。GitLab托管的AI Gateway在发布说明之前就已完成修复，因此使用GitLab托管AI Gateway的GitLab.com、GitLab Dedicated以及自管理实例均无需采取任何行动。真正的风险暴露面集中在运行自己自托管网关的自管理客户身上。

这里有两个容易被忽视的后果。其一，GitLab应用程序本身的升级并不一定会更新AI Gateway，因为二者拥有各自独立的发布线——修复版本是以网关版本号命名的。其二，一份将「GitLab」列为单一条目的资产清单，会掩盖这里真正重要的组件。如果网关作为容器或服务运行在你已经打补丁的应用程序旁边，它就需要有自己的条目、自己的版本字段和自己的升级负责人。

自管理网关的修复顺序

修复的第一步是识别，因为它决定了后续工作是否适用。找出每一个运行自托管AI Gateway的位置，记录版本号，并确认是否有任何功能被路由到了GitLab托管的网关——GitLab文档中记载了一种混合模式，其中部分功能使用托管模型，而这些功能完全处于你的网关之外。

随后，按照与你部署相匹配的分支，将受影响的网关升级至修复版本。GitLab的说明建议立即更新，并指出自管理客户在发布之前就已被通知，因此遵循供应商通知流程的团队可能已经知晓此事。

接下来，应在自己的文档中将网关视为特权组件对待。如果无法确认升级已及时落地，就轮换网关持有的任何提供商凭证；将网关日志纳入监控视野；并在每月生成的资产清单报告中加入版本检查。一个不出现在任何清单中的网关，会在每一次补丁之后，悄无声息地反复通不过同样的检查。

自托管AI平台给攻击面带来了什么

设想一个具体案例（标注为假设）：一个30人的产品团队出于数据驻留的考虑，将Duo迁移到自托管AI Gateway——代码和提示词必须保留在欧盟境内的基础设施上，而网关正是实现这一点的组件。这个部署本身没有任何错误。真正改变的是资产清单：一个一年前还不存在于补丁日历中的服务，如今位于每一条代码建议的路径上，持有模型后端的凭证，并拥有自己独立的发布线。

这最后一点可以推广到开发平台如今所交付的每一个AI组件。推理网关、检索索引、向量数据库、Agent运行时——每一个都是拥有自己版本、自己凭证集和自己CVE信息流的独立服务。把它们当作所接入平台的功能来对待，正是让一个看似合理的升级故事演变为「打了补丁的应用背后运行着未打补丁的网关」的根源。而察觉到这种状态，是一个监控问题，而非扫描问题。

这一更广泛的模式，与编码Agent供应链所面临的风险一脉相承：随着开发平台吸纳AI功能，AI组件成为了攻击者探测的部分，因为它们比周围的应用程序更新，且持有应用程序本来不需要的凭证。本次漏洞的修复方案已经可用，验证起来也很简单。真正剩下的工作，是确保你的团队知道这个网关的存在。

向量数据库和检索索引是现代AI应用（尤其是RAG架构，即检索增强生成）中的基础组件。RAG模式下，系统先从向量数据库中检索与用户查询语义相近的文档片段，再将这些片段连同用户输入一起送往大语言模型，使模型能够基于私有知识库作答。在开发平台场景中，这些知识库往往包含代码仓库、内部文档和历史Issue等高度敏感的内部资产。Agent运行时（Agent Runtime）则是负责调度和执行多步骤Agent任务的执行环境，通常持有调用外部工具和API的权限。这些组件与AI Gateway一样，都是拥有独立版本、独立凭证集和独立安全公告订阅需求的服务，却常常被错误地视为平台功能而非独立的攻击面。