GitLab 的 Duo Claude Agent 能在 CI 中執行任意指令。尚無人證明它曾被利用。

GitLab 於 2026 年 8 月 26 日針對 Duo Claude AI 代理程式中的高嚴重性漏洞發布修復版本；Duo Claude AI 代理程式是一款以 Claude 為基礎的代理程式，GitLab 的公告將其置於 CI 情境中。此漏洞追蹤編號為 CVE-2026-18252，讓持有 Developer 角色的已驗證使用者得以在 CI 工作內執行任意命令，原因是該代理程式會處理來自使用者可控來源的設定，卻未驗證其來源。GitLab 在 CVSS 3.1 量表上將其評為 7.3，並將受影響範圍界定為 GitLab Enterprise Edition：18.9 版至 19.1.7 之前（不含 19.1.7）、19.2 至 19.2.5，以及 19.3 至 19.3.1。GitLab.com 已執行修補後的程式碼，GitLab Dedicated 客戶則被告知無須採取任何行動。本文審閱的來源均未報導有人利用此漏洞，公開來源中也尚未發布任何概念驗證。此事件的檔案庫條目，包含其嚴重性與信心等級，收錄於 Orca AI Incident Archive，與同一週的鄰近紀錄並列。

這份公告說了些什麼，又略過了什麼

主要文件篇幅簡短。GitLab 同日發布的 19.3.1、19.2.5 與 19.1.7 修補版本發行說明列出七項安全修復。第一項標示為 High，標題為「Duo Claude AI agent 中的不受信任控制範圍功能納入問題影響 GitLab EE」，其文字說明僅有一句話。GitLab 表示，它「已修復一個問題：在某些條件下，具有開發者角色權限的已驗證使用者，可能因為 Claude agent 處理來自使用者控制來源的設定，而在 CI 環境中執行任意命令」。這就是廠商公布的完整技術描述。

CVE 記錄由 GitLab 本身指派，增添的是結構而非實質內容。它將該弱點歸類為 CWE-829，重述受影響範圍與 CVSS 7.3 分數，並記載該識別碼於 2026 年 7 月 29 日保留、於 8 月 26 日 13:36 UTC 發布。GitLab 歸功的漏洞賞金報告 HackerOne 報告 3863650，在 2026 年 10 月 29 日未經身分驗證的擷取中傳回 403，因此其技術細節並未公開；而 CVE 記錄連結作為參考的追蹤項目 gitlab-org/gitlab 工作項目 607342，在該次檢查中並無可讀取的議題內容。

這份公告沒說的，正是防禦人員最想知道的部分。它並未指明涉及的 Duo 功能、代理程式所讀取的設定欄位，或使用者可控來源的形式——究竟是儲存庫檔案、管線變數、issue 或合併請求留言，還是 API 參數。這些內容都沒有寫在 GitLab 的說明、CVE 紀錄，或本文所檢視的業界報導中。GitLab 的產品文件的確描述了 Claude 進入 CI 的一條路徑：外部代理程式（external agents）；文件指出，這些代理程式在 issue、epic 或合併請求中被提及時會執行 CI/CD 管線，而且有對應的 Claude Code 設定範例。所檢視的資料中，沒有任何內容將該路徑與 CVE-2026-18252 連上關係。這只是在說明 Claude 代理程式為何會擁有 CI 權限的背景，並非此漏洞的機制。

同一份文件對這類風險直言不諱。GitLab 的 external agents 頁面將提示注入漏洞列為客戶啟用該功能時所接受的風險之一，並將其採用的第三方提示掃描描述為一項緩解措施。該頁面未提及 CVE-2026-18252，而該警告也並非對它的描述。它確實表明，不受信任的輸入觸及具有管線存取權限的代理，是 GitLab 自家文件早已要求客戶接受的風險。

憑證就位於 CI 環境中

承載嚴重性判斷的關鍵措辭是「in a CI context」。pipeline 工作不是玩具沙箱；它會帶著 runner token 以及專案向它暴露的任何機密執行。Cyber Security News 在 2026 年 8 月 27 日報導該修補時，列出了這類工作通常能觸及的內容——原始碼、建置產物、部署憑證、雲端 token 與套件倉庫憑證——並指出，視 runner 的設定與 token 範圍而定，pipeline 中的命令執行可能暴露 CI 變數、改動建置產物、竄改發布流程，或進一步觸及相連的基礎設施。GBHackers 同日刊出的報導採用相同的框架。兩家媒體皆未報導實際發生此類情況的案例。

