top of page

GitLab 重大漏洞 CVE-2026-97229 遭實際利用：自架 GitLab 只升級還不夠，Ruby 也要修補

Miles Ma
4天前
讀畢需時 5 分鐘

很多台灣企業的研發團隊把原始碼、CI/CD 流程與部署金鑰都放在自架的 GitLab 上，通常跑在 AWS、GCP、Azure 的虛擬機或容器裡。GitLab 重大漏洞 CVE-2026-97229（CVSS 10.0）已在 2026-10-29 被美國 CISA 列入「已知遭利用漏洞（KEV）」清單，開源專案 Alpine Linux 的 GitLab 也在 10 月下旬遭到針對這個漏洞的攻擊，最後選擇整台重建。


這次事件最值得注意的一點是：如果你的 GitLab 不是用官方套件安裝，而是自行編譯或在自建容器裡另外安裝 Ruby，只升級 GitLab 並不會修好漏洞。 以下整理官方公告重點、受影響版本與企業可以馬上做的檢查。



漏洞重點：CI 設定裡的正規表示式，可能讓攻擊者在伺服器執行程式


以下為官方公告整理的事實（查核日期：2026-11-02）。


CVE-2026-97229 是什麼


  • 漏洞類型： GitLab CI/CD 正規表示式編譯器的整數溢位。依 GitLab 公告，在特定條件下，未經驗證的使用者可以透過 CI/CD 設定中特製的正規表示式，在 GitLab 伺服器上執行任意程式碼。

  • 嚴重程度： Critical，CVSS 10.0。

  • 修補時間： GitLab 於 2026-10-12 發布 19.4.2、19.3.5、19.2.8 修補版。

  • CISA KEV： 2026-10-29 列入，美國聯邦機構修補期限為 2026-11-01。


根本原因在 Ruby 的正規表示式引擎 Onigmo


Ruby 官方於 2026-10-23 發布 Ruby 4.0.9、3.4.12、3.3.13，修補 Ruby 內建正規表示式引擎 Onigmo 的多個問題，對應 GitLab 指定的 CVE-2026-89078、CVE-2026-93577、CVE-2026-97229、CVE-2026-110264。Ruby 官方說明：


  • 只要應用程式會把使用者可控制的字串編譯成正規表示式（例如 Regexp.new、Regexp.union，或把使用者輸入插入正規表示式），就可能受影響；只使用開發者寫死的正規表示式則不受影響。

  • Regexp.timeout 無法防護這類問題，限制輸入長度也不可靠，因為部分問題用很短的字串就能觸發。


另一個 CVSS 10.0 漏洞：CVE-2026-110264


GitLab 在 2026-10-21 又發布重大修補（19.5.1、19.4.3、19.3.6、19.2.9、19.1.9、19.0.10、18.11.13），修正同樣位於正規表示式編譯器的 CVE-2026-110264，影響範圍從 GitLab 7.0 起的多個版本。2026-10-29 的最新修補版為 19.5.3、19.4.5、19.3.7、19.2.10、19.1.10、19.0.11、18.11.14，另需單獨更新 GitLab Runner 至 19.5.1。


項目

CVE-2026-97229

CVE-2026-110264

嚴重程度

Critical，CVSS 10.0

Critical，CVSS 10.0

GitLab 修補日

2026-10-12

2026-10-21

已修補版本（各分支）

19.4.2、19.3.5、19.2.8

19.5.1、19.4.3、19.3.6、19.2.9、19.1.9、19.0.10、18.11.13

CISA KEV

2026-10-29 列入

查核時未列入

Ruby 修補版

4.0.9、3.4.12、3.3.13

4.0.9、3.4.12、3.3.13


GitLab.com 與 GitLab Dedicated 已由 GitLab 修補，需要動作的是自架（Self-managed）GitLab。



Alpine Linux 事件：升級了，但漏洞還在


Alpine Linux 在 2026-10-28 公開事件說明，時間軸大致如下：


  1. 10-13 升級 GitLab 時誤裝 19.3.4，而不是已修補的 19.3.5。

  2. 10-20 至 10-21，新註冊帳號送出特製 CI 設定，造成 GitLab 工作程序 8 次當機，其中 4 次已進展到部分利用階段。

  3. 10-22 升級到 19.3.6，但因為使用的是自行安裝的標準 Ruby，GitLab 自帶套件中的 Ruby 修補並沒有套用到他們的環境，漏洞仍在。

  4. 10-27 關閉服務、從頭重建，重設所有帳號密碼並更換 GitLab 機密金鑰，之後重新開放並升級到 19.3.7。


