GitLab滿分漏洞公開後即見探測：自管實例須優先更新

圖片：TechLab 自製資訊圖

TechLab 編輯部（譯）·2026-09-14

GitLab 已修補 CVSS 評分達 10 分的重大漏洞 CVE-2026-85706。據 iThome 報道，問題涉及儲存庫提交內容 API；在特定條件下，未經身分驗證的遠端攻擊者可能讀取 GitLab 伺服器上的任意檔案。對香港公司、開發團隊及學校而言，風險焦點不在日常使用 GitLab 的一般帳戶，而在自行營運 GitLab CE 或 EE 實例的管理者能否迅速確認版本並完成修補。

事件的急切性亦可見一斑。iThome 指出，GitLab 在 9 月 10 日發布修補版本後，資安公司 watchTowr 於 9 月 11 日已表示，其全球蜜罐網絡觀察到針對該漏洞的探測行為。這不等同每個探測都已成功入侵，卻說明公開漏洞資訊已迅速進入攻擊者掃描範圍。仍暴露於互聯網、又未更新的自管 GitLab，應被視為需要優先處理的資產。

先分清哪些部署需要行動

受影響範圍包括 GitLab CE 與 EE 的 18.7 至 19.1.7、19.2 至 19.2.5，以及 19.3 至 19.3.1。GitLab 提供的修補版本為 19.1.8、19.2.6 和 19.3.2；實際應升級至哪一個版本，取決於團隊原來所處的維護分支。管理者不宜只看主版本號便判定安全，例如 19.1 分支中的 19.1.7 仍在受影響範圍，必須升至 19.1.8 或採取合適的後續升級安排。

相反，使用 GitLab.com 的用戶毋須自行處理，因為 iThome 報道稱該服務已完成更新；GitLab Dedicated 客戶亦毋須採取額外措施。這個區分相當重要：同一間機構可能同時有 SaaS 專案、專用託管環境，以及由內部 IT 維護的自管實例。修補責任會隨部署模式而變，資安及開發主管應先建立清晰的資產清單，避免把已由供應商處理的平台與內部要跟進的伺服器混在一起。

漏洞為何令版本盤點變得急切

CVE-2026-85706 屬於路徑穿越問題。iThome 說明，成因是檔案路徑限制不足，加上相關 API 缺少必要的身分驗證檢查。若漏洞被成功利用，攻擊者可能讀取 GitLab 伺服器上的敏感檔案。報道沒有披露具體可讀取的檔案、受害情況或已確認入侵個案，因此不宜把「出現探測」直接描述為大規模資料外洩；但從防守角度看，未驗證存取配合讀檔風險，已足以令其成為優先級極高的修補事項。

這類事件也反映一個實務難題：GitLab 在不少團隊不只是程式碼儲存位置，還會連接開發流程、持續整合及各類內部設定。即使報道未有列出個別部署的設定方式，管理者仍可合理推論，伺服器上可能承載不宜被外部讀取的營運資料。因此，版本更新不能只由某個專案組自行決定；負責平台、資訊保安與開發運作的人員，應共同確認實例位置、可從外部存取的介面，以及更新窗口。

EE 用戶還要留意另一項高風險問題

同一次修補也包括僅影響 GitLab EE 的 CVE-2026-87719，CVSS 評分為 9.9。據 iThome 報道，這是一項重大反序列化漏洞；擁有 Duo Chat 存取權限的用戶在特定條件下，可能取得 Advanced Search 實例的設定及敏感憑證。它與首項漏洞的威脅模型不同：前者涉及未經驗證的遠端攻擊可能，後者則取決於既有 Duo Chat 權限及特定條件。

這個差異意味著 EE 管理者不能只把工作理解成「封掉外部掃描」。在安排升級時，亦應辨識是否啟用相關功能、哪些帳戶具有 Duo Chat 存取權限，以及 Advanced Search 環境由誰維護。這些檢查並非替代套用修補；它們的作用是協助團隊按暴露面和權限範圍排序處理工作，並在更新後確認敏感憑證及設定的保護安排仍符合內部要求。

更新之外，應怎樣安排後續檢查

自管 GitLab 的第一步應是盤點所有 CE／EE 實例，記錄目前版本、部署位置、是否可由互聯網到達，以及負責人。其後按現行分支升至 GitLab 列出的已修補版本，並依機構既有變更流程做好備份、相容性檢查和更新後驗證。由於報道已提到探測行為，處於受影響版本而且對外開放的實例，排序上應較只在受控內網使用的實例為先。

完成更新不代表調查工作必然結束。若團隊在漏洞公開後才修補，可檢視相關時段的存取及安全紀錄，特別留意異常 API 請求或其他不尋常活動；若發現疑點，應按既有事故應變程序處理。這是基於已見探測所作的審慎風險管理建議，並非指所有未更新系統都已遭入侵。避免公開可直接濫用的技術細節，同時保留足夠紀錄供內部判斷，會是較穩妥的做法。

接下來值得觀察的是，各機構能否把這次修補轉化為更完整的自管開發平台治理：清楚區分 SaaS、Dedicated 與自管責任，維持可快速查詢的版本清單，並讓平台更新、權限覆核和事故紀錄有固定協作機制。對 GitLab.com 與 GitLab Dedicated 用戶而言，這次毋須額外操作；真正需要即時跟進的，仍是管理受影響 CE／EE 版本的自管團隊。