Alpine Linux GitLab 服務遭遇 CVE‑2026‑97229 攻擊，已重建並重設密碼
GitLab Security Incident: Attempted Exploitation of CVE-2026-97229
Alpine Linux 針對 CVE‑2026‑97229 在 GitLab 服務上進行的近乎成功攻擊，已採取重建與密碼重設措施，並確認未被利用。
- 漏洞：CVE‑2026‑97229，CVSS 10.0，源於 Ruby Onigmo 正規表示式引擎。
Alpine Linux 迅速重建 GitLab 服務並重設密碼，證實未被成功利用 CVE‑2026‑97229，凸顯即時修補與完整驗證的重要性。
2026-10-28
於10月20日及21日，攻擊者嘗試利用我們例項上的 GitLab 漏洞 (CVE-2026-97229)，距離修復發布已經過一週。攻擊接近成功。雖未發現成功證據，但仍無法排除，故我們將例項視為已受攻擊並從頭重建。檢查顯示 aports 儲存庫、套件以及 10 月 21 日的釋出未被篡改。
GitLab 正在測試中，待重新開放給公眾使用。所有密碼已重設，因此回復後您需要在登入頁面使用「忘記密碼？」設定新密碼。我們將在重新開放時公佈具體操作步驟。此期間：若您在其他地方使用相同密碼登入 gitlab.alpinelinux.org 帳號，請在那裡更改。已發現有自動化登入嘗試，使用來自其他網站洩漏的密碼。
如有任何疑問或顧慮，請聯絡 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 日，一個新註冊帳號向我們的 GitLab 例項傳送精心設計的 CI 設定，該例項仍執行 19.3.4 且未安裝 10 月 12 日的修正。這導致 GitLab 工作程序崩潰 8 次，其中 4 次攻擊者已進入漏洞利用流程但在下一步失敗。攻擊者亦下載了我們的 GitLab 容器映像，暗示他們正調整漏洞利用以符合我們的精確版本。我們未發現攻擊者在伺服器上執行程式碼的證據，但仍無法排除。
升級並未修復漏洞： 於 10 月 22 日升級至 GitLab 19.3.6 並未修復漏洞。修正並不在 GitLab 自身程式碼，而是對 Ruby 的補丁，GitLab 只在官方套件中套用此補丁。我們的映像使用標準 Ruby，因而未獲得此修正。
若您使用自己的 Ruby（自原始碼或自建容器映像）而非 GitLab 套件，升級 GitLab 並不足以解決問題：您還需要 Ruby 3.3.13、3.4.12、4.0.9 或更新版本。
若您使用我們的 alpinelinux/gitlab 容器映像，請再次 pull alpinelinux/gitlab:19.3.6。10 月 27 日發布的映像包含 Ruby 3.3.13。任何在 10 月 27 日之前 pull 的 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 映像檔以及官方
alpineDocker 映像所使用的 minirootfs tarball，所有於 10 月 20 日至 24 日之間建置的套件均來自我們已驗證的 aports commits，並與 GitLab 之外的紀錄相符。請參閱下方 FAQ 以瞭解更多細節。 - 未有任何簽章金鑰外洩。 用於簽署 Alpine 套件與版本的金鑰並未、也不曾存放於 GitLab 伺服器。
- 沒有任何證據顯示攻擊者程式碼已執行：時間探測顯示無延遲，我們亦未發現任何意外檔案、金鑰、掛勾或程序。
- 我們所能觀察到的任何網頁或 API 請求都未將任何私密資料回傳給攻擊者。
為何我們無法確定
- 一次成功的利用將不會留下任何崩潰或網頁日誌痕跡。
- 攻擊當日的一些日誌已遺失（背景工作日誌、舊容器的檔案系統）。
- 我們沒有記錄外向網路連線，且我們的託管服務商亦未保留任何相關紀錄。
若攻擊成功，可能外洩的資訊
- 所有使用者的電子郵件地址、姓名與 IP 位址
- 密碼雜湊值
- 雙因素認證金鑰、CI/CD 變數與執行器 token
- Webhook、整合與推送映象的憑證
- 個人存取 token（以雜湊值儲存）
- 私人儲存庫，以及機密的問題與合併請求
常見問題
為什麼在能夠緩解攻擊的情況下仍然重建 GitLab？
因為我們無法排除程式碼執行的可能性，且確認其不存在所需的證據已不復存在，我們選擇較困難的路徑，從頭重建 GitLab 例項。這樣可消除任何可能成功利用的攻擊留下的蹤跡。
在 GitLab 關閉期間，我們的套件映象、cgit 以及郵件列表/IRC 仍正常可用。
Alpine 套件與發行版是否受到影響？
我們在 aports 或發行版中未發現任何篡改跡象。
從 10 月 20 日至 22 日新增的每一個 aports 提交都是透過已記錄的推送由已知開發者完成。我們已將其與攻擊者無法存取的紀錄做比對：開發者的 clone 以及所有 45 個建置機。從 10 月 20 日至 24 日、所有架構建置的每個套件皆來自 git.alpinelinux.org 上公佈的提交。10 月 21 日的發行版（3.21.9、3.22.7、3.23.7、3.24.3）亦是以同一組已驗證的提交建置。
我們於 10 月 24 日執行了這些檢查，涵蓋 10 月 20 日至 22 日的提交以及至 10 月 24 日建置的套件。GitLab 在 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 進行驗證。