GitLab AI Gateway 命令执行漏洞：版本与权限边界

获准配置智能体流程的 GitLab 用户，不应因此取得处理流程的服务所拥有的操作系统权限。CVE-2026-90970 打破了这一分隔：特制 Duo 流程配置可以逃逸提示模板沙箱，在受影响 AI Gateway 上执行任意命令。

GitLab 于2026年10月2日披露漏洞，CVSS 3.1 评分9.9，属严重级别。攻击需要身份认证和 Duo Agent Platform 访问权。这不是匿名用户零点击接管所有 GitLab 服务器的报道。危险在于满足前提后越过的边界，而不是假装这些前提不存在。

GitLab 托管网关已经修复，受影响自托管网关的运营方则要自行升级和调查。把代码与提示留在私有网络，不会自动把已认证配置作者限制在预期沙箱中。

核验网关版本，不要只看 GitLab 主应用

披露的受影响范围从 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 AI 原生功能与模型后端之间的独立应用服务，负责应用逻辑和模型请求，而不是语言模型本身。镜像和部署生命周期可能不同于主应用，因此熟悉的主应用版本检查可能漏掉旧网关。

托管、混合和完全自托管也不同。混合环境中，一些功能可能走客户基础设施，另一些走 GitLab 托管服务。清单需要覆盖功能级路由、所有副本、开发与概念验证环境、缓存镜像和灾难恢复部署，不只是主要生产界面。

完全自托管可在少量或没有通用互联网连接的网络运行。这减少部分外部路径，却不会排除获授权内部人员、被盗账户、服务令牌或其他失陷内部负载。断网还可能减慢安全通知和补丁传递。

故障发生在模板软件中

智能体流程可以把提示、工具、决策和行动组合为多步骤开发任务。模板把配置与运行时值转换成模型指令；沙箱本应阻止模板输入访问不安全应用函数或操作系统能力。

该问题归为 CWE-1336，即模板引擎特殊元素未被正确中和。攻击者控制的语法可能被解释为可执行模板行为，而非普通数据。GitLab 对此漏洞描述的结果是网关任意命令执行；后续影响取决于进程权限、暴露对象、可用凭据和网络路径。

这不同于提示注入。提示注入试图用指令影响模型，模板注入则攻击构造或渲染指令的传统软件。无论模型怎样回答，都可能发生命令执行。因此，给模型再加一条行为安全指令，并不是不安全模板处理的修复办法。

这也不证明模型独立发现了逃逸。输入表面是 AI 流程，但脆弱边界属于应用软件。审查必须覆盖配置历史、网关与容器活动、权限和下游凭据，不能把对话记录当作整个事件证据。

为什么需要登录的漏洞仍评为9.9

公开向量为 AV:N/AC:L/PR:L/UI:N/S:C/C:H/I:H/A:H。网络攻击不要求预先获得本地 shell，但“网络”不必然意味着公开互联网端点。低复杂度表示标准评估中不需要狭窄竞争条件或异常状态；低权限仍意味着用户必须认证并拥有平台访问权。

无后续用户交互意味着恶意配置到达脆弱路径后，不需要另一个人再打开文件、批准对话框或点击诱饵。作用域改变描述从获准的流程输入，跨入网关命令环境这一不同安全权限域。

机密性、完整性和可用性的高影响，反映读取可访问资料、修改资源和中断服务的可能性。9.9标准评分并不证明每个部署均遭最大损害，甚至不证明已发生入侵。实际波及范围取决于架构、最小权限、可达系统和秘密信息。

已认证用户不自动等于基础设施管理员。流程作者可能需要广泛应用功能，却不应拥有解释流程的进程权限。被盗令牌或权限过宽的自动化身份，会让这一区别在原用户合法时同样重要。

容器也是边界，不是风险橡皮擦。即使不以 root 运行，容器仍可能暴露挂载秘密、服务令牌、经手数据和内部网络。可写挂载、过高权限和广泛出站路径会扩大后果；单容器命令执行也不自动证明整个基础设施失陷。

第二个严重问题提出架构疑问

2月，GitLab 修复了网关 Duo Workflow Service 中的 CVE-2026-1868，同样涉及通过特制平台流程，不安全地展开用户提供模板，评分与向量也同为9.9。修复版本包括18.6.2、18.7.1和18.8.1，发现者是一名内部团队成员。

相似性值得深入审查流程到模板的信任边界，却不能证明10月问题是回归、2月修补不完整，或同一条不安全路径。公开摘要无法确立关系，任何一种解释都不能写成已经证实。

当服务把表达式、变量和插件转换成高权限行动时，灵活的声明式配置可能实际上具有编程语言性质。可定制性越强，解析器与沙箱需要安全解释的内容越多。危险组合是同一进程既渲染不可信模板，又握有重要基础设施访问权。

多层独立防护仍有价值：把输入当数据、最小化模板对象、授权流程提交、约束文件系统／网络／凭据权限，并留存可归责变更。流程创建或修改应能追踪到后续网关活动。自定义流程需要类似 CI 配置的所有者、审查、版本与测试。

安装补丁与判断是否失陷是两项工作

运营方应保留旧镜像摘要和部署证据，安装修复版、重启负载，再核验真正运行的镜像。旧副本、测试集群与恢复环境都不应保留受影响镜像。一次成功启动不能证明每份副本都被替换。

受影响期间的调查应确认哪些人员和服务身份能够创建或修改 Duo 流程，保留配置并检查审计记录。异常子进程、命令解释器、文件变化、出站连接或不寻常重启，应对照正常基线调查。这些是排查线索，不是已经公布、适用于本 CVE 所有部署的通用入侵指标。

安装文档描述签名 JSON Web Token，以及拥有独立签名密钥对的 AI Gateway 与 Agent Platform 服务。调查应检查两种服务、信任关系和运行时密钥／配置，不能假定一项凭据代表全系统。若证据或暴露情况支持，应轮换失陷进程能够访问的凭据。

还要绘出网关能访问的 GitLab 实例、模型服务器、监控和内部系统。即使容器本地存储很少，来自源代码的提示和 issue 上下文也可能敏感。限制出站、负载身份、只读文件系统与最小权限可控制后果，但不能修复模板漏洞或替代升级。

自托管把工作分给平台、模型、容器、网络团队，无人认领的网关镜像可能落在职责缝隙。托管减少这一具体客户补丁任务，却带来不同供应商、数据驻留和依赖取舍；事件不能证明某种方式永远更安全。

公开记录尚未证明什么

现有报道没有确立生产环境中活跃或广泛利用，也没有提供公开概念验证、详细调用路径或通用入侵后指标。没有公开确认，不等于确认从未发生。供应商已确认的命令执行和严重评级，足以支持修复，不必等到不确定性变成更多暴露。

下一步证据应包括可验证的客户补丁采用、GitLab 更完整的根因解释，以及可信利用遥测或机构新指导。在客户有时间更新后，根因说明可区分独立路径、绕过或回归。本地完成记录应保存新旧镜像、重启时间、验证和责任人，并留存事件与配置历史。

有用的运营检验是：哪些网关存在，谁能修改流程，每个进程可触及什么资产和秘密？AI 中间件应与 CI runner、制品仓库和秘密管理器受到同等生产管理。只有能够盘点、修复、隔离和调查实际执行工作的服务，数据本地化才真正成为控制权。

参考来源

浏览工具目录 →

GitLab 网关修复守住的边界，Duo 登录认证无法替代