四大 AI Coding Agent 全部中鏢的 Plugin4Shell——插件自動更新，變成攻擊者要的那道後門
Jacky ChenAI 系統架構顧問 · 擁有 HR 與獵頭背景的 AI 開發者一句話答案
資安公司 AIR Security 於 2026 年 9 月 17 日揭露名為 Plugin4Shell 的零點擊遠端程式碼執行（RCE）漏洞，影響 Claude Code、OpenAI Codex、GitHub Copilot、Gemini CLI 這四款主流 AI coding agent。漏洞原理是這些工具在安裝插件時會鎖定一個特定的 Git commit（SHA pinning），但事後從不驗證實際取出的內容是否真的對應那個 commit——攻擊者只要在自己控制的插件儲存庫裡，建立一個名稱跟那串 40 位十六進位 commit hash 一樣的分支，Git 就會優先解析成該分支而不是原本鎖定的 commit，程式碼就這樣被偷換掉。因為 Claude Code 與 Codex 預設會在背景自動更新已安裝的插件，使用者不需要按下任何核准，只要插件市集上游被動過手腳，下一次背景更新就會自動中招，是不折不扣的零點擊攻擊。截至 2026 年 9 月的報導，Anthropic 已在 Claude Code 2.1.179 修補、OpenAI 已在 Codex 0.146.0 修補；Google 選擇不修 Gemini CLI、直接將使用者導向另一款產品 Antigravity；Microsoft 的 Copilot 修補狀態則仍有爭議——微軟認為透過 GitHub 本身這條路徑已經被 GitHub 的命名限制擋住，但研究人員指出透過 Bitbucket 或自架 Git 伺服器安裝插件時風險依然存在，微軟尚未針對這條路徑發布修補。
2026 年 9 月 17 日，資安公司 AIR Security 揭露一個叫 Plugin4Shell 的零點擊漏洞——Claude Code、OpenAI Codex、GitHub Copilot、Gemini CLI 這四款主流 AI coding agent 全部中鏢。問題出在這些工具安裝插件時標榜的「鎖定版本」（SHA pinning）機制，實際上從不驗證真正取出的內容有沒有對應那個版本，攻擊者只要在自己控制的插件儲存庫動一點手腳，就能讓使用者在毫無察覺、完全沒有按下任何核准的情況下，透過背景自動更新換上惡意程式碼。截至目前，四家廠商的修補進度還不一致。這起事件值得企業注意的不是技術細節本身，是它示範了一件事：裝一個現成的 AI agent 工具，跟「這個工具背後的供應鏈有沒有人把關」，是兩件不同的事。
Plugin4Shell 到底是什麼漏洞？
這些 AI coding agent 都支援安裝第三方插件來擴充功能，為了防止插件被偷換成惡意版本，設計了「鎖定某個特定 Git commit」的機制——你安裝的時候，系統記住這個插件對應哪一個 40 位十六進位的 commit hash，理論上之後只會用那個版本。問題是，這些工具在安裝與更新時只會「要求」Git 取出那個 commit，卻從來不驗證最後實際取出來的工作目錄，是不是真的對應那個 commit。AIR Security 的研究人員（Or Nevo、Dor Granat、Niv Hoffman）發現，攻擊者只要在自己控制的插件儲存庫裡，建立一個「名稱」剛好跟那串 commit hash 一模一樣的分支（branch），Git 在解析這類名稱時會優先當成分支參照（reference），而不是原本鎖定的 commit 物件——鎖定機制表面上看起來沒變，取出來的程式碼內容卻已經被換掉。
為什麼叫「零點擊」——使用者什麼都沒做，就已經中了？
一般的供應鏈攻擊多少還需要使用者做點什麼：點下一個連結、核准一次更新、手動安裝一個新版本。Plugin4Shell 不需要。Claude Code 與 Codex 這類 agent 預設會在背景自動更新已經安裝的插件——這個設計原本是為了讓使用者不用自己手動維護版本，結果變成攻擊者最好用的管道：只要插件市集上游的那個分支被動過手腳，下一次背景自動更新重新執行同一套「取出鎖定 commit」的流程時，就會把惡意版本換進來，使用者連「有更新發生」這件事都不會被通知，更不用說核准。這也是為什麼 AIR Security 把它定性為業界「第一個針對 AI agent 生態系的供應鏈攻擊」——攻擊的不是模型本身，是模型周邊那整套插件市集的信任假設。
四家廠商的修補進度，到現在還不一樣
截至 2026 年 9 月的報導，四家廠商的應對明顯分成三種：Anthropic 已經在 Claude Code 2.1.179 版修補這個問題，OpenAI 也已經在 Codex 0.146.0 版修補；Google 的做法比較乾脆——不修 Gemini CLI，直接把這款產品列為淘汰，請使用者改用另一款產品 Antigravity；Microsoft 的 Copilot 狀況則還有爭議，微軟一方的說法是透過 GitHub 平台本身這條攻擊路徑已經被 GitHub 的分支命名限制擋住（GitHub 不接受跟 40 位十六進位 commit hash 完全相同的分支名稱），但 AIR Security 的研究人員指出，只要插件是透過 Bitbucket 或企業自架的 Git 伺服器安裝，這條路徑依然可以被利用，而微軟尚未針對這個情境發布修補。換句話說，「這個漏洞修好了沒有」，到目前為止沒有一個單一答案，要看用的是哪一款工具、插件又是從哪個 Git 服務安裝的。
企業如果只是把這些工具裝上去就當作「已經導入 AI Agent」，漏掉了什麼？
這起事件揪出的根本問題，不是某一家廠商的程式碼寫得不夠仔細，是「鎖定版本」這個防護機制設計在 agent 端，而 agent 端的驗證邏輯本身就不夠完整——AIR Security 的結論是，任何單一的插件市集都沒辦法靠自己把這個風險完全擔保掉，因為檢查的環節根本不在市集那一層。對企業來說，這代表一件更直接的事：如果工程團隊自己裝了 Claude Code、Copilot 這類工具，再裝上幾個第三方插件來加速開發，卻沒有人去確認「這個插件來源可信嗎」「背景自動更新這個設定開著安全嗎」「版本鎖定機制真的鎖得住嗎」，供應鏈信任這一塊就是一個沒人在管的空白。裝一個現成工具很容易，但「這個工具跟它背後整條供應鏈，有沒有經過風險評估跟版本控管」，從來不是裝上去那一刻就自動解決的事。
這跟「找 aijob 做客製化系統／AI Agent 整合」有什麼關係？
我們在〈連 Google 都會設定錯：Gemini 紅隊測試意外駭入三家真實公司〉裡談過環境隔離與權限邊界的問題——那篇講的是「AI 代理實際能碰到哪些系統」，Plugin4Shell 講的是另一塊同樣容易被忽略的風險：工具本身與它仰賴的第三方生態系，有沒有人在把關。這兩塊合起來才是「導入 AI Agent」真正要處理的範圍，不是裝一個聊天視窗或裝幾個插件就算完工。我們在做客製化 AI Agent 整合時，會把第三方套件與插件的來源評估、版本鎖定與自動更新設定，當成系統架構設計的一部分去處理，而不是上線後才發現漏洞。如果你的團隊正在用這類工具加速開發，或正在評估要不要讓 AI agent 深入接觸公司系統，聊聊你的情況，我們會先幫你盤點目前用的工具與插件實際有哪些存取範圍，再決定風險控管該補在哪裡。
出處
1. Help Net Security——Zero-click RCE vulnerability hit four major AI coding agents, two remain unpatched（2026-09-18 發布）https://www.helpnetsecurity.com/2026/09/18/plugin4shell-ai-coding-agents-vulnerability/
2. The Register——AI coding agents' 0-click RCE flaw could hand attackers keys to the kingdom（2026-09 發布）https://www.theregister.com/a/5297335
3. CSO Online——A zero-click RCE flaw in AI coding agents could have exposed enterprise systems（2026-09 發布）https://www.csoonline.com/article/4223909/a-zero-click-rce-flaw-in-ai-coding-agents-could-have-exposed-enterprise-systems-2.html
常見問題
Plugin4Shell 這個漏洞，名字裡的「Shell」是什麼意思？＋
命名方式呼應過去知名的 Log4Shell 等供應鏈／遠端程式碼執行漏洞慣例，用來強調這是一個能讓攻擊者取得遠端程式碼執行能力的嚴重漏洞，不是字面上跟 shell 指令本身有關。
我的公司有用 Claude Code 或 Codex，現在還有風險嗎？＋
如果已經更新到 Claude Code 2.1.179 以後、或 Codex 0.146.0 以後，官方說法是這個漏洞已經修補。建議直接確認目前安裝的版本號，而不是假設「背景自動更新應該已經處理好了」——背景自動更新正是這個漏洞原本被利用的管道，確認版本號是比較保守的做法。
Gemini CLI 不修這個漏洞，代表還在用的人會怎樣？＋
Google 的做法是把 Gemini CLI 列為淘汰產品，不會再發布修補，並建議使用者改用另一款產品 Antigravity。如果公司內部工程團隊還在用 Gemini CLI 並且安裝了第三方插件，這個漏洞會持續存在，直到停用或換用其他工具為止。
這起事件造成實際的資料外洩或損害了嗎？＋
目前查到的公開報導都停留在「漏洞揭露與廠商修補進度」的階段，沒有看到具名的實際攻擊案例或資料外洩事故被公開證實。這類揭露通常是資安研究人員先私下通報廠商、廠商修補後才公開細節，跟「已經發生的攻擊事件」是不同性質的新聞。
中小企業沒有專職資安人員，要怎麼管理這類風險？＋
至少可以先做兩件事：確認團隊用的 AI coding agent 版本是否已經更新到有修補的版本，以及盤點目前裝了哪些第三方插件、來源是否可信。如果公司正在規劃更深入的 AI Agent 整合（例如接上內部系統或客戶資料），這類第三方工具與插件的風險評估，建議當成專案的一部分一併處理，而不是留給工程團隊自己臨時判斷。
還有其他問題？看完整常見問題 →
Jacky Chen · AI 系統架構顧問
讀到這裡，如果你手上正好有個流程想自動化、或想把 AI 變成一套真的能營運的系統——直接找我聊。一次免費的技術診斷，我幫你看清最值得先動的是哪一塊，不繞圈子、不推你不需要的東西。