Plugin4Shell：四個 AI 編碼代理信任了它們從未檢查的 Pin

2026 年 9 月 17 日，專為企業 AI 代理打造安全工具的初創公司 AIR Security 發表研究，描述了 Plugin4Shell——一個存在於四款 AI 編碼代理中的零點擊遠端程式碼執行漏洞：Anthropic 的 Claude Code、OpenAI 的 Codex、GitHub Copilot 以及 Google 的 Gemini CLI。這個缺陷並不在任何模型之中，而是出在每個代理安裝外掛程式時所執行的 git checkout，以及這四款代理都沒有驗證自己收到的程式碼，是否就是當初所鎖定的那份程式碼。研究公開時，四款之中已有兩款推出修補程式，另外兩款則沒有。這起事件是Orca AI 事件檔案庫中的一筆紀錄，該檔案庫將其登錄為高嚴重性的供應鏈漏洞，且未傳出任何遭到利用的通報。

這些代理人實際上做錯了什麼

每個受影響的代理程式都會從市集安裝外掛程式，而每個市集在外掛程式經過審查後，會把該外掛程式固定到特定的 git commit——一個 40 字元的 SHA。這個固定就是整個安全模型：審查者核准一個不可變版本，而即使背後儲存庫之後變更，代理程式也應持續執行該版本。AIR 將這個缺陷描述為外掛程式 SHA 固定繞過。代理程式會簽出市集所固定的確切 commit，但從不驗證它最終得到的工作樹就是該 commit。用研究人員的話來說，代理程式「會簽出市集所固定的確切 commit，但從不驗證它是否真的落到那裡，因此控制外掛程式儲存庫的攻擊者可讓簽出結果解析為惡意程式碼，而固定機制仍看似受到遵守。」

Git 補上了這個缺口。當某個名稱同時是有效分支和提交物件時，git 會優先採用分支，只印出歧義警告。控制此外掛程式儲存庫的攻擊者會建立一個名稱正好是該 40 位十六進位固定 SHA 的分支，讓它指向惡意程式碼，並把該分支設為儲存庫的預設分支。接著，單純執行複製就會把該分支以 SHA 形狀的名稱帶到本機，而後續的簽出就會解析到它。固定提交本身可以維持不變，因此受檢版本看起來毫無異狀。根據 AIR，必須同時符合兩個條件：以 SHA 命名的分支必須是預設分支，因為非預設分支只會以遠端追蹤 ref 的形式被擷取，而簽出會退回真正的提交；而且 git 主機必須接受 40 位十六進位的分支名稱。GitHub 會直接拒絕這類名稱。Bitbucket 和自架 git 伺服器則不會。

Gemini CLI 透過另一條途徑失敗了。它擷取了固定提交，將其記錄在儲存庫的 FETCH_HEAD 檔案中，然後執行 FETCH_HEAD 的 checkout——這個 checkout 不必讀取該檔案。若某個儲存庫的預設分支本身就叫 FETCH_HEAD，checkout 就會被重新導向到攻擊者控制的內容，並悄悄丟棄已擷取的提交。Cybersecurity News 對該機制的說法與 AIR 相符，包括對這兩種變體的區分。

為什麼沒有人需要點擊任何東西

相同的 checkout 會在背景外掛自動更新期間再次執行，而這是 Claude Code 與 Codex 的預設行為。這正是讓該攻擊成為零點擊、而不只是悄無聲息的原因：當某個市集把固定的 SHA 升為例行的新版本時，每個已安裝該外掛的代理程式都會在沒有提示、也沒有使用者操作的情況下重新執行 checkout。AIR 的重點是，受害者不必粗心安裝任何東西。他們只需從信任的市集安裝一個外掛，而該外掛已完全依照設計原意經過審查並固定。

有兩種方法可以達到那個位置，而且兩者都不需要控制市集。第一種是，攻擊者發布一個真正無害的外掛，讓它通過審查、累積安裝量、推出正常更新，然後才建立那個以惡意命名的分支。第二種是，攻擊者接管別人撰寫、且市集已經信任的外掛背後的儲存庫，然後把惡意版本推送給所有已安裝該外掛的人。

