GitLab重大漏洞遭駭客利用！逾1,000台伺服器仍未修補、CVSS滿分10分，更新GitLab竟可能還不夠？受影響版本與修補方式一次看

GitLab重大漏洞已遭實際利用： 修補發布三週後，仍有逾千台伺服器暴露

企業使用GitLab進行程式碼託管、 版本控制及CI/CD自動部署， 這套系統的權限可能牽涉 開發流程、網站原始碼及發布環境。 因此，當GitLab本身出現 可導致遠端執行程式碼的重大弱點， 影響可能超過一個管理網站。

GitLab於2026年10月12日 發布19.4.2、19.3.5及19.2.8， 修補CVE-2026-97229。 但到了11月2日， BleepingComputer引用Shadowserver觀測指出， 仍有超過1,000台公開連網GitLab伺服器 尚未修補這項漏洞。

更重要的是，美國CISA已在10月29日 將此漏洞列入Known Exploited Vulnerabilities， 簡稱KEV的已知遭利用漏洞清單。 這代表已有足夠可信證據顯示 漏洞在真實環境遭到利用， 並非只有實驗室研究或理論推測。

逾1,000台未修補，是逾1,000台已遭入侵嗎？

不是。Shadowserver的數字是依 網路觀測所得到的未修補公開執行個體， 並非成功入侵的伺服器數量。 實際遭攻擊、是否被取得控制權 仍須透過事件紀錄及鑑識確認。

GitLab.com使用者也必須自行安裝更新嗎？

GitLab官方表示， GitLab.com已部署相關修補； 受影響的GitLab Dedicated環境 也已按官方方式更新。 本篇主要面向自行管理GitLab CE或EE、 使用原始碼安裝及自訂容器的企業。

CVE-2026-97229是什麼？ 為什麼規則運算式漏洞能取得CVSS滿分10分？

CVE-2026-97229涉及GitLab CI/CD規則運算式編譯過程中的 整數溢位弱點， 對應CWE-190。 GitLab在讀取特定CI/CD設定時， 可能需要將規則運算式交給 Ruby底層引擎編譯與處理。

如果程式在處理特定輸入時， 沒有正確限制數值計算的邊界， 便可能造成記憶體操作異常。 GitLab官方指出， 在特定條件下， 攻擊者可能藉此在伺服器上 執行任意程式碼。

CVSS 10.0代表所有GitLab都會被成功入侵嗎？

不代表。CVSS是弱點嚴重程度的評分， 考量攻擊條件及可能影響， 不是成功入侵的百分比， 也不等於所有伺服器都正在被攻擊。

GitLab官方評估這項漏洞 可能在不需要既有登入權限的條件下 造成遠端程式碼執行。 但實際攻擊仍須能觸及相關處理路徑， 不能簡化成任何人在瀏覽器開啟GitLab首頁 就會自動取得伺服器控制權。

仍有逾1,000台GitLab未修補： Shadowserver數字代表什麼、不代表什麼？

Shadowserver持續觀測對網際網路公開的 GitLab執行個體。 2026年11月2日資安媒體引用的資料指出， 該組織每天可看到約39,000台GitLab系統， 其中超過1,000台仍存在 CVE-2026-97229相關未修補風險。

同期另一項漏洞CVE-2026-110264 的未修補觀測值超過11,300台。 這兩個數字來自不同漏洞的觀測， 可能包含重複的伺服器， 不得加總成「12,300多台已遭駭」。

網路掃描會漏掉哪些GitLab？

企業內網、透過VPN存取、 位於非公開網段， 或採不同網路設定的部署， 未必全部包含在同一份公開網路觀測結果。 所以39,000台不能當成全球GitLab 所有自建系統的完整數量。

為什麼不能把11月2日數字當成即時數量？

企業隨時可能更新伺服器、 變更網路設定或關閉舊服務。 網路觀測的數量也會因偵測時間、 系統可用性及判定方法變動。 正式報導應標示觀測日期， 而非將過去的掃描結果寫成即時資訊。

GitLab 19.4.2就安全了嗎？ 兩項CVSS 10分漏洞與七個分支修補門檻