這項區別形塑了應如何解讀該缺陷。這是代理式元件中的命令執行漏洞，而非模型行為不當的示範：記錄描述的是從使用者可控來源取得的設定，以及代理依據該設定採取行動。經檢視的來源均未將該漏洞利用描述為成功的提示注入，GitLab 的安全公告也從未將結果歸因於模型判斷。記錄的弱點是程式碼信任了不應信任的設定來源——CWE-829，從不受信任的控制範圍納入功能。

兩個 CVSS 分數與一個互動步驟

GitLab 的 7.3 並非附加於該識別碼的唯一分數。在同一筆 NVD 紀錄中，NIST 的主要評分為 8.1。這兩個向量除了其中一個元件外完全相同：GitLab 將使用者互動標記為必要，而 NIST 則否。兩個分數都落在 High 等級，因此實務上的差異與其說在於嚴重程度，不如說在於該漏洞觸發的條件。CERT Santé 是法國衛生部的電腦緊急應變小組，於 2026 年 8 月 27 日發布一則警示，其內容依循 GitLab 的判讀——7.3、需要使用者互動，以及將觸發條件描述為一種會啟動設定處理的互動。

漏洞利用訊號相當沉寂，而每一項訊號都是對紀錄的判讀，而非遙測資料。CISA 的協調者角色於 2026 年 8 月 26 日存入 NVD 條目的 SSVC 評估，將漏洞利用記錄為「無」、可自動化記錄為「否」，技術影響記錄為「全面」。FIRST 的 EPSS 模型於 2026 年 10 月 28 日將漏洞利用機率估為 0.00519，也就是略高於 0.5%，在已評分漏洞中位於第 44 百分位。OpenCVE 的紀錄含有相同的 EPSS 數值，並將該 CVE 列為未列入 CISA 的已知遭利用漏洞（Known Exploited Vulnerabilities）目錄。CERT Santé 的警示紀錄記載「actively exploited: no」，並補充截至該日期，公開來源中並無概念驗證（proof of concept）存在。這些都不足以證明無人嘗試過；這只是表示沒有任何已記錄的嘗試。

至少有一個聚合器 Mallory 針對同一個識別碼流傳 8.7 的分數。NVD 的紀錄完全沒有 CVSS 4.0 指標——只有 GitLab 的 7.3 與 NIST 的 8.1——因此該數值無法從任何已檢視的第一方來源重現，本文也未予採用。

什麼是已經確立的，什麼不是

檔案將此條目評定為信心等級 A、無爭議，且未記錄任何實際傷害。這個等級在此確實發揮作用：各文件彼此一致，且其中沒有任何一份描述傷害。下方的分歧，是一行摘要無法承載的部分。

• 已確認：Duo Claude AI agent 中的一項缺陷，讓已通過驗證的 Developer 角色得以在 CI 環境中執行任意命令，因為該代理程式處理了來自使用者可控來源的設定。GitLab 將其評定為 CWE-829，CVSS 為 7.3。

• 已確認：受影響範圍與修正 — 18.9 至 19.1.7、19.2 至 19.2.5、19.3 至 19.3.1，已於 2026 年 8 月 26 日在 19.1.7、19.2.5 和 19.3.1 中修補。該漏洞記錄於 GitLab EE；同一版本也修補了 CE，但針對的是另一個漏洞。

• 已確認：透過 GitLab 的 HackerOne 計畫將回報功勞歸給 thwin_htet，以及 GitLab 向客戶提供的營運狀態——GitLab.com 已修補，GitLab Dedicated 不在所需行動的範圍內，自架安裝則被要求立即升級。

• 已確認：目前未接獲任何實際利用的通報。CISA 的 SSVC 評估顯示並無任何利用；EPSS 截至 2026 年 10 月下旬仍低於百分之一；根據 OpenCVE，該 CVE 並未列入 KEV 目錄；CERT Santé 於揭露後隔日記錄到並無實際利用情形。