這兩條途徑背後的數字來自 AIR 較早的研究，而非 Plugin4Shell。在一場該公司稱為 The Story of Skills 的活動中，它表示其打造的一個外掛程式在被撤下前已散佈到超過 26,000 個代理程式。在 SkillJacking 中，它報告指出，已有 925 個正在使用中的技能遭人從其原始維護者手中接管，觸及 134,000 個代理程式。AIR 在 Plugin4Shell 文章的標題宣稱「數百萬個代理程式受到影響」；該研究並未提供暴露安裝數量的統計，也沒有任何第三方公布過這樣的數字。

時間軸，以及修正落實的位置

AIR 表示，它於 2026 年 5 月發現這項漏洞，並握有可實際運作、能攻擊全部四個代理的概念驗證漏洞利用程式，隨後於隔月依協調式揭露原則向各廠商通報。Anthropic 已於 6 月 17 日在 Claude Code 2.1.179 中確認修復。Google 於 8 月 4 日告知 AIR 不會推出修復，因為 Gemini CLI 即將退役。Codex 0.146.0 已於 8 月 12 日驗證修復完成。微軟則尚未為 GitHub Copilot 推出修復。

這些修補版本是唯一公開證實該瑕疵在兩款已修復它的產品中確實存在的依據。Anthropic 針對 2.1.179 發布的更新日誌條目列出連線中斷處理、WSL2 捲動、沙箱 glob 與介面修正，且完全未提及 pinning、外掛驗證或任何類型的安全修復。根據 The Next Web 的報導，The Hacker News 也做出相同觀察。截至該研究發表時，尚未指派任何 CVE 識別碼；而 Cloud Security Alliance 關於該瑕疵的研究備註也重申，在通知廠商三個月後仍不存在任何識別碼。

四家供應商，三種不同的答案

Google 做得比拒絕修補更進一步。它棄用了 Gemini CLI，這意味著只要人們繼續執行既有的安裝，這些安裝就會一直暴露在風險之中。它的建議是遷移到 Antigravity，這個較新的代理式開發環境；AIR 表示該攻擊無法觸及它，因為它沒有可供繞過的市集外掛 SHA 釘選機制。

GitHub 的立場又有所不同。GitHub 發言人向 The Register 表示，該平台不允許使用者建立與提交 SHA 相似的分支或標籤名稱，並表示「這項緩解措施確保所回報的漏洞無法在 GitHub 上被利用」。AIR 質疑的是該緩解措施的適用範圍，而非其是否存在：研究人員向 The Register 表示，市集可託管於 Bitbucket 等其他平台，而 GitHub Copilot 仍支援來自這些平台的市集，因此分支名稱變體對 Copilot 使用者而言仍可觸達。AIR 也表示，Anthropic 自家的文件將 Bitbucket 與自架 Git 列為有效的市集後端；Anthropic 目前的市集文件說明可從 Git 儲存庫 URL 新增市集，而不僅限於從 GitHub 新增。微軟未回覆 The Register 的置評請求，而 AIR 表示自 6 月回報該問題以來，尚未收到微軟的任何回應，並提及該公司正在處理大量揭露事項。

這是在爭論暴露範圍有多大，而不是這個錯誤是否存在。GitHub 的緩解措施是主機層級的限制；AIR 的發現是，檢查必須在 agent 內部進行，因為 pin 是在用戶端解析的。

哪些是已經確立的，哪些則尚未

• 已確立：該機制。AIR 的報告提供了確切的 git 指令、ref 優先於 object 的解析規則、分支技巧所需的兩項條件，以及針對 Gemini CLI 的獨立 FETCH_HEAD 變體。The Register、Help Net Security、Cybersecurity News、InfoWorld 與 The Next Web 均以相同方式報導。

• 已確認：兩個已修補版本。根據 AIR 的披露時間表，Anthropic 於 2026 年 6 月 17 日確認 Claude Code 2.1.179，而 OpenAI 的 Codex 0.146.0 則於 2026 年 8 月 12 日獲核實已修復。

• 已確認：披露時有兩項產品尚未提供修補程式。Google 不會修補 Gemini CLI，並將予以汰除；Microsoft 尚未推出 Copilot 修正程式。

• 尚未確立：獨立重現。所有已發表的記述都可追溯至 AIR 自己的部落格文章，而 Cloud Security Alliance 的研究備註明確表示，其並未描述第三方技術驗證或對該漏洞的獨立重現。基於此原因，存檔將此紀錄的信心等級評為 B。

• 尚未確定：實際有多少安裝項目暴露於風險中。「數百萬」是 AIR 在其標題中的表述，並非實測數字。