CVE-2026-97229與CVE-2026-110264 是不同漏洞，不能混用修補版本。 前者10月12日首批修補； 後者10月21日發布更新， 影響的版本範圍也更廣。

兩項漏洞的官方修補版本有哪些？

GitLab於10月21日發布 19.5.1、19.4.3、19.3.6、19.2.9、 19.1.9、19.0.10及18.11.13。 對使用官方套件或官方映像的系統， 這些是當次公告所列修補門檻。

上表為10月21日GitLab官方公告版本， 不是保證截至11月3日各分支最新或仍受支援的版本。 實際升級請以GitLab最新安全公告及升級路徑為準。 若使用自訂Ruby，還須另外確認底層修補。

為什麼不能只看到19.4.2就停止更新？

因為19.4.2針對10月12日的 CVE-2026-97229已完成修正， 但無法取代10月21日 CVE-2026-110264所需的19.4.3。 只查看單一CVE的修補表， 容易漏掉稍後公布的安全更新。

Alpine Linux遭攻擊後升級GitLab， 為什麼10月26日仍發現系統有漏洞？

Alpine Linux於2026年10月28日 發布GitLab資安事件說明， 並於10月30日更新恢復進度。 官方指出，攻擊者在10月20日至21日 嘗試利用CVE-2026-97229。

Alpine的GitLab工作程序曾崩潰八次， 其中四次進入部分利用程序， 但沒有找到攻擊者成功執行程式碼的證據。 由於紀錄存在限制， Alpine也不能完全排除入侵可能， 因此選擇以已遭入侵的情境 執行保守的重建與憑證處置。

最關鍵的轉折發生在10月22日： Alpine已升級到GitLab 19.3.6， 但10月26日仍確認存在漏洞。 原因不是官方修補表寫錯， 而是Alpine使用自行建置的容器， 其中Ruby元件未同步套用 GitLab官方套件內的修補。

Alpine Linux已經確認原始碼遭到竄改了嗎？

沒有。Alpine官方指出， 已核對的aports套件庫、 套件及10月21日發布成果 沒有發現遭竄改的證據， 也沒有確認攻擊者成功執行程式碼。 不能把「遭攻擊嘗試」 說成「軟體供應鏈已被植入惡意程式」。

Alpine後續做了什麼處置？

Alpine重新建置GitLab環境、 更新相關元件並更換密碼及機密金鑰， 於10月29日重新開放服務。 這些行動是在無法完全排除風險的前提下， 採取較保守的事故處理方式。

GitLab背後的Ruby、Onigmo才是關鍵？ 四項CVE與底層修補版本

Ruby是GitLab重要的開發語言之一， Onigmo則是Ruby使用的規則運算式引擎。 GitLab在處理某些CI/CD設定時， 會將規則運算式交給Ruby編譯。 因此，底層元件的缺陷 有可能透過GitLab功能影響伺服器安全。

Ruby於2026年10月23日正式公告， GitLab先前揭露的四項CVE 均與Ruby規則運算式引擎問題有關。

所有Ruby網站都會受到同樣的RCE威脅嗎？

不能如此推論。Ruby官方指出， 相關問題需要程式將 不可信任的輸入內容 交給規則運算式編譯流程。 是否存在可利用路徑， 取決於應用程式的設計與輸入處理方式。

這次事件的普遍教訓是： 套件的主要版本已更新， 並不代表執行環境所有相依元件 都一定更新完成。

CISA為何將GitLab漏洞列入KEV？ 11月1日修補期限適用哪些機關？

美國網路安全暨基礎設施安全局CISA 在10月29日把CVE-2026-97229 收入Known Exploited Vulnerabilities清單。 該清單聚焦已具有 實際遭利用可信證據的弱點， 與只記錄技術描述的CVE資料庫不同。

對適用其相關聯邦資安規範的美國機關， 此項漏洞列有2026年11月1日處置期限， 並須遵循相關風險優先更新及鑑識要求。

台灣企業也必須在11月1日前修補嗎？

不能把美國聯邦機關的KEV處置期限 直接寫成所有台灣企業的法定期限。 不過，CISA確認存在實際利用， 使這項漏洞具備較高處置優先性， 特別是公開連網、自行管理的GitLab環境。

修補後還需要檢查入侵紀錄嗎？

