GitLab 爆出 CVSS 10 分满分漏洞：12 年前的正则引擎整数溢出，根因竟在 Ruby/SUENCA

一周之内，GitLab 连爆两个满分漏洞

对自建 GitLab 的团队来说，10 月这一周过得有点刺激。先是 10 月 12 日，GitLab 修掉了一个 CI/CD 正则编译器里的整数溢出远程执行漏洞（CVE-2026-97229）；仅仅 9 天后的 10 月 21 日，它又发了一版紧急补丁，修掉的是另一个同样能在未认证状态下远程执行代码的整数溢出漏洞 CVE-2026-110264，CVSS 直接拉满 10.0。

两个漏洞长得像孪生兄弟：都是整数溢出、都出在「正则表达式编译」这条路上、都能让未认证攻击者 RCE。这本身就值得警惕——当同一类 bug 在短时间内连续出现，往往说明它不是一个孤立的失误，而是一个被行业普遍低估的底层隐患。

这一次，问题可以追溯到 12 年前

CVE-2026-110264 最吓人的地方，是它的影响跨度。受影响范围覆盖了 GitLab CE/EE 从 7.0 一直到 19.5.1 之前的一大片版本——而 GitLab 7.0 是 2014 年 6 月发布的，整整 12 年前。也就是说，一个藏了十二年的整数溢出，一直静静埋在正则编译这条必经之路上。

精确的受影响区间：从 7.0 到 18.11.13 之前、19.0 到 19.0.10 之前、19.1 到 19.1.9 之前、19.2 到 19.2.9 之前、19.3 到 19.3.6 之前、19.4 到 19.4.3 之前、19.5 到 19.5.1 之前。补丁版本为 19.5.1 / 19.4.3 / 19.3.6，并向下回移植到 19.2.9、19.1.9、19.0.10 和 18.11.13。

真正扎心的，是根因不在 GitLab 自己

多位安全研究者点破了一个细思极恐的事实：这个漏洞的根，扎在 Ruby 的正则引擎里，而不只是 GitLab 的业务代码。GitLab 的补丁说明里，修复是被「打到 Ruby 的正则处理」上的；官方放出的检测规则里，有一条名字直接叫 Onigmo——那是 Ruby 底层的正则库。

这意味着两件事：

第一，GitLab 只是「碰巧先被暴露」的那个——任何用 Ruby 解析不可信正则表达式的 Web 应用，理论上都可能带着同一个雷；
第二，这本质上是一起「依赖供应链」风险：你的代码写得再稳，底层语言/库的老 bug 一样能把你拖下水，而且这种 bug 一埋就是十几年。

这也解释了为什么「自己做代码审计」救不了这类问题：它是语言运行时的底层缺陷，普通项目根本看不到、也改不了，只能等上游打补丁，然后你尽快升级。

为什么正则编译器这么容易翻车

整数溢出听着高深，本质很简单：正则引擎在编译一个「恶意构造的正则表达式」时，内部算出一个越界的长度或大小，导致内存被错误分配或访问。而正则编译又是几乎所有 Web 应用绕不开的功能——搜索、校验、路由匹配、CI 配置文件解析，处处都要把「外部给的字符串」当成正则来处理。

关键风险在于：攻击者要做的，只是提交一个精心构造的正则表达式。不需要登录、不需要权限、不需要上传文件。GitLab 这次的评分向量是 AV:N/AC:L/PR:N/UI:N/S:C/C:H/I:H/A:H——网络可达、复杂度低、无权限、无交互，影响范围还跨组件。

自建者现在该做什么

GitLab.com 和 GitLab Dedicated 都已提前打好补丁，最危险的是自建（self-managed）实例——而自建恰恰是很多公司为了合规、内网隔离而普遍采用的方式，也最容易在「内网不用急着更新」的惯性里被漏掉。

建议三步走：

立刻升级到 19.5.1 / 19.4.3 / 19.3.6（或对应回移植版本 19.2.9 / 19.1.9 / 19.0.10 / 18.11.13）；
优先排查公网暴露面，内网实例也按「可能被横向波及」对待，别抱侥幸；
做一次失陷排查：GitLab 官方已发布两条检测规则，重点看 Onigmo worker 崩溃、GraphQL 恶意正则、CI regexp 异常等痕迹。

顺带一提：这个漏洞是安全研究员 joaxcar 通过 GitLab 的 HackerOne 赏金计划报告的——也再次说明，悬赏众测在「挖老底层 bug」这件事上，效率相当可观。