Alpine 表示沒有找到程式碼被執行的證據，但成功利用不會留下當機或網頁日誌紀錄，加上部分日誌遺失，因此無法排除遭入侵，選擇把伺服器當成已被入侵處理。他們也特別提醒：自行編譯或自建容器的 GitLab，「只升級 GitLab 是不夠的」，Ruby 也必須更新到修補版。



對企業的影響


以下為 WeWinCloud 的分析與建議，非官方說法。


  • 原始碼與 CI/CD 是供應鏈的核心。 GitLab 伺服器通常保存原始碼、CI/CD 變數、部署金鑰、雲端存取憑證與 Runner token，一旦被入侵，影響會延伸到正式環境與客戶。

  • 「開放註冊」與「對外公開」會放大風險。 Alpine 的攻擊者是用新註冊帳號送出 CI 設定。對外開放、允許自行註冊或有大量外部協作者的 GitLab，暴露面最大。

  • 用自建映像檔或原始碼安裝的團隊最容易漏掉。 很多團隊為了客製化自己打包 GitLab 容器，升級時只改 GitLab 版本號，底層 Ruby 沒有跟著更新。

  • 其他 Ruby 應用也要盤點。 任何會把使用者輸入編譯成正規表示式的 Ruby 服務，例如搜尋、過濾規則或自訂規則引擎，也應確認 Ruby 版本。



企業 5 步驟檢查與修補


  1. 盤點所有 GitLab： 包含研發部門自行架設、測試環境與雲端上的 GitLab，確認對外是否可連線、是否開放註冊。

  2. 確認安裝方式與版本： 官方 Omnibus 套件或官方容器，升級到最新修補版（2026-10-29 的 19.5.3、19.4.5、19.3.7 等）即可；自行編譯或自建映像檔，另外確認 Ruby 已是 4.0.9、3.4.12、3.3.13 或更新版本。

  3. 無法立刻升級時先降低暴露： 暫停對外開放註冊、限制 GitLab 只能從公司網路或 VPN 連線，並以 WAF 或安全群組縮小可存取範圍，作為升級前的過渡措施（不能取代修補）。

  4. 檢查是否有異常跡象： 回頭檢查 10 月中旬以來的新註冊帳號、異常的 CI 設定、GitLab 工作程序異常當機，以及 GitLab 官方提供的威脅偵測規則（例如 Onigmo 工作程序當機）。

  5. 曾暴露且版本落後時，當成已被入侵處理： 參考 Alpine 的做法，輪替 CI/CD 變數、部署金鑰、雲端存取憑證、Runner token 與個人存取權杖，必要時重建伺服器，並比對近期程式碼與發布內容。


情境

建議優先順序

對外公開且開放註冊，版本未修補

立即限制存取並升級，事後輪替所有機密

僅內網使用，版本未修補

本週內升級，並檢查 Ruby 版本

已升級，但為自行編譯或自建映像檔

確認 Ruby 修補版本，未修補視同未修

使用 GitLab.com 或 GitLab Dedicated

由 GitLab 修補，持續關注官方公告



常見問題 FAQ


已經升級 GitLab，為什麼還可能有風險？


GitLab 官方套件會帶入已修補的 Ruby，但自行編譯或在自建容器另外安裝 Ruby 時，Ruby 不會隨 GitLab 升級。Alpine Linux 就是在升級到 19.3.6 後，發現漏洞仍然存在。


用 GitLab.com 的企業需要處理嗎？


依 GitLab 公告，GitLab.com 與 GitLab Dedicated 已完成修補。企業需要處理的是自架的 GitLab，以及自家其他 Ruby 應用。


設定 Regexp.timeout 可以防護嗎？


不行。Ruby 官方明確說明 Regexp.timeout 無法防護這些問題，限制字串長度也不可靠，應升級 Ruby 或停止編譯不可信的輸入。



WeWinCloud 能提供什麼協助


WeWinCloud 提供資安防護服務，包括 WAF 網站防火牆、EDR／MDR 端點防護，以及資安顧問與弱點評估；也提供架構規劃與上雲服務，協助檢視自架 GitLab 這類開發基礎設施的網路暴露、存取控制與備援設計。


如果你不確定公司內有多少套 GitLab、版本與 Ruby 是否已修補，可以先和我們聊聊目前的環境。



需要協助盤點 GitLab 與 CI/CD 資安風險？👉 與我們聯繫，或查看資安防護服務。



延伸閱讀



參考資料

留言

bottom of page