攻擊者嘗試利用 Alpine Linux GitLab CVSS 10.0 漏洞，Ruby 未修補

攻擊者試圖在 Alpine Linux 專案自己的 GitLab 伺服器上利用一個嚴重的 GitLab 漏洞，距離 GitLab 發布修正 之後一週，Alpine Linux 表示，於 10 月 28 日。

此缺陷，CVE-2026-97229（CVSS 分數：10.0），可讓攻擊者透過在 CI 配置中使用精心設計的正規表示式，在 GitLab 伺服器上執行程式碼。Alpine 沒有發現攻擊成功的證據，但無法排除可能性，因此重新從頭構建伺服器並重設所有帳戶密碼。

GitLab 的修正 是一套套補丁，針對 GitLab 在其自有套件與容器映像中所提供的 Ruby。Alpine 的 GitLab 映像使用標準 Ruby，因此於 10 月 22 日將伺服器升級至 GitLab 19.3.6 時，並未修復此缺陷。

Alpine 表示，對於任何在自有 Ruby 上執行 GitLab、從原始碼編譯或在自有容器映像中執行的人來說，"升級 GitLab 並不足夠"。這些伺服器還需要 Ruby 3.3.13、3.4.12、4.0.9 或更高版本，而使用 Alpine 的 alpinelinux/gitlab 映像的使用者則需要再次拉取 19.3.6。

伺服器 gitlab.alpinelinux.org 主機 aports，這是 Alpine 套件建置的來源倉庫。根據 Alpine，20 至 24 月 10 日以及 10 月 21 日的發行版，都是來自於經過 GitLab 之外的記錄驗證的 aports 變更。

這些發行版包含官方 Alpine Docker 映像所使用的 minirootfs 檔案。Alpine 正將檢查延伸至 10 月 27 日，當時其關閉了伺服器。簽署其套件與發行版的金鑰從未存在於 GitLab 伺服器上。

攻擊過程

10 月 13 日，Alpine 將伺服器升級至 GitLab 19.3.4 而非 19.3.5，這被其稱為一個錯誤。伺服器仍處於該版本，且未安裝 10 月 12 日的修正，當一個新註冊帳戶於 10 月 20 日開始探測時。

該帳戶於 10 月 20 日和 21 日向伺服器傳送精心設計的 CI 配置。這些配置使 GitLab 工作者程序崩潰 8 次，且 10 月 21 日的主要攻擊還導致 502 錯誤，使 CI 任務失敗。

根據 Alpine，四次崩潰中，攻擊者在利用過程中部分完成，但在下一步失敗。攻擊者還下載了 Alpine 的 GitLab 容器映像，Alpine 說：「這表明他們正在將利用技巧調整到我們的精確建置」。

Alpine 於 10 月 23 日封鎖該帳戶。攻擊者於 10 月 25 日和 26 日再次嘗試登入，但這些嘗試失敗，Alpine 表示。

10 月 26 日，Alpine 發現伺服器在 10 月 22 日升級至 19.3.6 後仍然脆弱。次日，它將 GitLab 關閉給所有人，僅允許開發人員和建置伺服器使用，並開始重新構建。

重新構建於 10 月 28 日完成。Alpine 還更換了 GitLab 的機密金鑰，且重新構建的伺服器執行 Ruby 3.3.13 或更高版本，該版本已包含修正。Alpine 正在測試，待通過後再向公眾開放。

Alpine 能排除與不能排除的情況

Alpine 沒有發現攻擊者程式碼在伺服器上執行的跡象。時間探測顯示沒有延遲；沒有任何意外檔案、金鑰、掛鉤或程序；且沒有任何私密資料透過任何 Web 或 API 請求回傳給攻擊者，Alpine 可見範圍內。

但無法確定。Alpine 表示，"一次成功的利用不會留下崩潰或任何網頁日誌痕跡"。部分攻擊日的日誌已遺失，包括背景工作日誌與舊容器的檔案系統，且 Alpinelinux 或其託管服務商均未記錄出站網路連線。

因為確認程式執行所需的證據已不存在，Alpine 將該伺服器視為已被攻陷並重新建置，以移除任何成功利用可能留下的根據點。

若攻擊成功，以下資訊可能被外洩：

• 所有使用者的電子郵件地址、姓名與 IP 位址
• 密碼雜湊值
• 雙因素驗證秘密、CI/CD 變數與執行器令牌
• Webhook、整合與推送映象憑證
• 個人存取令牌（以雜湊形式儲存）
• 私人倉儲，以及機密的問題與合併請求

除了重設密碼與新增秘密金鑰外，Alpine 尚未說明伺服器上儲存的執行器令牌、CI/CD 變數、存取令牌或整合憑證是否已被替換。

為檢查其套件，Alpine 確認 10 月 20 日至 22 日期間新增的每一項 aports 變更，皆透過已記錄的推送由已知開發者完成。它將此與攻擊者無法存取的紀錄做比對：開發者的倉儲副本與所有 45 臺建置伺服器。10 月 20 日至 24 日期間建置的每一套件，皆來自於 git.alpinelinux.org 上公佈的 aports 變更。

為何 GitLab 升級未能修復此漏洞

GitLab 在 CI 設定中使用 Ruby 編譯正規表示式，而 CVE-2026-97229 背後的錯誤位於 Ruby 內建的正規表示式引擎 Onigmo。

GitLab 10 月 12 日的發布版透過修補 GitLab Linux 套件與容器映像中的 Ruby，修復了此問題。Ruby 本身的 已修復版本於 10 月 22 日與 23 日發布。

