GitLab 出了一个满分洞。

CVSS 10.0，未授权远程代码执行，编号 CVE-2026-97229。攻击面不在别处，就在几乎每个项目都会有的 .gitlab-ci.yml 里——一段构造过的正则，就能让 CI/CD 的正则编译器整型溢出，最终在服务器上执行任意代码。不需要账号，也不需要任何交互。

这个洞随 2026-10-12 的修复版一起公开，之后 Rapid7 放出了 PoC 分析。Censys 的统计是，暴露在公网上的自建 GitLab 实例大约 2.6 万台——还在自建 CI/CD 的团队，这周该看一眼自己的版本号了。

影响的版本：自建（self-managed）GitLab。

修复版本：19.2.8 / 19.3.5 / 19.4.2（2026-10-12 已发布）。

修完还有一件事：轮换相关的 secrets。这类 RCE 一旦被利用，落在 CI 环境里的令牌、密钥都该按"已泄露"处理，光升级不换等于门修好了、钥匙还插在锁上。

自查一条命令：

cat /opt/gitlab/embedded/service/gitlab-rails/VERSION

或者用管理员登录后访问 /help，页面上会直接显示版本号。

如果你是 Omnibus 包，升级就是标准的包管理器升到上面那几个版本，升级前照例备份。这次 19.x 是一次常规安全发版，同时修了好几个问题，别只盯着这一个洞。

为什么会值得单独写一篇：满分漏洞本就少见，更少见的是攻击面这么"日常"——一个 CI 配置文件。这两年的教训反复是同一句话：出事的往往不是最核心的那个服务，而是它周边那些"顺手就开了"的组件。 PHP 引擎、GitLab 的 CI、nginx 的一个指令，都是这个道理。

要管的机器一多，版本核对最麻烦的往往不是"查"，而是查完要记住、要比对——这种事我后来是丢给七亿批量远程管理工具这类工具去做的，一次把几十台的 nginx -v、php -v 捞回来，扫一眼就知道谁该升级。至于漏洞本身怎么打补丁，还是那句老话：先确认影响版本，再对修复版本，最后留一条自查命令——说明书里这些命令都按"每条看什么"标了一遍。