上个月 10/12 那波 GitLab 满分洞，不少人刚把补丁打上。这个月 10/21，又来一个。

CVE-2026-110264，同样是 CVSS 10.0 的未认证远程代码执行，同样出在 GitLab，同样是一条构造过的正则。区别在于这回根子更深：问题不在 GitLab 自己写的代码里，而在它内置的 Ruby 正则引擎 Onigmo 上。攻击者给一段重复次数特别夸张的正则，引擎在算「需要多少内存」时整型溢出，算出来的缓冲区尺寸偏小，后面往里写就越了界，一路走到 RCE。

最早能追到 2014 年的 7.0——这个洞埋了 12 年。公开分析里提到，触发路径大概率是 Org 模式文件渲染：往一个公开仓库里提交一份带恶意正则的 Org 文件，别人渲染预览的时候就触发，全程不需要登录。

撑不住这么大的跨度，GitLab 这次破了例，把补丁回植到 7 个分支（平时只维护最新的三个）：19.5.1、19.4.3、19.3.6、19.2.9、19.1.9、19.0.10、18.11.13。没有临时缓解方案，只能升级。

真正值得琢磨的，是「白忙活」这层。10/12 刚修过同类的 CVE-2026-97229，也是正则引擎、也是满分，那次只覆盖到 19.2 以上；打过那次补丁的机器，这次照样中。再往上看，同一个研究员 joaxcar，一个月里报了 4 个 GitLab 正则引擎 RCE（9/23 两个 9.9、10/12 一个 10.0、这次又是 10.0）。这已经不是某一个 bug 了，是一整类系统性缺陷——修好一个，不代表这一类就清干净了。

影响版本：自建（self-managed）GitLab CE / EE，低于 18.11.13、19.0.10、19.1.9、19.2.9、19.3.6、19.4.3、19.5.1 的版本。

修复版本：19.5.1 / 19.4.3 / 19.3.6 / 19.2.9 / 19.1.9 / 19.0.10 / 18.11.13（2026-10-21 发布）。

一条自查：

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

或者管理员登录后看 /help 页，版本号直接印在上面。Shadowserver 追踪到公网上还暴露着 2700 多台自建 GitLab；截至 10/22 还没见在野利用、也没进 CISA 的 KEV 名单——但这不是能等的理由，没有缓解方案的时候，升级就是唯一选项，升之前照例先备份。

一个多星期前那个 GitLab 10.0 分洞我们写过（一段 .gitlab-ci.yml 里的正则就能拿服务器），当时留了一句「补丁管理不是打一次就完」。这回算是把这句话又验了一遍。同类的事也在别处反复：上周 PHP 引擎自己那个洞，道理是一样的——出问题的常常不是业务代码，是底下那层平时没人盯的基础组件。

参考来源：https://www.cnblogs.com/zktq/p/23412246 ｜ GitLab 官方 2026-10-21 安全发版公告