NetSafe.TW

recent posts

about

全球逾萬台 GitLab 仍暴露於兩個 CVSS 10.0 漏洞、台灣有 46 台：只更新到 10/12 版本還不夠，CVE-2026-97229 已遭攻擊列入 KEV

新聞重點

GitLab 在 10 月中、下旬接連修補兩個 CVSS 10.0 滿分漏洞，但到了 11 月初，網路上仍有大量自架（self-managed）GitLab 沒有更新。資安監測組織 Shadowserver 11 月初公布的掃描資料顯示，全球每天約可觀測到 3.9 萬台直接連上網際網路的 GitLab 執行個體，其中逾 1.13 萬台仍受 CVE-2026-110264 影響，另有逾 1,000 台仍受已遭實際攻擊的 CVE-2026-97229 影響。

台灣也有 46 台暴露在這兩個漏洞的風險下（iThome 引述 Shadowserver 儀表板的國家統計；此數字目前只有 iThome 一家報導，未核實）。同一份國家統計中，美國約 2,700 台最多，其次是中國約 2,400 台、德國約 1,100 台；這三個國家的數字有 iThome 與韓國資安媒體 Zerowiz 兩方報導對得上。

TWCERT/CC 已在 10/22 發布漏洞警訊，香港政府電腦保安事故協調中心（GovCERT.HK）也在 10/23 發出高危保安警報，並於 11/2 更新。美國 CISA 則在 10/29 把 CVE-2026-97229 列入「已知遭利用漏洞」（KEV）清單，要求聯邦機關在 11/1 前完成修補。

要特別注意的是：只更新到 10/12 那一批修補版本（19.4.2、19.3.5、19.2.8）還不夠，這些版本只修了 CVE-2026-97229，CVE-2026-110264 要到 10/21 的版本才修好。另外，如果不是用 GitLab 官方套件或官方容器映像檔，而是自己編譯、自帶 Ruby，光升級 GitLab 也沒用，還要把 Ruby 升到 3.3.13、3.4.12、4.0.9 或更新版本。

事件時間線

  • 10/12：GitLab 發布 19.4.2、19.3.5、19.2.8，修補 CVE-2026-97229（CI/CD 正規表示式編譯器整數溢位，CVSS 10.0）。
  • 10/13：Rapid7 在實驗環境重現攻擊，並公開概念驗證（PoC）程式碼；當時尚未發現實際攻擊。
  • 10/20–21：開源作業系統 Alpine Linux 的 GitLab（當時仍是未修補的 19.3.4）遭人以特製 CI 設定嘗試利用 CVE-2026-97229，造成 8 次工作程序當機，其中 4 次攻擊已走到一半。
  • 10/21：GitLab 再發布 19.5.1、19.4.3、19.3.6、19.2.9、19.1.9、19.0.10、18.11.13，修補 CVE-2026-110264（同樣是正規表示式編譯器整數溢位，CVSS 10.0），並破例回補到 18.11 等較舊版本。
  • 10/22：TWCERT/CC 發布 GitLab 兩項漏洞警訊。
  • 10/23：上游 Ruby 推出修補版 3.3.13、3.4.12、4.0.9；GovCERT.HK 發布高危保安警報。
  • 10/28：Alpine Linux 公開事件經過，說找不到攻擊成功的證據、但也無法排除，因此整台 GitLab 從頭重建並重設所有帳號密碼。
  • 10/29（美東時間）：CISA 將 CVE-2026-97229 列入 KEV，聯邦機關修補期限 11/1。
  • 11/1–11/2：Shadowserver 公布未修補 GitLab 數量；iThome 於 11/2 報導台灣有 46 台。

技術細節：兩個滿分漏洞與修補版本

兩個漏洞的根源都在 Ruby 內建的正規表示式引擎 Onigmo，GitLab 的修補方式是替官方套件裡附帶的 Ruby 打補丁，而不是改 GitLab 本身的程式碼。兩者都是同一位研究人員 joaxcar 透過 HackerOne 漏洞賞金計畫通報。

項目CVE-2026-97229CVE-2026-110264
CVSS10.0（AV:N/AC:L/PR:N/UI:N/S:C/C:H/I:H/A:H）10.0（同左）
問題位置CI/CD 設定中的正規表示式處理（CI/CD Regular Expression Compiler）編譯特製正規表示式時的整數溢位（Regular Expression Compiler）
影響版本（GitLab 官方公告）19.2 至 19.2.8 前、19.3 至 19.3.5 前、19.4 至 19.4.2 前7.0 起至 18.11.13 前、19.0 至 19.0.10 前、19.1 至 19.1.9 前、19.2 至 19.2.9 前、19.3 至 19.3.6 前、19.4 至 19.4.3 前、19.5 至 19.5.1 前
修補版本19.4.2、19.3.5、19.2.8（10/12）19.5.1、19.4.3、19.3.6、19.2.9、19.1.9、19.0.10、18.11.13（10/21）
是否遭實際利用是，10/29 列入 CISA KEV目前未見確認的實際攻擊；GovCERT.HK 稱已有 PoC 公開（未核實）
Shadowserver 未修補數量逾 1,000 台逾 11,300 台