GitLab 升級並不會改變伺服器自身的 Ruby，故在標準 Ruby 上安裝 GitLab 仍保留此缺陷，直至 Ruby 本身更新至已修復版本，如 Alpine 所發現。

GitLab 的已修復 Linux 套件與官方容器映像皆包含已修補的 Ruby。自行編譯安裝，或像 Alpine 那樣分別安裝 Ruby 的容器映像，則不會得到此修補。

截至 10 月 29 日，GitLab 於 10 月 12 日與 21 日發布的補丁公告均未告知自行編譯安裝的管理員須更新 Ruby。GitLab 的 自行編譯安裝指南仍將 Ruby 3.2 標示為最低版本，而 Ruby 3.2 已於四月停止支援，且不會再獲得修補。

哪些 GitLab 伺服器可能被外洩

GitLab 的公告指出，"在特定條件下"，此缺陷可能允許未經授權的使用者在伺服器上執行程式碼。GitLab.com 與 GitLab Dedicated 已經修補。

Rapid7 built a working exploit 在實驗室內開發了一個可執行的利用程式，並於 10 月 13 日發布概念驗證程式碼。該利用程式以 GitLab 的 git 使用者身份，在未修補的官方 GitLab 19.4.1 映像上執行指令，但相同輸入在已修補的 19.4.2 映像上無法執行。

該利用程式首先需要寫入許可權：攻擊者必須將惡意的 .gitlab-ci.yml 檔案及包含 UTF-8 字元的檔案路徑提交到公開專案的某個分支。此需求不適用於允許新使用者自行註冊並建立專案的伺服器。

在 Rapid7's tested route 中，"只有最後的 CI lint 請求是未授權的。" GitLab 的 own detection notes 亦指出攻擊者必須先透過常規倉儲 API 建立該檔案路徑。Rapid7 尚未了解原始報告中對 GitLab 的攻擊（仍為私有）如何避免寫入步驟。

Alpine 尚未說明其攻擊者的 CI 設定如何到達 GitLab，或是否允許新帳號在其伺服器上建立公開專案。

CVE-2026-97229 在 CISA 的 已知被利用漏洞目錄中，於 10 月 28 日更新時並未列入。

GitLab 管理員應該採取的措施

GitLab 的 10 月 21 日版本 是下列每個分支最新的版本，並且也修復了 CVE-2026-110264、另一個正規表示式缺陷。

哪個版本能修復伺服器取決於 GitLab 的安裝方式：

• GitLab 的 Linux 套件或官方容器映像： 升級至您分支的最新版本。
• 自行編譯安裝，或安裝了自有 Ruby 的映像： 升級 GitLab 並將 Ruby 更新至 3.3.13、3.4.12、4.0.9 或更高版本。Ruby 3.2 不會收到修復，故執行 3.2 的伺服器需升級至上述版本之一。

GitLab 的公告將 19.3.4 指定為 19.3 分支的修正版本，發布時於 10 月 12 日。它現在將 19.3.5 指定為修正版本，並列出 19.3.4 為受影響版本，因此仍使用 19.3.4 的伺服器應升級至 19.3.6。

若伺服器無法立即升級，Rapid7 建議限制匿名存取公開專案、阻止不受信任的使用者建立或寫入公開專案，或封鎖 CI lint 路徑。公司表示，這些措施僅覆蓋 Rapid7 的利用路徑，並未修復易受攻擊的正規表示式編譯器。

GitLab 已發布 六條偵測規則，針對自主管理伺服器的利用嘗試，使用 Sigma 格式編寫。其四條被 GitLab 標記為實驗性，會搜尋 CI 正規表示式警告與 GraphQL ciLint 請求中的敵意模式、非 ASCII 字元的極長檔案路徑，以及指出 Onigmo 的 Ruby 崩潰報告。

這些規則的 指引 警告說，成功利用可能不會留下崩潰痕跡，並提供以下進一步步驟：

• 檢查 /tmp 中 git 使用者擁有的檔案、Puma 或 Sidekiq 的非預期子程序、外部連線，以及 git 使用者的 crontab 或 SSH 金鑰是否被更改。
• 若發現程式碼執行跡象，將伺服器視為已被攻破，並旋轉 gitlab-secrets.json、所有 CI/CD 變數、所有執行器令牌與所有存取令牌。
• 限制誰能在伺服器上建立帳號與個人存取令牌。

Alpine 使用者應該採取的措施

Alpine 表示，帳戶持有人在 gitlab.alpinelinux.org 重新開放時，需要在登入頁面使用\"Forgot your password?\"設定新密碼。它也觀察到使用其他網站洩漏的密碼對其 GitLab 進行自動登入嘗試，任何在其他地方使用 gitlab.alpinelinux.org 密碼的人都應在那裡更改。

使用 alpinelinux/gitlab 映像檔的使用者應再次拉取 alpinelinux/gitlab:19.3.6。於 10 月 27 日發布的映像檔包含 Ruby 3.3.13，而在此之前拉取的任何 19.3.6 映像檔以及所有較舊的標籤均存在漏洞。

Alpine 自身的 Ruby 套件已包含修復：Alpine 3.22、3.23、3.24 與 edge 上的 Ruby 3.4.12，以及 Alpine 3.21 上的 Ruby 3.3.13。執行 apk upgrade 即可安裝。

Ruby 維護者表示，該漏洞僅影響從攻擊者控制的文字編譯正規表示式的程式，且 Ruby 的 Regexp.timeout 設定無法防護此問題。

覺得這篇文章有趣嗎？ 追蹤我們的 Google News、Twitter 和 LinkedIn，閱讀更多我們發布的獨家內容。