Alpine Linux 重建 GitLab：CI 漏洞敲響供應鏈警號
iThome 報道指出，Alpine Linux 的自建 GitLab 曾遭攻擊者透過惡意 CI 設定，嘗試利用 CVE-2026-97229 遠端執行程式碼。報道稱，攻擊集中於 10 月 20 至 21 日，造成 GitLab 工作程序多次當機，部分嘗試曾進入「部分利用」階段。
目前沒有證據顯示攻擊者已成功執行程式碼，或曾修改原始碼儲存庫、套件和已發布軟件。這項限制很重要：事件不能直接描述為供應鏈已被攻陷。不過，iThome 指出部分日誌遺失，令團隊無法完全排除入侵可能；Alpine Linux 因而在 10 月 27 日關閉服務，重建 GitLab server、重設帳戶密碼及更換機密金鑰，至 10 月 29 日恢復服務。
問題不只在 GitLab 版本
iThome 報道將事件歸因於 CVSS 10.0 的 GitLab 漏洞未及時修補，並提到攻擊者曾下載 GitLab 容器映像檔，可能用作研究攻擊手法。報道同時出現 19.3.4、19.3.5 及其後升級至 13.9.6 的版本說法，彼此並不一致；因此，外界現階段不宜據此自行判定確切受影響版本或修補路徑。
但報道所描述的另一個環節更具普遍性：即使管理員更新了 GitLab，自建容器若沒有一併納入所需 Ruby 修補，漏洞仍可能存在。對使用容器部署 CI 的團隊而言，這意味著「更新產品版本」與「確認實際執行映像及其相依套件已修補」是兩件事。
對自建 CI 團隊的啟示
CI 平台接觸原始碼、建置程序、套件發布權限與部署機密；一旦攻擊者能讓 pipeline 執行非預期程式，即使未即時改動儲存庫，也可能把風險延伸至憑證、發布流程和下游套件。這是本次事件最值得 DevOps 與資安團隊留意的供應鏈面向。
在 iThome 所述的情況下，較審慎的應對次序包括：
- 依官方安全公告核實實際 GitLab 版本與受影響範圍，避免只按容器標籤判斷。
- 檢查運行中的容器映像、Ruby 與其他相依套件，確認修補已真正進入部署環境。
- 審閱近期新帳戶、CI 設定變更、失敗或異常 pipeline，以及 GitLab 工作程序當機前後的記錄。
- 如日誌不足以排除機密外洩，輪換 GitLab 帳戶密碼、存取權杖、部署金鑰及發布憑證，並重新檢視其權限。
這些做法未必代表 Alpine Linux 已出現程式碼或套件遭竄改，卻反映在 CI 基礎設施出現高風險漏洞時，單靠「未發現入侵」不足以完成風險處置。接下來值得觀察的是，官方公告能否釐清受影響版本及完整修補條件，以及其他自建 GitLab 環境會否發現相近的 CI 異常紀錄。
延伸閱讀
AI 輔助說明： 本文由 AI 協助整理，並經兩輪獨立自動品質審核；資料及連結仍以原始來源為準。
參考來源
- iThome — Alpine Linux遭GitLab重大漏洞攻擊，重建開發基礎設施防範供應鏈風險 — original report
本文根據原文及公開資料整理；資料有出入時，以原文及官方資料為準。
