GitLab 於二〇二六年十月二十一日發布臨界保安修補，修復正則表達式編譯器整數溢位漏洞 CVE-2026-110264，CVSS 評為滿分十點零；在特定條件下，未認證使用者或可於自管 GitLab 伺服器遠端執行任意程式碼，受影響版本由 7.0 起橫跨多個長期分支。來源真實性已驗證，以 GitLab 官方 Docs 臨界修補專頁為準。本文整理修補版本、影響範圍與自管實例應急要點。
GitLab／官方：臨界修補釋出——正則編譯整數溢位 CVE-2026-110264 評 CVSS 10.0；未認證可遠端執行；自管須升至 19.5.1 等
引言
自管（self-managed）GitLab 是企業程式碼、CI／CD 與權限邊界的匯流點。二〇二六年十月二十一日，GitLab 為 Community Edition（CE）與 Enterprise Edition（EE）同步釋出 19.5.1、19.4.3、19.3.6、19.2.9、19.1.9、19.0.10 與 18.11.13，並強烈建議所有受影響的自管安裝立即升級。來源真實性已驗證：以 GitLab Docs《Critical Patch Release》專頁為主，交叉核對其對 CVE 編號、CVSS 向量與受影響版本區間之表述。以下為改寫整理，不轉載完整漏洞技術附錄。
一、事件核心與修補時間線
技術細節
據官方專頁，此輪屬針對高嚴重度漏洞的臨界修補（critical patch），而非僅例行雙周三排程更新。GitLab.com 已運行修補後版本；GitLab Dedicated 租戶若已達 19.3.5-internal0、19.4.2-internal0 或更新內部版本，亦已包含相關修復，一般無需另行操作。其餘自管實例（含 Omnibus、原始碼安裝、Helm chart 等部署型態，除非另有註明）均被要求盡快升至對應修補版。
本輪保安表列以「Critical」領頭者為 CVE-2026-110264：正則表達式編譯器（Regular Expression Compiler）存在整數溢位問題。官方描述稱，在特定條件下，未認證使用者或可藉特製正則表達式，於編譯階段觸發溢位，進而在 GitLab 伺服器上執行任意程式碼。CVSS 3.1 向量為 AV:N/AC:L/PR:N/UI:N/S:C/C:H/I:H/A:H，分數 10.0。漏洞經 HackerOne 漏洞賞金計劃由研究員 joaxcar 通報。
受影響版本區間極廣：GitLab CE／EE 自 7.0 起，直至升至下列修補版之前皆屬範圍——18.11.13、19.0.10、19.1.9、19.2.9、19.3.6、19.4.3、19.5.1。官方除標準修補線外，亦把此修復反向移植至 18.11.13、19.0.10、19.1.9 與 19.2.9，以覆蓋仍停留在較舊支援線的自管客戶。
同日表列尚有多項 High／Medium／Low 議題，其中較需營運端一併留意者包括：OmniAuth 與 LDAP 自動連結路徑上的不當認證問題 CVE-2026-15723（CVSS 8.2，特定組態下已認證使用者或可接管既有 LDAP 帳戶）；以及 OAuth／OIDC discovery 端點快取投毒 CVE-2026-112212（CVSS 7.5）。本文以 CVSS 滿分之遠端程式碼執行風險為敘事主軸，其餘條目請以官方表為準逐項對照。
二、技術原理深度解析
CVE-2026-110264 的關鍵不在「需要先登入的管理介面誤用」，而在網絡可達、低攻擊複雜度、無需權限與無需使用者互動的評分組合，再加上影響範圍標為 changed（S:C）。對自管實例而言，這意味著只要攻擊面能觸及會編譯特製正則的路徑，理論上即可由未認證一方嘗試推進至程式碼執行——官方亦因此以「立即升級」而非「僅靠網絡 ACL」作為首要建議。
GitLab 保安團隊同日釋出兩項威脅偵測，協助自管客戶觀察疑似利用跡象：一為 Onigmo native worker 崩潰相關訊號；二為 Org mode 渲染錯誤突增。官方並重申：GitLab 代管基礎設施（含 GitLab.com 與 Dedicated）維持已修補狀態；偵測規則主要服務仍自行營運實例的客戶。讀者應把偵測視為升級後的輔助監控，不能替代套用修補版本。
與約一周前（十月十二日）曾披露、同樣評為 CVSS 10.0 的 CI／CD 正則相關議題相比，本次 CVE-2026-110264 的版本跨度回推至 7.0，且明確寫入「未認證使用者／任意程式碼執行」表述，對長期未升級的自管節點壓力更大。兩者皆提醒：GitLab 內建正則編譯路徑一旦出錯，後果可直接落在託管原始碼與流水線密鑰的同一主機信任邊界上。
三、日常應用場景
1. 開發者與技術團隊
立即核對正式、預備與災難復原環境的 GitLab 小版本是否已達上述修補版；容器映像與 Helm values 應改釘修補標籤並重部署，而非只重啟 Pod。若實例曾對互聯網或廣闊內網開放，升級後宜依自身事件應變程序檢視應用與系統紀錄，並對照官方威脅偵測訊號；曾暴露期間的 CI 變數、部署金鑰與個人存取權杖，應評估是否需要輪替。
2. 企業與隱私敏感行業
金融、醫療、法律與政府外包團隊常用自管 GitLab 存放客戶程式碼與掃描報告。CVSS 滿分且可未認證觸發的遠端程式碼執行，等同把原始碼倉、Runner 註冊權杖與雲端部署憑證放在同一被攻陷風險下。資安與平台團隊應把本次升級列為有時限的緊急變更，並同步檢查 Runner、對外 webhook 與 OmniAuth／LDAP 組態是否落入同批 High 級議題的前提條件。
3. 一般中小企與外包維運
香港不少中小企把 GitLab 放在單一 VPS 或機房虛擬機，由內部或外包同事維護。負責人應要求取得「目前版本號＋升級完成時間」的書面確認，而不是只問「有沒有開防火牆」。若暫未能升級，至少應收緊對來源 IP 的暴露面並加強監控，但官方立場仍是：升級才是完整解法。
4. 香港與亞洲市場視角
區內不少產品團隊以自管 GitLab 滿足數據留存與合規要求，同時讓 AI 編程代理、CI 與容器部署共用同一平台。當日科技媒體亦以「網絡保安非常糟糕的一天」概括多條並行披露；對香港營運者而言，重點不是追新聞標題，而是確認自身 GitLab 小版本與對外攻擊面。把原始碼平台、Runner 主機與雲端身份一併納入加固與持續監控，比單一臨時 ACL 更符合實際風險。
四、專業評價與潛在考量
優勢
官方以可核對的 CVE、CVSS 向量、精確小版本清單與 Dedicated／.com 狀態說明，讓營運端可以直接排程，而非依賴二手轉述。反向移植至多條舊支援線，亦有助仍停在 18.11／19.0–19.2 的機構縮短「通告已出、分支無修補」的空窗。
需要留意的地方
「under certain conditions」意味著利用前提與完整技術細節，仍須等待官方約九十日後公開議題追蹤器記錄，以及社群後續分析；在此之前應假設披露後探測會上升。共用快取、身份提供者與 AI Gateway 相關的同批議題，可能影響已啟用 SAML／LDAP／OIDC 或 Duo 功能的組態，升級後宜做回歸驗證。讀者亦不應把「GitLab.com 已修」誤讀為「自管鏡像自動安全」。
結語
正則編譯路徑上的整數溢位，把未認證攻擊與原始碼平台信任邊界直接打通；對仍運行舊版自管 GitLab 的機構，可驗證的下一步只有升至官方列明的修補版本並確認生效。香港團隊若正把開發平台、CI／CD 與雲端工作負載一併加固，宜同步檢視暴露面、密鑰輪替與持續監控。若需在香港規劃雲端遷移與網絡安全加固，可參考 YSK Limited 的雲端遷移與網絡安全服務（https://ysk.hk/services/cloud-security）。
參考來源
- GitLab Docs：Critical Patch Release 19.5.1／19.4.3／19.3.6／19.2.9／19.1.9／19.0.10／18.11.13（官方，二〇二六年十月二十一日）
- Hacker News 指標發現（非一手來源）：討論指向上述 GitLab Docs 專頁