GitLab 企业版曝出高危漏洞，AI 代理成攻击入口

八月下旬，GitLab 一口气推送了多个版本的安全补丁。这次更新的核心目标，是堵住企业版里一个评分达到 7.3 的漏洞 —— 编号 CVE-2026-18252。出问题的地方藏在 Duo Claude AI 代理的处理逻辑里，攻击者一旦得手，就能在 CI 管道里执行任意命令。

这个漏洞的杀伤力不容小觑。CI 环境通常掌握着源代码、构建产物、部署密钥、云令牌、制品库凭证等核心资产。命令执行权限落到攻击者手里，意味着整个研发基础设施都可能被翻个底朝天。

漏洞的利用门槛比想象中低。GitLab 官方确认，拥有开发者角色的已认证用户就能触发。Duo Claude AI 代理在处理配置时，没有对用户可控的来源做足够的安全校验，导致低权限用户有机会影响 CI 命令的实际执行。这种漏洞类型被归类为"包含来自不受信任控制域的功能"—— 说白了，就是程序信了不该信的数据。

受影响的版本跨度不小。GitLab EE 从 18.9 到 19.1.7、19.2 到 19.2.5、以及 19.3 到 19.3.1 都在射程之内。GitLab 在 8 月 26 日放出了 19.3.1、19.2.5 和 19.1.7 三个修复版本，强烈建议自托管用户立即升级。GitLab.com 已经跑在修复后的代码上，Dedicated 客户则不需要额外操作。

单节点部署的管理员要留个心眼。这次更新带了数据库迁移，升级过程中服务会短暂中断。多节点环境如果配置正确，可以走零停机升级流程，业务不会受影响。

这个漏洞由安全研究员 thwin_htet 通过 HackerOne 平台提交。截至目前，GitLab 没有公开技术细节、PoC 代码，也没有发现野外利用的迹象。但这并不意味着可以掉以轻心 —— 7.3 的 CVSS 分数摆在那里，机密性和完整性影响都是高危级别。

这次补丁其实是一揽子修复。除了 CVE-2026-18252，还解决了社区版和企业版共有的几个问题：导入管道中的拒绝服务缺陷、SCIM API 的 DoS 漏洞、受保护环境终端的访问控制不当、合规框架分配绕过、管道执行策略弱点，以及合并请求批准规则被重置的问题。虽然这些问题的严重程度参差不齐，但放在一起看，GitLab 这一轮的安全债清理得相当彻底。

更值得深思的是背后的趋势。AI 代理正在大规模嵌入开发者平台，它们不再是简单的代码补全工具，而是直接参与构建流程的自动化组件。一旦 AI 代理的配置或行为能被用户输入左右，它本质上就变成了一个代码执行基础设施。组织在享受 AI 提效的同时，必须把代理配置视为敏感权限来管控。

实际防护层面，有几件事现在就可以做。把 CI 作业隔离到独立的运行环境中，限制单条管道能接触到的密钥数量，对管道日志做异常命令执行的监控。AI 代理的配置权限也应该收紧，不是谁都能改、什么输入都能进。毕竟，当 AI 开始替你写代码、跑构建的时候，它身上的安全边界必须比人更严格，而不是更宽松。

GitLab 这次的事件给整个行业敲了一记警钟。AI 和 DevOps 的融合越深，攻击面就越隐蔽。一个看似无害的 AI 代理配置，可能就是通往生产环境的暗门。补丁已经发布了，剩下的就看各家运维团队的动作有多快了。