• 尚未確定：更新受影響的代理程式，究竟會移除已經被替換的外掛程式，還是只會防止下一次替換。目前尚無已發布的資料來源能釐清此事。

• 尚未確立：任何真實世界中的用途。紀錄中沒有任何來源報告漏洞利用、探測或攻擊者基礎設施，而該檔案將實際損害記錄為不實。這是缺乏報告，而非什麼都沒發生的證據。

一項第三方查核確實限縮了實際情況。The Next Web 在摘要《The Hacker News》的查核時報導，Anthropic 社群目錄以及預設 Claude Code 與 Copilot 目錄中的外掛都指向 GitHub 儲存庫，而且自動更新主要只對那些內建市集預設開啟。由於 GitHub 拒絕 SHA 形式的分支名稱，對於沿用預設目錄的使用者而言，分支名稱變體較難觸及。該推論並未涵蓋 Gemini CLI 的 FETCH_HEAD 變體，因為該變體不取決於主機如何命名分支。

修復方案必須是什麼樣子

AIR 建議的修正方案只有一條斷言：在 checkout 之後，解析實際存在於工作樹中的提交，並在其不等於固定的 SHA 時中止。研究人員強調，它必須檢查解析後的 HEAD，而不是所請求的 ref，因為這個區別正是 Gemini CLI 變體得以繞過的地方；而且它必須在 agent 內執行，因為 pin 是在客戶端解析的，沒有任何 marketplace 能強制執行它所宣稱的保證。

針對運行這些代理程式的團隊所提供的實用建議，取材自 AIR、Cybersecurity News，以及 InfoWorld 中的分析師評論：

• 將 Claude Code 更新至 2.1.179 或更新版本，並將 Codex 更新至 0.146.0 或更新版本。在有修補程式的情況下，更新是唯一完整的緩解措施。

• 在任何沒有修補程式的代理程式上，停用外掛程式的自動更新。這會把該漏洞從零點擊降為手動重新安裝，這只是降低暴露風險，而不是修復。

• 與其等待 Google 表明不會推出的修補程式，不如從 Gemini CLI 遷移開來。

• 稽核外掛程式清單，並盡可能限制市集來源。AIR 指出，市集可透過僅允許會拒絕 SHA 形式名稱的主機，來削弱分支名稱變體，實質上僅限 GitHub；但這麼做會封鎖代理程式官方支援的主機，而且對 Gemini 變體毫無作用。

• 將工作站視為曝險邊界。外掛程式會繼承代理程式的權限，因此一旦漏洞利用成功，就能以開發者自身的權限觸及原始碼、SSH 金鑰、雲端憑證、CI/CD 權杖與內部儲存庫。Pareekh Consulting 首席分析師 Pareekh Jain 向 InfoWorld 表示，安全團隊應檢視 EDR、git、CI/CD、雲端 IAM 與身分驗證日誌，尋找異常程序、非預期的外掛檔案、遭變更的儲存庫及可疑的 git 活動——並補充，這些步驟能降低風險，卻無法修正根本缺陷，而他將該缺陷歸因於廠商程式碼。「企業可以對外掛程式的使用加以控管，」他向 InfoWorld 表示，「但無法修正程式碼代理驗證其所簽出程式碼的方式中的缺陷。」

為什麼 pinning bug 才是真正重要的那一個

SHA 釘選（pinning）是業界針對 AIR 早已實際展示過的那類接管攻擊所提出的解方：一旦公開儲存庫遭到入侵，代理程式仍會繼續執行經過稽核的雜湊，而不會去拉取攻擊者推送的任何內容。Plugin4Shell 並沒有破解雜湊。它揭示的是：這些代理程式把釘選值解析成一個只是「看起來像」該雜湊的分支名稱，而且從未比對解析結果。建立在這項假設之上的一切下游環節——審查流程、內部允許清單，以及開發者對釘選版本的信任——全都繼承了這個失效。

這些紀錄無法佐證「有任何東西被取走」的說法。這是一個已被發現的漏洞，而且在四起案例中有兩起已修復；其中沒有任何來源通報入侵，而未推出修補程式的產品仍在等待。最令人不滿意的正是那個懸而未決的問題：對任何曾在未修補的代理程式上執行外掛的人來說，沒有公開的方法能判斷實際執行的程式碼是否就是他們所核准的程式碼。