CVSS 9.9，今年第二次：GitLab AI Gateway 模板沙箱逃逸给 Agent 基础设施上的一课

2026 年 10 月 2 日，GitLab 发布 AI Gateway 19.4.1 补丁版本，随附的安全公告披露了一个编号为 CVE-2026-90970 的漏洞：CVSS 评分 9.9，距离满分只差 0.1。一个拥有 Duo Agent Platform 权限的登录用户，只需要提交一份精心构造的自定义 flow 配置，就能逃出 prompt 模板的沙箱，在网关主机上执行任意命令。漏洞由 HackerOne 研究员 invisiblemeerkat 负责任披露。截至 10 月 2 日，尚无已知的在野利用，CISA 将其利用状态标记为 none，也没有公开 PoC 流出。

先把这个漏洞放在正确的位置上理解。GitLab AI Gateway 是连接 GitLab 与 Duo Agent Platform 背后大模型的服务：用户的请求先经过网关，网关把 flow 配置和 prompt 模板渲染好，再去调用模型。问题就出在「渲染」这一步——模板引擎是 Jinja2，渲染发生在服务端、发生在调用 LLM 之前，而这台服务端同时持有模型调用凭证。用户可控的输入，在一台持有高价值秘密的服务器上被当作模板执行。这不是什么新花样，这是服务端模板注入（SSTI），CWE-1336，一个在 Web 安全领域被研究了十多年的老漏洞类别，穿上 Agent 基础设施的外衣又出现了一次。

披露的时间线也值得注意。漏洞经 HackerOne 平台由研究员 invisiblemeerkat 负责任披露，GitLab 在 10 月 2 日随补丁版本一并公开。截至披露日，无已知的在野利用，CISA 的利用状态标记为 none，也没有公开 PoC。这是个好消息，但别把它当成可以慢慢 patch 的理由：模板沙箱逃逸属于「原理公开即武器化」的漏洞类别——CWE-1336 的攻击模式在安全社区里是公开知识，一旦有人把 GitLab AI Gateway 的具体渲染入口摸清楚，从披露到出现可用 PoC 的窗口期按历史经验通常很短。9.9 分的漏洞，补丁策略只有一种：立刻升。

这不是 prompt 注入，别搞混了

很多人第一眼会把这个漏洞归类为「prompt 注入」，这是错的，而且错得很关键。Prompt 注入骗的是模型：让模型输出攻击者想要的内容、泄露 system prompt、绕过安全对齐。CVE-2026-90970 骗的是模板引擎：Jinja2 在把 prompt 拼好发给模型之前，先在网关主机上把模板里的表达式求值了。攻击者的代码根本没经过模型，直接在服务器上运行。一个是话术层面的欺骗，一个是执行层面的接管，两者差了一个数量级。

这个区分之所以重要，是因为防御思路完全不同。防 prompt 注入靠的是对齐、输入过滤、输出审查；防模板沙箱逃逸靠的是压根不让不可信输入进入模板渲染，或者把渲染放到无凭证、无网络的隔离环境里。把 CVE-2026-90970 当成 prompt 注入来修，等于给错了药——而 GitLab 今年已经给过一次错药了，见下文。

顺带说一句为什么这类漏洞的评分能到 9.9：模板逃逸一旦成功，攻击者拿到的是网关主机的完整命令执行权。而这台主机按设计就持有模型调用凭证——命令执行权叠加凭证窃取，攻击者既能横向移动，也能把模型调用配额和经手的数据一并带走。单点突破、满盘皆输，这就是网关类组件出高危漏洞时评分封顶的逻辑。

谁要行动，谁可以不动

影响范围很明确。受影响的版本：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.com、GitLab Dedicated 以及 GitLab 托管的网关已经自动修复，这些用户什么都不用做。需要动手的只有一类人：自托管 AI Gateway 的用户。

这里藏着一个容易踩的坑：AI Gateway 的升级与 GitLab 主版本是相互独立的。你的 GitLab 实例可能已经打了最新的安全补丁，仪表盘上一片绿色，但网关跑的镜像 tag 还停在 19.4.0——漏洞照样在。自托管环境里，「GitLab 已更新」不等于「网关已更新」，这是两套发布列车。已经有太多团队的补丁流程只覆盖主应用，网关、runner、registry 这些周边组件靠人工想起来才升。这次就是一次点名：去查你的网关镜像 tag，现在。

第二个动作是审计权限。利用这个漏洞的前提是「登录用户 + Duo Agent Platform 权限」。权限的授予范围越宽，能构造恶意 flow 配置的人就越多。在很多团队里，Duo 相关权限是批量开的，离职员工、短期外包、测试账号的权限回收永远慢半拍。漏洞窗口期里，每一个多余的权限持有者都是一个潜在的攻击入口。

今年第二次，同样的 9.9 分

