Alpine Linux 官方近日披露了一起针对其 GitLab 实例的安全事件。在 10 月 20 日至 21 日期间，攻击者试图利用严重漏洞 CVE-2026-97229 入侵系统。尽管目前未发现攻击成功的直接证据，但出于安全谨慎原则，团队已将该实例视为“受损”状态，并执行了从头开始的重建工作。
初步检查显示，GitLab 上的代码仓库、软件包以及 10 月 21 日发布的版本未被篡改。但在重新向公众开放前，所有用户密码已被强制重置。用户需在登录页面通过“忘记密码”功能设置新凭证。此外，鉴于检测到有外部泄露的密码被用于尝试自动登录 Alpine GitLab，建议用户在其它平台若使用相同密码，也立即进行更改。
漏洞详情与攻击过程
CVE-2026-97229 是 GitLab 中一个 CVSS 评分高达 10.0 的严重漏洞，源于 Ruby 内置正则表达式引擎 Onigmo 在评估 CI 配置时的缺陷。GitLab 已于 10 月 12 日发布修复版本，但该修复主要针对其官方软件包和容器镜像中捆绑的 Ruby 进行了补丁处理。上游 Ruby 项目则在 10 月 23 日于 Ruby 3.3.13、3.4.12 和 4.0.9 版本中发布了根本性修复。
攻击发生在 10 月 20 日和 21 日，一个新注册账户向 Alpine 的 GitLab 实例发送了精心构造的 CI 配置文件。这导致 GitLab 工作进程崩溃 8 次。其中 4 次崩溃表明攻击者突破了漏洞的一半，但在后续步骤失败。攻击者还下载了 GitLab 容器镜像，暗示其正在调整攻击载荷。虽然未证实攻击者在服务器上成功运行代码，但也无法完全排除这一可能性。
值得注意的是，简单的版本升级并未立即解决问题。10 月 22 日升级到 GitLab 19.3.6 后，漏洞依然存在。原因在于该解决方案依赖于对 Ruby 本身的补丁，而 Alpine 使用的标准 Ruby（非 GitLab 官方捆绑版）当时尚未应用此补丁。因此，对于自行构建 Ruby 或使用自定义容器镜像运行 GitLab 的用户，仅升级 GitLab 是不够的，必须将 Ruby 更新至 3.3.13、3.4.12、4.0.9 或更高版本。同时，使用 alpinelinux/gitlab 容器镜像的用户需重新拉取 10 月 27 日后发布的 alpinelinux/gitlab:19.3.6 镜像，此前拉取的旧标签均存在风险。
事件时间线
| 日期 | 事件 |
|---|---|
| 10 月 28 日 | 完成 GitLab 重建；所有密码重置及秘密密钥更换完毕 |
| 10 月 27 日 | 除开发人员和构建服务器外，GitLab 对所有用户关闭；重建工作开始 |
| 10 月 26 日 | 确认升级后实例仍易受攻击 |
| 10 月 25-26 日 | 攻击者再次尝试进入，未能成功 |
| 10 月 24 日 | 对外部记录进行验证 |
| 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 团队确认以下事实：
- Alpine 的软件包和发布文件未被修改。10 月 21 日的稳定版本（3.21.9, 3.22.7, 3.23.7, 3.24.3）及其 ISO 镜像、minirootfs tarballs 均为官方构建基础。10 月 20 日至 24 日构建的所有包均来自经独立验证的 aports commit。
- 签名密钥未泄露。签署 Alpine 软件包和发布的密钥从未存储在 GitLab 服务器上。
- 无代码执行证据。时间探测器显示无异常延迟，未发现攻击者代码运行的迹象。
- 无数据外泄证据。在网络或 API 请求日志中，未发现私有数据返回给攻击者的情况。
然而，由于技术限制，部分不确定性无法完全消除：
- 成功的漏洞利用可能不会在网络日志中留下明显痕迹。
- 部分关键日志（如后台工作日志、旧容器文件系统）已丢失。
- 出站网络连接未被记录，托管提供商亦无相关日志。
若攻击最终成功，理论上可能暴露的信息包括：所有用户的电子邮件地址、姓名和 IP 地址；密码哈希值；2FA 秘密、CI/CD 变量和运行符号；网络连接、集成及推送镜像凭证；个人访问令牌（存储为哈希）；以及私人存储库、机密问题和合并请求等内容。
常见问题解答 (FAQ)
既然未发现明确入侵证据，为何要重建 GitLab？
因为无法排除代码执行的可能性，且所需的取证证据已不存在。为了彻底消除潜在的后门或持久化威胁，重建是最安全的措施。在 GitLab 关闭期间，包镜像、cgit 以及邮件列表/IRC 服务保持正常运行。
Alpine 的软件包和发布是否受到影响？
未发现任何篡改迹象。10 月 20 日至 22 日添加的所有 aports commit 均通过已知开发者推送到达，并与攻击者无法获取的记录（如开发者克隆副本及 45 个构建者节点）进行了比对验证。10 月 21 日的发布基于同样的经过验证的提交。这些检查涵盖了直至 10 月 27 日实例关闭前的时间段。
Alpine 中的 Ruby 包是否受影响？
该漏洞位于 Ruby 的正则表达式引擎中，任何从不可信输入编译正则表达式的程序均面临风险，不仅限于 GitLab。目前，Alpine 3.22、3.23、3.24 和 edge 版本搭载的 Ruby 3.4.12，以及 Alpine 3.21 搭载的 Ruby 3.3.13，均已包含修复补丁。用户只需运行 apk upgrade 即可获取更新。
此次事件后有哪些改进措施？
- 修复 Ruby 环境：重建后的实例运行已修复的 Ruby 版本（3.3.13 或更高）。
- 加快补丁响应：承诺在一天内应用关键的 GitLab 安全版本，并仔细审查每次发布中 Ruby 或其他组件的补丁是否需要在自建环境中应用。
- 增强日志记录：记录来自 GitLab 主机和数据库连接的输出连接，并将日志保存期限延长至 14 天以上。
- 签名发布标签：对发布标签进行签名，以便独立于 GitLab 进行验证。
