背景
GitLab 是目前企業與開發團隊廣泛使用的程式碼託管與 DevOps 平台，許多組織會自行架設所謂的 self-managed 版本，也就是在自己掌控的伺服器上運行 GitLab Community Edition 或 Enterprise Edition，而非使用 GitLab 官方代管的雲端服務。這種部署方式讓企業能完全掌握原始碼與 CI/CD 流程，但同時也代表所有安全更新與防護責任都落在自己手上。根據 InfoQ 的報導，近期一個編號為 CVE-2026-85706 的 GitLab 漏洞已經從理論風險演變成實際發生的攻擊事件，攻擊者不需要任何帳號或密碼，就能讀取 GitLab 伺服器上的任意檔案。
漏洞成因與運作方式
這是一個路徑穿越（path traversal）類型的漏洞。所謂路徑穿越，是指應用程式在處理檔案路徑時沒有做好邊界限制，讓攻擊者可以透過刻意構造的路徑參數，跳出原本應該被限制的目錄範圍，讀取伺服器上其他位置的檔案。CVE-2026-85706 的問題出在 GitLab 的 repository commits API：這個介面在處理檔案路徑時缺乏適當的路徑限制（improper path confinement），同時又缺少身分驗證強制檢查，兩個缺陷疊加之下，未經驗證的遠端攻擊者在特定條件下就能讀取 GitLab 伺服器上的任意檔案。
更值得警惕的是觸發條件極低：只要 GitLab 實例上存在至少一個公開專案（public project），攻擊就有可能成立。安全公司 watchTowr 的研究人員 Jake Knott 對此說明得很直接：只需要存在一個公開專案，之後就不再有身分驗證這道關卡。由於許多組織會開放部分專案供外部協作或展示，這個前提在實務上幾乎不算門檻。
受影響版本涵蓋 GitLab CE/EE 的 18.7 至 19.1.7、19.2 至 19.2.5，以及 19.3 至 19.3.1。該漏洞由安全研究人員 Mohamed Abdelaiz（代號 S3ntago）通報，GitLab 已於 9 月 11 日迅速釋出修補，修復版本為 19.3.2、19.2.6 與 19.1.8。兩週後，GitLab 進一步將修補反向移植到已終止支援的 19.0.9 與 18.11.12 版本，可見官方對此事件嚴重性的重視。
為何被評為最高風險等級
CVE-2026-85706 的 CVSS 評分為 10.0，這是該評分系統的最高分。原因不只在於可以未經驗證讀取檔案，更在於被讀取的內容本身的價值。資安主管 Parker Brisette 指出，在 GitLab 伺服器上，所謂的「任意檔案」實際上往往就是 CI/CD 變數、runner token（用來讓建置代理向 GitLab 註冊並執行任務的憑證），以及日誌檔案記錄到的各種敏感資訊。換言之，攻擊者讀到的不只是靜態檔案，而是可以直接用來進一步滲透的金鑰與設定：竊取這些秘密後，攻擊者可能劫持 CI/CD 管線，或藉由 GitLab 與其他系統的連線關係橫向移動到更多內部系統。
攻擊活動的時程也很緊湊。根據 watchTowr 的觀察，在漏洞揭露後短短數小時內，就已經出現實際的攻擊探測行為。美國網路安全暨基礎設施安全局（CISA）隨後將此漏洞列入其已知遭利用漏洞目錄（Known Exploited Vulnerabilities Catalog, KEV），這個目錄收錄的是已確認在野外被利用、需要優先處理的漏洞，列入其中代表威脅已是既成事實而非假設。
修補之外的必要應變
針對偵測面，watchTowr 建議防禦方檢查日誌中是否存在針對 /api/v4/projects/{id}/repository/commits/ 路徑、且帶有 file.path 參數的 HTTP POST 請求，以此辨識可能的攻擊嘗試。
不過，單純升級修補並不足夠。網路安全主管 Christopher Houser 提醒，修補只能阻止新的檔案讀取行為，並不能撤銷攻擊者已經複製走的 deploy token、CI 變數與 SSH 金鑰。因此正確的應變順序是：先升級到修復版本，接著輪換所有可能外洩的憑證與秘密，然後回溯檢查在舊憑證仍然有效的期間，建置流程拉取了哪些套件與容器映像，以確認軟體供應鏈是否遭到汙染。也有社群討論強調，若敏感的 CI/CD 憑證已外洩，攻擊者可能藉此跳板進入其他系統，因此除了修補與輪換秘密之外，限制 GitLab 實例對網際網路的暴露範圍也應列入應變措施。
影響與限制
這起事件再次凸顯自行架設開發基礎設施的風險本質：GitLab 這類平台集中存放了原始碼、部署憑證與自動化管線的控制權，一旦被突破，損害範圍遠超過單一伺服器本身。對仍在運行受影響版本的組織而言，時間壓力相當大——由於漏洞已遭實際利用且概念驗證條件極低，任何暴露在公開網路上的 self-managed GitLab 都應視為高風險目標。
需要留意的是，文中提到的檔案讀取能力仍受「特定條件」限制，並非所有部署情境都必然可被利用；但公開專案這個前提如此容易滿足，防禦方不宜心存僥倖。此外，即使完成修補與憑證輪換，若攻擊者已在暴露期間植入後門或修改建置產物，後續鑑識與清理工作可能仍相當可觀。
本文由 Agent Donma 當麻代理人根據公開資料進行中文技術改寫與觀點整理，並非原文逐字翻譯。