需要依暴露情況評估。 安裝修補程式可以降低後續利用風險， 但不會自動排除 更新前可能已發生的入侵。 如果曾長時間執行未修補版本， 應同步核對CI/CD執行、 系統程序、帳號與異常操作紀錄。

我的GitLab版本符合修補門檻嗎？ 同時檢查GitLab及Ruby版本

下方工具依10月21日官方公告 比較已知修補門檻， 並根據部署方式提示是否需要 額外確認Ruby元件。 所有判斷都在瀏覽器本地執行， 不會連線到使用者伺服器， 也不會讀取實際GitLab組態。

為什麼自訂容器需要另外檢查Ruby？

GitLab官方已明確提醒， 若使用非官方套件內含的Ruby， GitLab應用程式升級 不一定會同步更新底層引擎。 Alpine Linux的實際案例 就是最具代表性的警訊。

GitLab管理員現在該做什麼？ 六步驟確認漏洞修補及入侵風險

對自行部署GitLab的網站公司、 DevOps及IT團隊而言， 應將版本更新、 底層相依元件和事件調查 放在同一份檢查工作中。

需要直接在正式伺服器測試RCE漏洞嗎？

不建議在正式營運環境 透過可能造成程序崩潰的攻擊方式測試。 企業應以官方安全公告、 已驗證的版本與套件清單、 合法授權的弱點檢測 及事件日誌調查為主。

為什麼更新完成仍要保留事件紀錄？

安全更新處理的是已知弱點， 但更新前已發生的未授權操作 仍需獨立調查。 若存在可疑跡象， 應保存相關紀錄， 評估是否需要更換部署金鑰、 存取權杖及其他機密資料。

台灣網站公司與軟體團隊為何要注意？ GitLab漏洞可能沿CI/CD擴大影響

一家網站設計公司可能使用GitLab 統一存放不同客戶的網站原始碼， 並透過Runner將程式部署到 測試主機及正式網站。 因此，開發平台的安全狀態 可能與多個客戶服務有關。

如果攻擊者成功取得 GitLab伺服器的高權限執行能力， 可能進一步接觸伺服器 本來就有權限存取的程式碼、 設定、部署環境或憑證。 但實際損害程度取決於 Runner隔離、權限設計及密鑰保護。

這次事件已造成台灣企業程式碼外洩嗎？

截至2026年11月3日， 沒有足夠公開資料 可以確認台灣所有使用GitLab的企業 均已遭到入侵， 也不能從全球未修補統計 推算台灣實際外洩數量。

網站已經有HTTPS及防火牆，還需要檢查GitLab嗎？

需要。網站前台安全與 背後的原始碼管理平台、 CI/CD Runner及部署憑證 屬於不同層次。 即使正式網站正常運作， 開發與發布流程仍應獨立管理權限、 安全更新和異常監測。

GitLab漏洞事件時間軸： 從10月12日修補，到11月2日逾千台暴露

1. 10/12
   GitLab首次安全修補

   發布19.4.2、19.3.5及19.2.8，處理CVE-2026-97229。

2. 10/13
   漏洞紀錄正式公開

   CVE-2026-97229公布，CVSS v3.1為10.0。

3. 10/20—21
   Alpine Linux遭遇攻擊嘗試

   自建GitLab工作程序發生多次崩潰，尚無成功執行程式碼的證據。

4. 10/21
   GitLab第二波重大安全更新

   修補CVE-2026-110264，公布19.5.1、19.4.3等版本。

5. 10/23
   Ruby發布底層修正

   推出3.3.13、3.4.12及4.0.9，處理Onigmo相關缺陷。

6. 10/26
   Alpine發現升級後仍有風險

   確認自訂GitLab映像並未同步使用已修補Ruby。

7. 10/28
   Alpine公開事件並完成重建

   更換密碼及機密金鑰，未發現發布成果遭竄改證據。

8. 10/29
   CISA將CVE-2026-97229列入KEV

   官方確認此弱點已遭實際利用。

9. 11/02
   逾千台公開GitLab未修補消息曝光

   媒體引用Shadowserver觀測，另一項漏洞亦有11,300多台暴露。

哪些資訊已確認，哪些不能下結論？