GitLab AI Gateway 漏洞将已获授权的 Duo 访问转化为严重的 RCE 风险
GitLab 已修复一项 CVSS 评分为 9.9 的 GitLab AI Gateway 漏洞，该漏洞可将已获授权的 Duo Agent Platform 访问转化为在自托管网关上执行命令的能力。该漏洞编号为 CVE-2026-90970，突破了产品本应强制执行的安全边界。经过精心构造的流程配置可逃逸提示词模板沙箱，并在网关上执行任意命令。
这一限定条件至关重要。这并非已被报告的、可零点击攻陷所有 GitLab 服务器的漏洞，也不会让匿名互联网用户立即获得访问权限。利用该漏洞需要完成身份验证，并拥有 Duo Agent Platform 访问权限。不过，GitLab 的严重性评估反映了满足这些条件后可能发生的情况：可通过网络以低复杂度利用，无需进一步用户交互，并可能对保密性、完整性和可用性造成严重后果。
这一事件直接凸显了控制权与责任之间的矛盾。组织选择自托管 AI 基础设施，是为了将代码、提示词和模型流量保留在可信边界内。但自托管也意味着，这些组织必须自行负责更新处理这些敏感材料的服务。GitLab 托管的网关已完成修复，而受影响的自托管网关运营方则必须自行完成升级。
GitLab AI Gateway 漏洞带来了什么变化
CVE-2026-90970 将配置 AI 工作流的权限转化为一条可能通往操作系统命令执行的路径。
GitLab 于 2026 年 10 月 2 日披露了该问题。根据公开的漏洞记录，受影响版本包括 18.1.6 起至 19.2.4 之前的 AI Gateway 版本。19.3 分支在 19.3.2 之前受影响，19.4 分支则在 19.4.1 之前受影响。
这些版本边界与 GitLab 主应用的发布历史不同。因此，管理员应核实 AI Gateway 镜像或部署本身。仅检查可见的 GitLab 应用版本，可能会造成虚假的安全感，因为网关遵循独立的部署生命周期。
修复版本为 19.2.4、19.3.2 和 19.4.1。运营方应升级至相应的修复版本或更高的受支持版本。GitLab 托管的网关已完成修复，因此 GitLab.com 以及使用 GitLab 托管网关的客户无需面对相同的补丁任务。
易受攻击的路径始于经过特殊构造的流程配置。流程定义了一个可结合提示词、工具、决策和操作的智能体序列。GitLab Duo Agent Platform 使用这些配置执行多步骤的软件开发任务，而不是只回答单一、孤立的提示词。
提示词模板会将流程的配置和运行时数据转换为 AI 模型可处理的指令。模板沙箱是一种受限环境，旨在防止模板内容触及不安全的应用程序或操作系统能力。CVE-2026-90970 涉及该边界内的特殊元素未被正确中和。
该弱点被归类为 CWE-1336，即对模板引擎中使用的特殊元素进行了不当中和。实际而言，攻击者控制的语法可能被解释为可执行的模板行为，而非惰性数据。具体的危险后果取决于周边应用、可用函数和进程权限。
对于这一漏洞，GitLab 表示其结果可能是在 AI Gateway 上执行任意命令。这一结果比操纵 AI 响应更为严重。这意味着该漏洞突破了模型输出，进入了承载网关的常规执行环境。
区分 AI Gateway 与大语言模型十分重要。网关是位于 GitLab 功能与 AI 模型之间的独立应用服务。GitLab 的网关文档指出，该服务为 AI 原生的 GitLab Duo 功能提供访问能力。它处理围绕模型的应用逻辑和请求，而非模型本身。
因此，该漏洞并不表明模型自行发现了逃逸路径，或忽略了行为安全指令。已报告的机制是模板处理中的软件漏洞，其输入恰好通过智能体配置界面传入。
这一事实使该事件仍属于熟悉的安全问题类别，但其所处环境提高了风险。AI 网关可能处理源代码衍生的上下文、工作流指令、认证材料，以及与模型后端的连接。该交汇点上的命令执行漏洞，可能暴露的不只是格式错误的提示词或不可靠的回答。
GitLab 尚未公开描述 CVE-2026-90970 被大规模利用的情况。现有记录也无法证明攻击者已在生产环境中利用该漏洞。管理员不应将这一验证空白解读为安全证明，尤其是在披露已为潜在攻击者提供更明确目标之后。
因此，眼下的变化是运营层面的。此前被视为受控内部组件的自托管 AI Gateway，如今需要紧急进行版本核查、修补和升级后审查。其风险不能仅根据 GitLab 主界面是否公开来判断。
为什么经认证的沙箱逃逸能获得 9.9 评分
该漏洞之所以严重，是因为其前置条件限制了攻击者范围，但沙箱一旦失效，潜在影响仍可能十分广泛。
GitLab 为 CVE-2026-90970 分配了 CVSS 3.1 基础评分 9.9。公开的向量为 AV:N/AC:L/PR:L/UI:N/S:C/C:H/I:H/A:H。每个元素都解释了为何一个经认证的漏洞仍能位居严重性量表的顶端附近。
网络攻击向量意味着，潜在攻击者无需获得网关主机的本地 shell 访问权限。相关服务可通过网络可访问的应用功能接收恶意配置。可通过网络访问并不一定意味着暴露于整个公共互联网，但它将可能的攻击路径扩展到了物理或本地访问之外。
低攻击复杂度表明，利用并不依赖狭窄的竞争条件或异常的部署状态。所需权限较低，而非无需权限。用户必须完成身份验证，并拥有 Duo Agent Platform 访问权限。
无需用户交互意味着，在配置进入易受攻击路径后，其他人无需打开文件、批准对话框或访问恶意链接。这一特性在协作开发环境中尤为重要，因为可信自动化通常会在无需第二次人工操作的情况下处理提交的配置。
范围变更组件尤其值得关注。它表明，利用可能影响超出原始易受攻击组件所代表安全权限范围的资源。在此，模板输入始于获授权的智能体工作流，却可跨入网关的命令执行环境。
最后三项指标记录了对保密性、完整性和可用性的高潜在影响。理论上，命令执行可支持读取可访问的信息、修改网关资源或中断服务。实际损害仍取决于部署架构、进程权限、网络可达性和可用凭据。
这一背景可避免两种误导性解读。将漏洞称为“需认证”不应被用来淡化为普通的账户级问题。将其称为“远程代码执行”也不代表每位匿名访问者都能立即攻陷 GitLab 环境。
相关攻击者可能本就是有效用户，也可能是控制了被入侵账户、失窃令牌或权限过高的自动化身份的人。安全边界必须在认证完成后继续发挥作用，因为合法访问很少等同于无限的基础设施权限。
智能体系统使这种区分更加紧迫。它们接受结构化指令，并能够在开发服务之间执行一系列操作。获授权定义流程的用户可能确实需要广泛的应用能力，但不应因此继承解释该流程的服务所拥有的操作系统权限。
易受攻击的沙箱原本旨在维持这种隔离。它的失效将一种配置语言转化为可能的执行面。这正是 GitLab AI Gateway 漏洞背后的核心逆转：原本用于约束智能体操作的功能，变成了绕过自身隔离层的路径。
模板注入也不同于提示词注入。提示词注入会操纵发送给模型的指令，通常试图重定向模型行为或泄露上下文数据。模板注入针对的是构建或渲染这些提示词的软件。当模板引擎暴露不安全的对象或函数时，无论模型如何响应，都可能导致服务器端执行。
CWE-1336 对这类失效进行了正式定义。当软件未能中和模板引擎视为可执行语法的元素时，就会出现模板引擎弱点。最安全的应对方式不是再向模型添加行为指令，而是通过软件修复阻止攻击者控制的数据变成可执行的模板内容。
这种差异应当塑造事件复盘的方式。团队需要检查应用权限、配置历史、网关日志、容器活动和下游凭据。仅审查 AI 对话记录，会遗漏发生在网关进程或其周边运行时中的活动。
即使网关不以 root 身份运行，它通常仍处于具有特权的集成位置。它可能与 GitLab 实例、模型服务器、可观测性系统或内部网络服务通信。运营方应梳理这些连接，而不是假定一个容器上的命令执行必然等同于整个基础设施被完全攻陷。
配置得当时，容器化可以降低影响，但无法消除事件。被攻陷的容器仍可能暴露挂载的密钥、服务令牌、可通过网络访问的系统，或进程处理的数据。过多权限、可写挂载和宽泛的网络路由会扩大这一影响范围。
因此，9.9 分描述的是最坏情况下的标准化评估，而非证明每个受影响环境都遭受了最大程度的损害。管理员必须将该评分与自身实际部署架构结合起来。正确的结论是紧急调查和修复，而非自动确认已经发生了入侵。
自托管以数据控制权换取补丁责任
自托管网关的安全承诺，只有在客户能够将该网关作为关键基础设施进行清查、隔离、更新和监控时才依然有效。
GitLab 支持托管、混合和完全自托管的 AI 配置。在托管模式下，GitLab 运营网关，并将其连接至选定的外部模型提供商。自托管部署则将网关和模型路径置于客户控制的基础设施之内。
该架构能够支持严格的隐私、数据驻留和网络隔离要求。GitLab 的自托管指南称，组织可以自行运行网关和模型，从而完全掌控 AI 基础设施。完全自托管的配置也可以在仅具备有限互联网访问能力或完全没有通用互联网访问能力的网络中运行。
CVE-2026-90970 揭示了这种取舍的另一面。客户获得了对部署位置和数据流的控制权，但也需负责已部署网关的维护。GitLab 无法在客户控制的环境中悄然更新正在运行的容器。
由于 AI 网关与更为熟悉的开发基础设施并行存在，这一责任可能变得模糊。平台团队可能管理 GitLab 应用，而机器学习团队维护模型服务器。另一个团队则可能负责容器平台或网络控制。
如果没有团队明确负责网关镜像，其补丁状态就可能落入这些职责边界之间的空白地带。托管网关能避免这一特定的协调问题，因为供应商控制部署。自托管则要求内部流程将网关视为一项独立的生产服务。
资产清单是第一个关键压力点。组织需要了解自己使用的是 GitLab 托管网关、自托管网关，还是混合部署。混合部署需要在功能层面加以理解，因为某些请求可能使用客户基础设施，而另一些则使用 GitLab 托管服务。
版本发现是第二个关键压力点。运营人员应识别每一个自托管网关实例，包括概念验证系统和断网环境。即使隔离部署无法接收直接的互联网流量，仍可能受到已认证内部人员或受损身份的攻击。
打补丁是第三个关键压力点。受影响的安装环境需要升级至已修复的网关版本，而不仅仅是更新可见的 GitLab 应用。团队应保留部署证据，记录之前的镜像摘要，并确认工作负载已使用目标版本重新启动。
第四个关键压力点是暴露面分析。管理员应识别在漏洞期间哪些用户和服务账户拥有 Duo Agent Platform 访问权限。他们还应确定谁能够创建或修改流程，以及这些操作是否生成了可用的审计记录。
第五个是运行时审查。补丁后的调查应将网关进程行为与其正常基线进行比较。意外的子进程、命令解释器、文件变更、新的出站连接或异常的容器重启，都值得检查。
密钥需要特别关注。GitLab 的安装文档说明，网关使用签名的 JSON Web Tokens 对请求进行身份验证。自托管服务也会通过其运行时环境接收配置值和密钥。这些机制是正常运行所必需的，但任何受损进程可访问的凭证都可能需要轮换。
安装指南还将 AI Gateway 和 Duo Agent Platform 描述为具有独立签名密钥对的独立服务。这种分离为防御人员提供了有用的审查框架。他们应评估这两项服务、它们之间的信任关系，以及二者之间使用的凭证。
网络设计能够显著改变后果。一个只能访问模型服务器和严格限定的 GitLab 端点的网关，比可广泛访问内部网络的网关带来的机会更少。出站限制、工作负载身份、只读文件系统和最小化容器权限，仍然是有意义的控制措施。
不过，网络隔离应当补充补丁工作，而不能取代它。易受攻击的内部服务可能遭到另一个已受损内部账户或工作负载的攻击。分段能够限制横向移动和数据访问，但无法修复不安全的模板处理。
运营人员还应考虑通过网关传递的数据。选择自托管通常正是因为提示词可能包含专有源代码、议题上下文或内部指令。如果发生利用，调查人员需要确定网关可以访问哪些信息，而不仅仅是其容器中存在哪些文件。
这项工作应归入与保护 CI 运行器、制品仓库和密钥管理器相同的运营类别。所有这些服务都会将开发者可控的输入转化为自动化操作。它们的价值来自特权连接能力，而这也使其隔离措施和更新节奏变得重要。
这并不意味着托管 AI 基础设施始终更安全。托管服务集中了承担供应商责任，并减少了客户的补丁工作量，但客户接受的是不同的信任、驻留和依赖性权衡。真正的教训是：自托管改变了关键网关漏洞出现时必须由谁作出响应。
先前一个 9.9 分漏洞表明，这不只是一次性补丁
CVE-2026-90970 是 2026 年第二个公开记录的、评级为 9.9 的 GitLab AI Gateway 模板问题，这进一步强化了进行架构审查的必要性。
2026 年 2 月，GitLab 修复了 AI Gateway 的 Duo Workflow Service 组件中的 CVE-2026-1868。GitLab 公开的CVE 分配记录描述了通过精心构造的 Duo Agent Platform 流程定义，对用户提供数据进行不安全模板扩展的问题。
此前的漏洞具有相同的 CVSS 3.1 向量和 9.9 严重性评分。其修复版本包括 AI Gateway 18.6.2、18.7.1 和 18.8.1。GitLab 将该漏洞的发现归功于一名内部团队成员。
根据当前记录，新漏洞影响从 18.1.6 开始、延伸至 19.4 系列的后续发布分支。两项问题的公开描述都涉及精心构造的流程定义或配置、模板处理、低权限已认证访问，以及可能的命令执行。
这种相似性并不能证明补丁以同样的方式失效。公开漏洞摘要信息过于有限，无法确定 CVE-2026-90970 是回归问题、此前修复不完整，还是一条不同的不安全模板路径。将这些可能性视为已证实事实，会夸大现有证据。
尽管如此，防御人员不应孤立评估 10 月的披露。在同一广泛信任边界附近出现两项严重发现，表明流程配置处理值得进行更深入的测试。一次简单的版本升级或许能关闭已披露的路径，却可能仍留下更广泛的设计问题。
这一事件中的主要对立面，是平台的治理承诺与可执行配置表面的现实之间的冲突。GitLab 将代理流程定位为在既定开发流程内运行的受控自动化。若获得授权的流程作者能够跨越边界执行网关级命令，这些控制措施的价值便会降低。
这一问题并非 GitLab 产品类别所独有。AI 网关、代理编排器和工作流引擎都会将灵活的用户输入转化为特权操作。即使产品界面将其呈现为声明式文件，它们的配置格式仍可能成为编程语言。
这种灵活性带来反复出现的安全权衡。客户希望可自定义的代理能够检查仓库、调用工具、响应事件并完成多步骤目标。每一个新增工具、表达式、模板变量或插件，都会扩展编排层必须安全解释的内容。
严格的配置语言可以降低风险，但会限制客户自定义能力。灵活的语言支持更多工作流，但需要成熟的沙箱隔离、解析器控制、权限边界和安全测试。当单个进程既渲染不受信任的模板，又持有有价值的基础设施访问权限时，风险会升高。
因此，防御需要多层彼此独立的措施。解析器应将不受信任的值视为数据。模板环境应暴露尽可能少的对象集。授权机制应限制可提交流程的人员。网关运行时应仅拥有最小化的文件系统、网络和凭证访问权限。
可审计性提供了另一层保障。流程创建和修改事件应能够归因于特定的人类或服务身份。组织应能够将已提交的配置与后续网关活动关联起来。缺少这条链路，确认或排除利用行为都会困难得多。
此前的漏洞也改变了团队处理升级验证的方式。仅确认最新的修复镜像已成功启动并不够。运营人员还应确认旧副本、缓存镜像、测试集群和灾难恢复环境中没有保留受影响版本。
断网环境尤其具有迷惑性。缺乏通用互联网访问可降低某些外部威胁，但也可能延缓安全通知和补丁的交付。该环境中的已授权用户仍可能访问漏洞所需的应用功能。
审慎的评估还必须承认目前仍未知的事项。公开记录尚未提供概念验证、详细调用路径或已确认的利用遥测数据。它们也没有针对每种部署确定一套通用的利用后指标。
这些缺口限制了对已观察到攻击的可靠判断，但不会削弱打补丁的建议。一个经供应商确认、评分为 9.9 的命令执行漏洞，已具备足够风险，应立即修复。等待公开利用证据，是以不确定性换取本可避免的暴露。
更有力的长期问题是，在当前信任上下文中，模板处理是否仍有必要。GitLab 可以在客户获得足够修补时间后发布更多技术细节，以降低未来风险。根本原因信息将帮助运营人员了解哪些边界失效，以及哪些补偿性控制最为重要。
与此同时，客户应将自定义代理流程视为代码。它们应获得与 CI 配置相当的审查、所有权、变更控制和测试。即使采用可视化或声明式界面，当平台将其内容转化为操作时，工作流也并非不可执行。
防御人员接下来应关注什么
下一步评估应取决于三个信号：补丁采用情况、GitLab 的根本原因披露，以及有关现实世界利用的证据。
第一个信号是自托管运营人员是否迅速升级至已修复的 AI Gateway 版本。GitLab 控制其托管服务，但无法从私有基础设施内部衡量每个客户部署。安全团队应建立自己的完成证据，而不是假定常规软件更新报告已涵盖网关。
这些证据应标识部署、先前版本、替换镜像、重启时间和验证结果，也应覆盖开发与灾难恢复系统。如果组织难以产出这类资产清单，事件揭示的便是超出漏洞本身的所有权问题。
快速采用补丁将强化这样一种判断：企业可以像管理传统生产基础设施一样管理自托管 AI 组件。缓慢或无法衡量的采用将削弱私有部署背后的控制论据。当关键中间件仍未被追踪时，数据本地性提供的保护有限。
第二个信号是 GitLab 提供更完整的技术说明。防御人员需要了解 CVE-2026-90970 代表一条新的模板路径、一次回归，还是对先前漏洞的不完整缓解。这一区分会影响对周边架构和测试策略的信心。
一份有用的披露应说明存在漏洞的组件、受影响的权限边界以及采取的隔离措施，同时避免提供不必要的利用细节。它还应澄清，独立的 Agent Platform 和 AI Gateway 服务是否需要采取不同的事件后处置措施。
确认存在不同的根本原因，将表明广泛的模板加固措施正通过多项发现发挥作用。若有证据显示此前的缓解措施被绕过，则会引发更尖锐的问题：最初的安全边界是否经过了全面设计。
第三个信号是有关漏洞遭利用的可信证据。应关注 GitLab 和安全机构是否发布入侵指标、已知遭利用漏洞清单或修订后的响应指南。如果独立事件报告包含可验证的遥测数据，也同样值得关注。
在此类证据出现之前，文章不应将 CVE-2026-90970 描述为正在被积极利用。尚无公开确认，并不等同于确认从未发生利用。组织必须根据暴露面和影响作出响应决策，而不能仅凭新闻标题判断。
团队可以先从四个实际问题入手。我们是否运行任何自托管的 AI Gateway？所有实例是否都在运行 19.2.4、19.3.2、19.4.1 或更高版本？在受影响期间，谁能够修改 Duo agent 流程？网关进程能够访问哪些系统和机密信息？
这些答案应与事件记录、配置历史和相关日志一并保存。需要关联部署说明、责任归属决策和审查证据的团队，可以维护一个可搜索的知识库。文档无法修复漏洞，但零散的证据可能会延误隔离处置和后续审计。
GitLab AI Gateway 漏洞最终考验的是：agent 基础设施是否获得了与 CI 系统及其他代码执行服务同等严格的运营管理。修补受影响的网关，验证正在运行的镜像，审查获授权的流程变更，在证据表明确有必要时轮换暴露的凭证，并降低网关权限。
随后还要追问更困难的问题：如果下个月另一项 agent 配置跨越了信任边界，你的团队能否在无需在事件期间重新盘点资产的情况下，识别责任人、受影响版本、可访问资产和响应路径？