幾個容易誤會的地方：

  • CVE-2026-110264 影響範圍大很多：從 2014 年的 GitLab 7.0 起都受影響，所以未修補數量是 CVE-2026-97229 的十倍以上。
  • 10/12 的修補不涵蓋 CVE-2026-110264：手腳快、10 月中就更新的管理者，仍要再升一次到 10/21 的版本。最簡單的做法是直接升到各版本線的最新修補版。
  • 自帶 Ruby 的安裝要另外升 Ruby：GitLab 官方公告明說，自行編譯或自製容器映像檔、未使用官方套件附帶 Ruby 的環境，必須把 Ruby 升到 3.3.13、3.4.12、4.0.9 或更新版本。Alpine Linux 就是因為自製映像檔用的是一般 Ruby，10/22 升到 19.3.6 後漏洞其實仍未修好。
  • 「免驗證」有前提：GitLab 評為未經驗證即可利用，但 Rapid7 指出，攻擊者需能把惡意的 .gitlab-ci.yml 和含 UTF-8 字元的檔案路徑提交到公開專案的分支；在開放任何人註冊、可自建專案的自架 GitLab 上，這個條件很容易達成。
  • 台灣 TWCERT 警訊把兩個漏洞的影響版本合併列出（7.0 至 18.11.13 前等），實際上 CVE-2026-97229 只影響 19.2 到 19.4，以 GitLab 官方公告為準。
  • GitLab.com 和 GitLab Dedicated 已由 GitLab 修補，不需處理；風險集中在企業、學校、機關自己架設的 GitLab。

暴露統計（資料來源與日期）

  • 全球每日可觀測約 3.9 萬台、逾 11,300 台受 CVE-2026-110264 影響、逾 1,000 台受 CVE-2026-97229 影響：Shadowserver 11/1（當地時間）在社群平台發布，BleepingComputer、Techzine、iThome 皆引述，數字一致。
  • 國家分布：美國約 2,700、中國約 2,400、德國約 1,100（iThome、Zerowiz 一致）；Zerowiz 另列俄羅斯 919、法國 717、新加坡 338、南韓 253、印度 238、香港 228、芬蘭 206、日本 204（僅 Zerowiz，未核實）。
  • 台灣 46 台：僅 iThome 引述 Shadowserver 儀表板（11/2 報導），未核實。
  • 計算方式：Shadowserver 是依伺服器對外顯示的 GitLab 版本判斷，屬「版本比對」，不代表該伺服器一定能被攻破，也不代表已遭入侵；國家統計是兩個漏洞標籤加總，同一台可能被算兩次（依 Zerowiz 說明，未核實）。反過來說，攻擊者只看版本號也能列出同一份目標清單。

怎麼檢查有沒有被入侵

  • 先確認版本：在 GitLab 管理區（Admin Area）或 /help 頁面看目前版本，對照上表；自帶 Ruby 的環境另外執行 ruby -v 確認 Ruby 版本。
  • 查 GitLab 官方公布的威脅偵測項目：CVE-2026-97229 有 6 項（如 Onigmo native worker crash、Graphql cilint hostile regexp、ci regexp guard rejection、ci lint workhorse worker crash 等），CVE-2026-110264 有 2 項（Onigmo native worker crash、Org mode render error burst）。
  • 找不明原因的 GitLab 工作程序（worker）當機紀錄，尤其是集中在特定時段、且與 CI lint 或管線設定提交同時發生者。Alpine Linux 就是從 8 次工作程序當機發現攻擊。
  • 檢查近期新註冊的帳號、新建的公開專案，以及含有異常正規表示式或 UTF-8 檔案路徑的 .gitlab-ci.yml 提交。
  • 檢查伺服器上是否有不明檔案、SSH 金鑰、Git hooks、排程或程序，以及 git 使用者是否有異常的對外連線。
  • 注意：Alpine Linux 指出，攻擊成功可能不會留下當機或網頁日誌痕跡；如果日誌已經不完整，又曾在未修補狀態下對外開放，最保險的做法是視同已遭入侵。

給企業／IT 管理者

  • 立即升級到各版本線最新修補版（至少 19.5.1、19.4.3、19.3.6、19.2.9、19.1.9、19.0.10 或 18.11.13），不要停在 10/12 的版本。
  • 自編譯或自製容器映像檔者，同步把 Ruby 升到 3.3.13、3.4.12、4.0.9 或更新。
  • 19.4.3、19.3.6 含資料庫遷移，單節點升級會停機，先排好維護時段，但不要因此拖延。
  • 暫時關閉開放註冊、限制一般帳號建立公開專案，降低攻擊門檻。
  • 非必要不要把 GitLab 直接開在網際網路上，改放 VPN 或零信任存取後面。
  • 曾在未修補狀態下對外開放者，輪換管理員密碼、個人與專案存取權杖、Runner 權杖、部署金鑰與 CI/CD 變數中的雲端金鑰。
  • 依上方項目做入侵檢查，並保留日誌與對外連線紀錄。
  • 訂閱 Shadowserver 免費報告或留意 TWCERT/CC 通報，確認自家 IP 是否在名單上。

給一般用戶

  • 如果你只用 GitLab.com，不需要自己處理，但建議開啟兩步驟驗證。
  • 如果你用的是公司、學校或開源專案自架的 GitLab，留意管理者的重設密碼或權杖通知，依指示處理。
  • 在家用 NAS 或 Docker 自架 GitLab 的玩家，請檢查版本並更新，不要直接開對外連接埠。
  • 不要把雲端金鑰、密碼直接寫進程式碼或 CI 設定。

資料來源

Posted in

發表留言