• 據稱，但未經廠商確認：這些影響描述——機密可被讀取、產出物可被竄改、發行版本可被篡改——是 coverage 對於 CI 作業權杖範圍一般允許哪些操作的說法，而非認定本案中確實發生任何上述情況。Cyber Security News 與 GBHackers 都以「可能」（could）和「取決於」（depending on）來描述；兩者均未報導實際案例。

• 尚未確認：涉及哪項 Duo 功能、哪個設定欄位，以及使用者控制的來源實際上為何。廠商聲明並未指明這些項目。

• 尚未確定：有多少自我管理的 Enterprise 安裝位於受影響的範圍內、有多少在 2026 年 8 月 26 日之後完成升級，或是否有任何遭到攻擊。所檢視的來源均未衡量採用情況，且廠商並未針對較晚修補的執行個體發布任何偵測方法。

• 尚未確定： 技術機制。根據 GitLab 的 90 天規則，該議題大約會在 2026 年 11 月下旬公開；在那之前，連結的追蹤項目僅是指向一份尚未公開存在的說明。

修復、停機時間，以及 90 天的等待

GitLab 於 2026 年 8 月 26 日為社群版與企業版發布了 19.3.1、19.2.5 和 19.1.7，並表示強烈建議所有自行管理安裝的用戶立即升級至其中一個版本。此次發布的社群版部分之所以重要，是因為同批次的另一個漏洞——CVE-2026-77801，一個存在於匯入流程、評級為 6.5 的阻斷服務問題——同時影響 CE 和 EE。CVE-2026-18252 本身僅記錄於企業版。

目前沒有廠商提供的因應措施。CERT Santé 的警示指出並不存在任何因應措施，而 GitLab 的說明也未提供任何因應方式；唯一列出的補救措施就是升級。此版本也並非可直接替換。它包含三個版本皆適用的常規資料庫遷移，以及 19.3.1 與 19.2.5 的部署後遷移；GitLab 表示，在單節點安裝環境中，遷移完成期間將導致停機。多節點部署則可使用 GitLab 的零停機升級程序。

其餘六項修正值得一看，因為其中一項與本條目的主題相近。CVE-2026-15387 評分為 4.3，並於相同三個版本中修正；此漏洞讓具有開發者角色權限的已驗證使用者，能透過不當處理作業相依性，影響 Pipeline Execution Policy 強制執行作業的執行環境。兩條以開發者角色進入作業執行的路徑，一條評為高風險、一條為中風險，都在同一個修補程式中關閉。

GitLab 的揭露政策說明了為何該機制仍不透明。其修補說明指出，詳述各漏洞的議題會在修補該漏洞的版本發布後 90 天，於議題追蹤器上公開。從 2026 年 8 月 26 日起算，CVE-2026-18252 的技術說明文章將落在 2026 年 11 月的最後一週。在此之前，CVE 紀錄中的追蹤器參照背後，並沒有任何本文能讀到的公開技術說明。

這與 GitLab 其他代理程式漏洞的相對定位

GitLab 於 2026 年 10 月 2 日揭露了第二起、另一起與代理程式相關的漏洞：CVE-2026-90970，評分 9.9，存在於 AI Gateway 而非 Duo Claude AI 代理程式之中，且可透過特製的流程提示範本觸及，而非透過 CI 設定。這兩個是在不同元件中、具有不同分數的不同錯誤，而封存庫將它們列為各自獨立的條目。它們的共同點在於形態——交付路徑中的 AI 元件，會依據低權限使用者可影響的設定採取行動——這正是為何十月的那個漏洞值得與這個漏洞並讀，而不是取而代之。

對營運者而言，決策空間很有限。檢查版本：19.1.7、19.2.5 和 19.3.1 是已修復的版本，而三個指定版本範圍內的任何版本都會受影響。期間沒有可供採行的替代緩解措施，而且直到十一月下旬，都還沒有公布技術說明，可用來稽核延後修補的執行個體。現有的紀錄是沒有人回報曾遭利用——這只是在陳述缺乏證據，並非供應商保證未曾發生入侵。