保护 GitLab AI 网关免受远程代码执行攻击
大型企业花费数百万美元将他们的 AI 工作负载隔离在私有防火墙和自托管网关之后。他们期望对数据流拥有完全的控制权，并针对外部威胁建立坚固的防御周界。然而，GitLab AI 网关 19.4 版本的实际可利用性表明，即使是最隔离的环境也容易受到简单输入缺陷的影响。一个拥有 Duo Agent Platform 访问权限的已登录用户就可以绕过本应包含 AI 提示词的沙箱。这种逃逸直接导致在管理组织与大语言模型连接的服务器上执行任意命令。
我多年来一直在分析开发人员如何将模板引擎视为安全区域。存在一种普遍的误解，即如果用户已经通过身份验证，那么沙箱逃逸的风险就是次要的。这种心态是危险的。在 CVE-2026-90970 的案例中，GitLab 将该漏洞在 CVSS 评分标准中评为 9.9 分（满分 10 分）。这个分数清楚地表明安全社区将其视为任务关键型故障。该漏洞并不是微妙的内存损坏或复杂的计时攻击，而是自定义流程提示词模板中的一个故障，该功能旨在自动执行多步骤任务。
敏感签名密钥的架构风险
GitLab AI 网关充当内部 GitLab 实例与外部 AI 提供商之间连接的防碎数字金库。根据设计，此网关持有 JSON Web 令牌 (JWT) 签名密钥。这些密钥是促进安全通信的敏感凭据。如果攻击者在网关上执行命令，他们就不再仅仅是沙箱中的用户。他们拥有与网关服务本身相同的权限。这种级别的访问允许恶意行为者拦截请求，或可能操纵公司内其他开发人员在代码生成和安全扫描中依赖的 AI 响应。
从风险角度来看，其影响是系统性的。选择自托管网关通常是为了将数据保持在受控环境中。当该网关被攻破时，原本旨在增强隐私的工具反而变成了更大规模入侵的滩头阵地。网关连接着组织的 AI 模型提供商和主要的 GitLab 实例。这里的失陷是对开发环境与为其提供动力的智能层之间信任关系的破坏。
解构提示词注入沙箱逃逸
这一缺陷的技术现实在于 CWE-1336，它涵盖了网页模板中指令的中和不当。GitLab 允许用户在 Duo Agent Platform 上创建自定义流程。这些流程使用提示词模板来构建 AI 处理信息的方式。具有合法访问权限的用户可以精心构造流程配置，诱导模板引擎在其预定边界之外执行代码。这是经典的沙箱逃逸。系统将攻击者的恶意输入视为命令而非数据。
在幕后，网关未能正确验证提示词模板的结构。我记得去年通过 Signal 连接与一位白帽黑客讨论过类似案例。我们研究了一个模板引擎，如果用户以特定方式嵌套括号，该引擎就允许用户调用系统函数。这只是解析器中的一个简单疏忽。GitLab 最近的历史表明这是一个反复出现的主题。今年 2 月，他们修复了 CVE-2026-1868，这是另一个 9.9 分的漏洞，同样涉及精心构造的流程定义。这类漏洞的重复出现表明，模板安全对于 AI 集成平台来说仍然是一个难以逾越的障碍。
评估自托管实例的攻击面
只有托管自己 AI 网关的组织需要采取行动。GitLab 为 GitLab.com 和 GitLab Dedicated 的客户管理网关。主动地说，这些客户已经受到了保护，因为 GitLab 在发布公开公告之前已经更新了自己的基础设施。防御的重担现在落在了管理自己的 Docker 镜像或 Helm chart 的系统管理员肩上。
在架构层面，网关是一个独立的服务。当你更新 GitLab 主实例时，它不会自动更新。这种分离很重要。一个常见的陷阱是假设修复了 GitLab Rails 应用程序就意味着修复了 AI 环境。网关是一个独立的 Docker 镜像，拥有自己的版本控制和生命周期。如果你运行的版本在 18.1.6 到 19.2.4 之间，或者最新版本之前的 19.3 和 19.4 系列中的任何版本，你都是脆弱的。
Docker 和 Helm 的手动更新步骤
修补是唯一有效的对策，因为 GitLab 尚未提供变通方案。要保护基于 Docker 的部署，你必须停止现有容器并将其删除。然后拉取更新后的镜像标签。对于大多数企业用户，这将是 self-hosted-v19.4.1-ee 标签或其对应的 19.2 和 19.3 系列标签。
对于使用 Kubernetes 的用户，该过程涉及更新 Helm chart 中的镜像设置。下表总结了受影响版本的必要更新路径：
| 使用中的网关版本 | 首个修复版本 |
|---|---|
| 18.1.6 至 19.2.3 | 19.2.4 |
| 19.3.0 至 19.3.1 | 19.3.2 |
| 19.4.0 | 19.4.1 |
GitLab 的维护政策通常涵盖当前及之前的两个次要版本。因此，修复程序适用于 19.2、19.3 和 19.4 系列。如果你运行的是较旧版本（如 19.1），则没有列出官方修复程序。这种对旧版本支持的缺乏是管理员绝不能忽视的细节。运行不受支持的网关版本实际上相当于让数字金库处于未上锁状态。
取证限制与利用情况的缺失
截至今日，美国网络安全和基础设施安全局 (CISA) 将此漏洞的利用情况列为“无”。目前没有公开的概念验证，也没有证据表明在野外存在活跃的利用行为。然而，公告并未提供检查网关在更新前是否受到攻击的方法。这种取证可见性的缺乏是一个重大缺口。如果没有特定的日志签名或入侵指标，管理员只能暗自揣测他们的签名密钥是否在漏洞窗口期内被访问过。
在涉及此类工具的违规事件中，目标通常是隐蔽的持久化。攻击者可能不会使网关崩溃，而是悄悄导出 JWT 签名密钥，以便日后未经授权访问 AI 模型。这就是为什么在修补后立即轮换敏感凭据是行业标准做法。修补船体上的洞是第一步，但你还必须检查在洞开着的时候是否有货物被扔到了船外。
AI 安全中的人为因素
我们经常将 AI 视为坐落在现有代码之上的未来层。实际上，像 GitLab 网关这样的 AI 服务也只是软件。它们同样受到命令注入和模板逃逸等老派漏洞的影响。人为防火墙仍然是第一道防线。拥有 Duo Agent Platform 访问权限的用户才是能够触及此缺陷的人。将这些平台的访问权限仅限制在严格需要的人员范围内，遵循了最小权限原则。
零信任就像是每一扇内部大门前的 VIP 俱乐部保镖。即使用户已经在建筑内部，保镖也应该在让他们靠近模板引擎配置之前检查其凭据。如果你的组织允许每位开发人员在没有监督的情况下创建自定义 AI 流程，你就是在增加攻击面。这些 AI 集成的复杂性使得细粒度的访问控制成为一项要求而非建议。
立即缓解的要点
为了解决这一关键缺陷，管理员应遵循特定的操作顺序。首先，识别环境中当前运行的 AI 网关镜像的确切版本。不要假设版本与 GitLab 主应用程序匹配。其次，立即使用 GitLab 提供的 Docker 或 Helm 程序应用相关补丁。第三，如果网关在应用补丁前已暴露给不受信任的内部用户，请考虑轮换 JWT 签名密钥。
最后，审计有权在 Duo Agent Platform 上配置自定义流程的用户列表。如果用户没有修改这些配置的任务关键型理由，请移除其访问权限。减少能够触及漏洞的人数与修复代码本身同样重要。安全是一个持续改进的过程，而不是一次性的更新。
来源
- GitLab Security Advisory (CVE-2026-90970)
- CISA Known Exploited Vulnerabilities Catalog (Assessment Phase)
- CWE-1336: Improper Neutralization of Directives in Web Page Templates
- NIST Guide to Enterprise Patch Management Strategies
免责声明： 本文仅供参考和教育目的。它不能替代专业的网络安全审计或事件响应服务。在执行系统更新之前，请务必咨询官方供应商文档。