最值得咀嚼的是这一句：这是 GitLab AI Gateway 今年第二次出现同类严重漏洞。2026 年 2 月的 CVE-2026-1868，同样 CVSS 9.9，同样是这个模板引擎组件，同样归类为 CWE-1336。两次漏洞相隔 8 个月。

第一次可以叫疏忽：模板引擎的沙箱本来就以难做对著称，Jinja2 官方文档自己都承认沙箱模式不是安全边界，研究员找到一条逃逸路径，厂商打补丁堵上，流程走完。但 8 个月后同一个组件、同一个 CWE 编号又爆出 9.9 分，性质就变了。这说明 2 月份的修复堵的是某一条具体的逃逸路径，而不是「用户输入不该在持证服务端渲染」这个信任边界。沙箱逃逸类漏洞有个残酷的规律：你修的是洞，攻击者找的是墙——只要渲染不可信模板和持有模型凭证这两件事还发生在同一台服务器上，新的逃逸路径只是时间问题。

对 GitLab 来说，真正的修复不是再发一个 19.4.2，而是重新设计这条调用链：模板渲染能不能挪到无凭证的隔离环境？flow 配置能不能在渲染前做更强的 schema 约束，让它表达能力受限到构不成代码？这些是架构问题，补丁版本号解决不了。

Agent 基础设施的新威胁类别正在成型

把视线从 GitLab 一家抬起来，CVE-2026-90970 暴露的是整个 Agent 平台共有的攻击面：用户可定义的 flow / prompt 配置，本质上是代码。任何一个 Agent 平台，只要把「渲染用户输入」和「持有模型凭证」放在同一台服务器上，就继承了这层风险。Duo Agent Platform 的 flow 配置是这样，各家的 agent 编排、自定义指令、prompt 模板大同小异——区别只在于有没有人去挖。

今年的事故清单已经能连成一条线了。4 月，Cursor 的 Agent 被曝出删库事件（PocketOS）：Agent 拿到了超出预期的执行能力，破坏发生在真实环境。7 月，Hugging Face 的自主 Agent 攻陷集群节点，执行了超过 17000 条命令：Agent 的自主行动能力一旦被劫持，破坏规模是机器级的。10 月，GitLab AI Gateway 模板沙箱逃逸：攻击者甚至不需要劫持 Agent，直接从配置层拿到网关主机的命令执行权。三起事件的作案手法各不相同，但病根是同一个：Agent 基础设施的能力边界在过去一年里扩张了几倍，安全模型还停留在「聊天机器人」时代。

传统 Web 应用的安全模型假设「用户输入是数据」，Agent 平台悄悄把这个假设换掉了——在 Agent 世界里，用户输入（prompt、flow 配置、自定义指令）经常就是代码，会被模板引擎求值、被 Agent 当成行动计划执行。安全团队如果还用防 XSS、防 SQL 注入的老清单去审计 Agent 平台，CVE-2026-90970 这类漏洞就会一直漏网。审计清单的第一行，应该改成：这条链路上，到底是谁在执行谁的输入。

给 vibe coder 的三件事

如果你是自己搭东西的 vibe coder，这次事件有三件具体的事值得做，而不是泛泛的「注意安全」。

第一，检查你所有自托管 AI 组件的版本，而不只是 GitLab。网关、模型代理、prompt 编排服务——这些站在模型前面的「前置件」往往有独立的发版节奏，也最容易被遗忘。这次 GitLab 官方明确说了网关独立升级，把网关、runner 这类组件纳入你的补丁清单，设个日历提醒都比靠记忆强。

第二，把「谁能改配置」当成和「谁能登录」同等重要的权限来管。在 Agent 平台里，能编辑 flow、能改 system prompt、能调 agent 工具权限的人，实际权力接近管理员——CVE-2026-90970 证明了，配置层就是代码层。定期审计 Duo Agent Platform 这类权限的持有者，离职、外包、测试账号的权限该收就收。

第三，对「配置即代码」建立条件反射。以后每当你在某个 Agent 平台里看到「自定义 flow」「prompt 模板」「变量插值」这类功能，多问一句：这个模板是在哪台机器上渲染的？那台机器上还有什么秘密？如果答案是「和模型 API key 在同一台服务器上」，那这个平台就继承了 CVE-2026-90970 的攻击面——无论它有没有被公开披露过。

一句话总结：CVE-2026-90970 的技术细节并不新鲜，新鲜的是它发生的位置——Agent 调用链的最上游。当 AI 网关变成所有开发流量的必经之地，它就成了单点故障，也是单点攻击面。今年第二次 9.9 分说明，Agent 基础设施的安全课才刚刚开始交学费。自托管网关的用户先去升级，剩下的人，记住这个模式：用户输入在哪里被渲染，哪里就是下一个 CVE-2026-90970。