GitLab 上周那个满分洞（CVE-2026-97229，CVSS 10.0，未授权 RCE），我写过一次——打哪儿、修哪个版本、修完要轮换 secrets（那条在这里）。这次补的不是技术细节，是一个更值得记的后续：Alpine Linux 被人真刀真枪打了，而且他们已经升到最新版，洞还在。

事情是这样的。10 月 20 到 21 号，Alpine 的 GitLab 实例被人拿 97229 打。攻击者做的事很"讲究"——专门把他们的 GitLab 容器镜像拉下来，自己搭环境调 exploit；打了四次，每次都卡在下一步崩掉，没能完全得手，但也没法完全排除代码执行。最后 Alpine 的处置是：实例整个重建，所有密码重置。

对，整个重建。不是打个补丁、重启一下。

原因就一句话：他们当时已经升到 GitLab 19.3.6 了——按理说 97229 的修复版本 19.3.5 早该盖住了——可漏洞还在。因为根因不在 GitLab 本身，在它依赖的 Ruby 的 Onigmo 正则引擎。GitLab 自带的那份 Ruby 修了，但你机器上真正参与编译正则的那份 Ruby，未必修了。

这就是"半拉补丁"最典型的样子：包管理器里显示的版本是对的，你对着 changelog 认为自己安全了，可真正出问题的那个组件，藏在下面一层。

影响版本：GitLab CE/EE 自建版，19.2 < 19.2.8、19.3 < 19.3.5、19.4 < 19.4.2。

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

修完还不算完：如果你用的是系统 Ruby 或自建镜像（不是 GitLab 自带的 embedded Ruby），还得把 Ruby 升到 ≥ 3.3.13 / 3.4.12 / 4.0.9。这一步最容易漏，因为它不在 GitLab 升级说明的显眼处。

还有一层：10/21 GitLab 又发了一批（19.5.1 / 19.4.3 / 19.3.6 / 19.2.9 / 19.1.9 / 19.0.10 / 18.11.13），修的是另一个洞 CVE-2026-110264，影响面能回溯到大约 12 年前的发行版。换个说法：10/12 刚打过 97229 补丁的机器，这周还得再升一次。

一条自查：

cat /opt/gitlab/embedded/service/gitlab-rails/VERSION 2>/dev/null || gitlab-rake gitlab:env:info 2>/dev/null | grep -i gitlab
/opt/gitlab/embedded/bin/ruby -v 2>/dev/null || ruby -v   # 确认是不是你系统里那份 Ruby

我要说的教训不是"GitLab 又有洞"。是："我升到最新版了"和"这个洞修好了"，是两件事。 前者看的是你包的版本号，后者看的是那条攻击路径上每一个组件——包括那些你没意识到自己也在用的东西。碰到满分洞，核对完版本号之后，多问一句"这条路上还有谁"，往往比单纯升级更有用。

参考：https://www.securityweek.com/max-severity-gitlab-vulnerability-exploited-against-alpine-linux/