满分漏洞这回不是纸上谈兵了，是真有人上手试了。 Alpine Linux 那边披露的：10 月 20–21 日，一个新注册的账号，冲着它那台还在跑 19.3… · @Younik4we · TwKit

@Younik4we

满分漏洞这回不是纸上谈兵了，是真有人上手试了。 Alpine Linux 那边披露的：10 月 20–21 日，一个新注册的账号，冲着它那台还在跑 19.3.4 的 GitLab 实例发精心构造的 CI 配置——就是那个 GitLab CI 配置正则表达式编译器整数溢出、CVSS 10.0 满分的 CVE-2026-97229。结果工作进程崩了 8 次，里面有 4 次是攻击者都推进到下一步了才失败。 更扎心的一点是，攻击者还把 Alpine 的 GitLab 容器镜像下载下来了，疑似在照着它这个具体构建调利用。先说清楚两边：目前没发现攻击者在服务器上执行代码的证据，但也不能排除。 真正该让自建 GitLab 的人警醒的，是后面的坑。Alpine 10 月 22 日升级到 19.3.6，结果还是没修好。为啥？因为修复不光在 GitLab 版本里，还在 GitLab 官方包捆绑的 Ruby 补丁里——你自己用标准 Ruby 构建的镜像，压根吃不到这个修复。 所以别只盯着 GitLab 版本号看，Ruby 也得对上：必须是 Ruby 3.3.13、3.4.12、4.0.9 或更新版。Alpine 10 月 27 日发布的 19.3.6 镜像已经带了 Ruby 3.3.13，之前拉取的镜像仍然有风险，该换就换。 时间线再捋一下：GitLab 是 10 月 12 日发布修复版本 19.2.8、19.3.5、19.4.2 的，http://GitLab.com 也已经修了。你要是还在跑 19.3.4 这种没打 10 月 12 日补丁的版本，别拖了。 自建 GitLab 的朋友，今天就查两件事：GitLab 是不是 19.2.8、19.3.5、19.4.2 或更新版，Ruby 是不是 3.3.13、3.4.12、4.0.9 或更新版。两个都对上，才算真的修好了。

曝光 180 · 评论 5 · 点赞 4 · 书签 1