GitLab在10月12日发布了一组安全补丁，修掉一个评分满分的远程代码执行漏洞，编号CVE-2026-97229，CVSS评分10.0。问题出在CI/CD的正则表达式编译器上：由于正则校验不充分，未认证的攻击者可以向CI/CD配置文件里塞进一段特制的正则表达式，触发整数溢出，进而在服务器上以git账号的权限执行任意代码。
受影响的是自管理实例，涉及三条版本线：19.2系列的19.2.8之前、19.3系列的19.3.5之前、19.4系列的19.4.2之前。对应修复版本是19.2.8、19.3.5与19.4.2。官方同时说明，该产品的云端托管版本已经运行在修复后的版本上，专有部署的客户不需要额外操作。
这个漏洞的复现门槛值得留意。安全厂商Rapid7在补丁发布后做了验证，在未修补的官方镜像19.4.1上成功复现了任意代码执行，同一个输入打到19.4.2上就失效了。但它也补充了一个前提：攻击者需要能向公开项目的分支里提交恶意的CI配置文件，以及一个带UTF-8字符的仓库路径。在允许用户自行创建公开项目的自管理实例上，一个普通账号就能满足这个条件。
暴露面不算小。第三方资产测绘机构估算，当时互联网上大约有2.5万台主机、近8万条Web属性跑在受影响版本上。目前没有确认的在野利用记录，这个漏洞也还没有被收录进美国相关机构的已知被利用漏洞目录。也就是说，眼下是一个补丁窗口期，不是事后追溯。
处置路径其实不复杂。第一条是升级到修复版本，Rapid7建议自管理实例跳出常规补丁周期、尽快完成。第二条是暂时无法升级时的临时缓解：限制GitLab Web界面的入站访问，比如只允许可信网络或通过VPN进入；同时关掉不受信任用户的公开项目创建权限，把可以被利用的入口先堵上。
对运维来说，这件事里有两点比版本号更值得记。一是GitLab服务器上通常同时放着源代码、CI/CD密钥、部署凭据和镜像仓库令牌，一旦被拿下，损失不止一个应用的边界，这也是这条漏洞评分给到满分的原因。二是漏洞由一位化名joaxcar的研究者通过GitLab的漏洞赏金项目提交，同一人此前还报告过一个中危的开放重定向问题——自管理实例的补丁节奏，本质上取决于管理员跟得上跟不上上游的修复速度。
申请创业报道，分享创业好点子。点击此处，共同探讨创业新机遇！
