GitLab滿分漏洞波及自架CE、EE 七個分支須急升級
GitLab 近日為社群版（CE）及企業版（EE）發布安全更新，其中 CVE-2026-110264 的 CVSS 評分為 10 分。iThome 報道指出，漏洞源於正規表達式編譯器的整數溢位；在特定條件下，未經登入的攻擊者可能在 GitLab server 執行任意程式碼。
對自行營運 GitLab 的團隊而言，風險不只在於原始碼外洩。GitLab 通常同時承載專案、CI/CD 工作流程及部署憑證；一旦 server 被取得程式碼執行權限，攻擊者理論上或可進一步接觸平台可見的資料或自動化流程。這是根據漏洞性質作出的風險分析，實際影響仍取決於實例配置、權限分隔及所儲存的機密資料。
七個版本分支均有修補
iThome 指出，GitLab 今次合共處理 11 項漏洞，並為現行與已終止支援的分支一併發布更新。受影響環境應按現有分支盡快套用對應版本：
| 現有分支 | 建議升至版本 |
|---|---|
| 19.5 | 19.5.1 |
| 19.4 | 19.4.3 |
| 19.3 | 19.3.6 |
| 19.2 | 19.2.9 |
| 19.1 | 19.1.9 |
| 19.0 | 19.0.10 |
| 18.11 | 18.11.13 |
iThome 亦指出，該漏洞最早可追溯至 2014 年推出的 GitLab 7.0，意味著不少長期未整理的自架環境尤其需要盤點。即使某些舊分支今次獲得補丁，管理員仍應把升至受支援主線列為後續工作，避免日後只能依賴例外更新。
升級前後應核對甚麼
升級前，先確認 CE 或 EE、目前版本、安裝方式，以及是否有可還原的備份；同時預留維護時段，因 GitLab 更新可能影響 CI/CD 排程。升級後應確認 web 介面、登入、專案存取、Runner 與關鍵 pipeline 均能正常運作，並檢視管理員帳戶、存取權杖、SSH 金鑰和近期異常工作，以判斷是否需要輪換敏感憑證。
使用 GitLab.com 或由雲端／IT 供應商代管的團隊，不能單憑本地沒有版本號便假設已修補。應先確認服務是否屬自管實例；若由第三方營運，向供應商查詢其受影響範圍、修補完成時間及是否需要客戶採取額外行動。現有資料未足以確認 GitLab.com 或各代管服務的修補狀態。
目前資料沒有提供實際在野利用個案，因此不宜把漏洞直接描述為已遭大規模攻擊；但其未登入即可觸發、且可導致任意程式碼執行的性質，已足以令自管 GitLab 成為優先修補項目。接下來值得留意的是各代管平台的修補說明，以及舊版自架實例是否能順利完成升級與憑證檢查。
延伸閱讀
AI 輔助說明： 本文由 AI 協助整理，並經兩輪獨立自動品質審核；資料及連結仍以原始來源為準。
參考來源
- iThome — GitLab修補存在12年的滿分漏洞 — original report
本文根據原文及公開資料整理；資料有出入時，以原文及官方資料為準。
