Alpine Linux 於 2026 年 10 月 28 日公布一宗 GitLab 安全事故。攻擊者於 10 月 20 日及 21 日，向其仍運行 GitLab 19.3.4 的實例投遞特製 CI 設定，企圖利用嚴重漏洞 CVE-2026-97229，導致 GitLab 工作程序八次崩潰，其中四次已越過部分利用步驟[1]。專案團隊表示未發現攻擊成功的證據，但無法排除，因此把實例當作已被入侵，並由零重建。
漏洞與攻擊經過
CVE-2026-97229 的 CVSS 評分為 10.0，問題出在 GitLab 評估 CI 設定中正規表達式的方式，根源是 Ruby 內建的正規表達式引擎 Onigmo[1]。GitLab 已於 10 月 12 日發布修正版本，但 Alpine 在 10 月 13 日更新時誤升至 19.3.4，而非含修正的 19.3.5，令實例持續暴露。
攻擊者在 10 月 20 日註冊帳戶並開始試探，翌日送出特製 CI 設定，令背景工作程序反覆崩潰，並出現 502 錯誤與 CI 工作失敗。攻擊者亦下載了 Alpine 的 GitLab 容器映像，團隊認為此舉是為了針對其實際建置調整利用方式[1]。
升級 GitLab 為何仍未修好
團隊在 10 月 22 日升至 GitLab 19.3.6，但 10 月 26 日覆核時發現實例仍然存在漏洞。原因在於修正並非落在 GitLab 自身程式碼，而是 Ruby 的修補；GitLab 只在官方套件中套用該修補，而 Alpine 的映像使用標準 Ruby，因此未取得修正[1]。
Ruby 上游最終於 10 月 23 日，在 3.3.13、3.4.12 及 4.0.9 版本中發布修正[3]。Alpine 指出，若自建 GitLab 使用自行編譯或自製容器映像的 Ruby，單靠升級 GitLab 並不足夠，必須同時把 Ruby 升至上述版本或更新[1]。使用 alpinelinux/gitlab 映像者，則需重新拉取 19.3.6；只有 10 月 27 日之後發布的映像才含 Ruby 3.3.13，較早拉取的同一標籤仍然有漏洞。
已核實與仍無法排除的部分
團隊在 10 月 24 日以 GitLab 以外的紀錄核對 10 月 20 日至 22 日的 aports 提交，以及 10 月 20 日至 24 日各架構的套件建置。結果顯示 10 月 21 日的穩定版本（3.21.9、3.22.7、3.23.7、3.24.3）、其 ISO 與 minirootfs 均無被篡改；用於簽署套件與版本的簽鑰亦從未存放於 GitLab 伺服器[1]。
不過團隊列出三項無法排除的理由：成功的利用不會留下崩潰或網頁日誌痕跡；攻擊當日的部分日誌，包括背景工作記錄與舊容器的檔案系統，已經遺失；主機與供應商均無對外連線日誌。若攻擊實際成功，可能外洩的資料包括用戶電郵、姓名、IP 位址、密碼雜湊、雙重驗證密鑰、CI/CD 變數、runner 權杖、webhook 與整合憑證，以及私人倉庫與機密議題[1]。
自建 GitLab 用戶要注意
Alpine 已重建實例並更換 GitLab 密鑰，所有密碼重設，重開後需以「忘記密碼」設定新密碼。團隊亦提醒曾在其他網站使用同一密碼者應一併更改，因為已觀察到以其他網站外洩密碼嘗試登入的自動化行為[1]。
對外自建 GitLab 的機構可跟隨三項檢查：確認 Ruby 版本是否已達 3.3.13、3.4.12 或 4.0.9；若使用自製映像，確認建置時有套用 Ruby 修補；以及核對 GitLab 官方公告所列的修正版本[2]。Alpine 同時表示會把重大 GitLab 安全版本的套用時間縮短至一日內，延長日誌保留期，並為版本標籤加入簽署。
參考資料
[1] GitLab security incident: attempted exploitation of CVE-2026-97229（2026 年 10 月 28 日）