2026年10月28日 在10月20日和21日，攻击者试图在我们的实例上利用GitLab漏洞（CVE-2026-97229），该漏洞在修复发布一周后被利用。攻击差点成功。我们没有发现它成功的证据，但我们不能排除这种可能性，因此我们将该实例视为被攻破，并从头开始重建。我们的检查显示，aports库、包以及10月21日的发布没有遭到篡改。在我们向公众重新开放GitLab之前，正在进行测试。所有密码已重置，因此当它重新开放时，您需要在登录页面上使用“忘记密码？”设置一个新密码。重新开放时，我们会发布您需要做的确切步骤。与此同时：如果您在其他地方使用了与gitlab.alpinelinux.org账户相同的密码，请在那里进行更改。我们已经看到针对我们的GitLab进行的自动登录尝试，使用的是从其他网站泄露的密码。如果您有任何问题或疑虑，请通过infra@alpinelinux.org与我们联系。发生了什么 漏洞：CVE-2026-97229是GitLab在CI配置中评估正则表达式的一种关键性（CVSS 10.0）漏洞。根本问题出在内置于Ruby中的正则表达式引擎Onigmo。GitLab在10月12日发布了修复版本，但修复本身是对GitLab打包在自己包和容器镜像中的Ruby的一组补丁。上游Ruby在10月23日发布了修复，版本为Ruby 3.3.13、3.4.12和4.0.9。攻击：在10月20日和21日，一个新注册的账户向我们仍在运行19.3.4，且没有10月12日修复的GitLab实例发送了构造的CI配置。这导致GitLab工作进程崩溃了8次。在其中4次崩溃中，攻击者在利用过程中到了一定阶段，但在下一步失败。攻击者还下载了我们的GitLab容器镜像，这表明他们正在调整利用以适应我们的确切构建。我们没有发现攻击者在服务器上运行代码的证据，但我们不能排除这种可能性。我们的升级并没有修复漏洞：在10月22日升级到GitLab 19.3.6并没有修复漏洞。修复不在GitLab自己的代码中，而是在GitLab仅在其官方包中应用的Ruby补丁中。我们的镜像使用标准Ruby，因此没有获得补丁。如果您使用自己的Ruby（从源代码或在自己的容器镜像中）运行GitLab，而不是GitLab的包，升级GitLab是不够的：您还需要Ruby 3.3.13、3.4.12、4.0.9或更高版本。如果您使用我们的alpinelinux/gitlab容器镜像，请再次拉取alpinelinux/gitlab:19.3.6。10月27日发布的镜像包含Ruby 3.3.13。您在10月27日之前拉取的任何19.3.6镜像，以及所有较旧的标签，都是有漏洞的。事件时间线 日期 事件 10月28日 GitLab重建完成；所有密码重置，GitLab的密钥替换 10月27日 GitLab仅向开发人员和构建服务器开放；重建开始 10月26日 重建后发现实例仍有漏洞 10月25日至26日 攻击者返回并尝试重新进入；尝试失败 10月24日 对aports、包和10月21日发布进行了外部记录验证 10月23日 攻击者的账户被封锁；Ruby发布了修复 10月22日 升级到GitLab 19.3.6 10月21日 主要攻击；GitLab崩溃，502错误和失败的CI作业 10月20日 攻击者注册账户并开始探测 10月13日 发布CVE-2026-97229；我们错误地将版本升级到GitLab 19.3.4而不是19.3.5（后者包含修复） 10月12日 GitLab发布了修复 我们所知道的和无法排除的 我们发现 Alpine发布和包没有被修改。10月21日的稳定版本（3.21.9、3.22.7、3.23.7、3.24.3），包括它们的ISO镜像和官方alpine Docker镜像构建的minirootfs tarballs，以及10月20日至24日之间构建的所有包，均来自我们与GitLab之外的记录验证的aports提交。有关详细信息，请参见下面的FAQ。没有签名密钥被曝光。签署Alpine包和发布的密钥没有，并且从未存储在GitLab服务器上。没有证据表明攻击者的代码被执行：时序探测显示没有延迟，我们未发现任何意外文件、密钥、钩子或进程。通过我们能看到的任何Web或API请求没有机会返回私人数据给攻击者。 我们不能确定的原因 成功的利用将不会留下崩溃和Web日志中的任何痕迹。攻击当天的一些日志丢失（后台作业日志，旧容器的文件系统）。我们没有对出站网络连接进行日志记录，我们的托管提供商也不保留。 如果攻击成功，可能会泄露的内容 用户的电子邮件地址、姓名和IP地址 密码哈希 2FA密钥、CI/CD变量和运行器令牌 Webhook、集成和推送镜像凭证 个人访问令牌（以哈希形式存储） 私有存储库以及机密问题和合并请求 FAQ 为什么在能够减轻攻击时还要重建GitLab？