Plugin4Shell 影響哪些 AI coding agent？插件 SHA 驗證與盤點清單
Plugin4Shell 是 2026 年 9 月公開的 AI coding agent Plugin supply-chain 研究。它指出一個容易被忽略的差異：安裝器「想要 checkout 某個 commit」不代表最後工作目錄真的停在那個 commit。如果代理程式只相信 fetch 或 checkout 的輸入值，卻沒有讀回 git rev-parse HEAD 驗證結果，移動中的 branch、tag 或遠端內容就可能讓實際載入的程式碼和預期版本不同。
直接答案是：先列出每個 agent 實際載入的 Plugin 與 commit，再核對工作目錄的 HEAD 是否等於預期 SHA；無法確認修補狀態時先停用自動更新與高權限 Plugin，並把 agent、Plugin、token、workspace 和 sandbox 分開盤點。 本文只整理防禦檢查，不提供利用漏洞的步驟，也沒有在本機重現攻擊。
先分清楚：研究報告、修補狀態與你的環境
Air Security 於 9 月 17 日公開 Plugin4Shell 研究，Cloud Security Alliance（CSA）在 9 月 18 日發布研究摘要。兩份資料都描述了 Plugin checkout 與 SHA 驗證之間的風險；CSA 也提醒當時尚未有 CVE。這些是公開研究的時間點，不是「所有版本現在都一定受影響」的判決。
目前能確認的資訊應分三層讀：
- 漏洞模型：Plugin 來源或 branch 被替換後，安裝流程可能沒有確認實際 resolved HEAD 是否等於預期 SHA。
- 產品修補：不同 agent 的修補版本與策略不同，不能用一個 agent 的版本號推論另一個 agent 已修好。
- 部署實況：即使 agent 已升級，既有 Plugin checkout、cache、workspace mount 與 token 權限仍要重新盤點。
公開資料中的版本線索
| Agent | 截至查核日的可用線索 | 使用時的保守做法 |
|---|---|---|
| Claude Code | Air Security 與 CSA 將修補線索指向 Claude Code 2.1.179；Anthropic 的 release 頁面仍應以目前版本與公告為準 | 升級到供應商目前支援版，重新檢查既有 Plugin，不要只更新 CLI binary |
| Codex | OpenAI Codex rust-v0.146.0 release 的 changelog 列出「Verify Git plugin SHA checkouts」 | 使用目前支援版本，並以實際 checkout HEAD 驗證防護是否生效 |
| GitHub Copilot | CSA 研究摘要當時沒有記錄 Microsoft 已公開相同修補確認 | 以目前官方公告確認前，停用不必要的第三方 Plugin 或自動更新 |
| Gemini CLI | CSA 摘要記錄 Gemini CLI 的產品處置是棄用並轉向 Antigravity，而不是照搬其他 agent 的 patch | 不要把舊 Gemini CLI Plugin 流程當成仍受支援的安全基線 |
上表的版本線索不是長期保證。若你的環境由企業管理、封裝映像或內部 Plugin registry 控制，還要以實際安裝 commit、發布渠道與 administrator policy 為準。
十分鐘 Plugin 盤點流程
1. 列出「實際啟用」而不是「曾經安裝」的 Plugin
先從每個 agent 的設定、Plugin directory、lock file、container image 與啟動 log 找出：
- Plugin 名稱、來源 repository、branch／tag 與預期 commit SHA。
- 實際 checkout 路徑、最後更新時間與目前 agent 版本。
- Plugin 能讀取的 workspace、環境變數、Secrets、shell、browser、network 與外部 API。
- 是否開啟自動更新，更新由誰觸發，以及失敗時是否會繼續啟動舊 cache。
「在 registry 看得到」或「以前裝過」都不等於目前回合會載入；把 inventory 和實際啟動 log 對照，才知道需要修補哪一份 checkout。
2. 讀回 HEAD，不能只比對設定檔
下列是可套用到一般 Git Plugin workspace 的示意檢查。PLUGIN_DIR 與 EXPECTED_SHA 必須替換成你的實際值；這段命令沒有在本文環境執行：
plugin_dir=/path/to/pluginexpected_sha=0123456789abcdef0123456789abcdef01234567
actual_sha="$(git -C "$plugin_dir" rev-parse HEAD)"printf 'expected=%s\nactual=%s\n' "$expected_sha" "$actual_sha"
if [ "$actual_sha" != "$expected_sha" ]; then printf '%s\n' 'Plugin checkout does not match the expected commit.' >&2 exit 1fi再保存一份不含 Secret 的版本證據：
git -C "$plugin_dir" show -s --format='%H%n%ci%n%s' HEADgit -C "$plugin_dir" status --shortgit -C "$plugin_dir" remote -v如果 Plugin 目錄不是 Git checkout，改從套件 lock、image digest、release artifact checksum 或 agent 提供的安全驗證報告取得證據；不要自行把「資料夾名稱看起來像版本」當作固定版本。
3. 安裝或更新後立即再驗證
安全的更新流程至少要在 checkout 後重新讀回 HEAD。概念上應包含：
git fetch --quiet origin "$expected_sha"git checkout --detach "$expected_sha"actual_sha="$(git rev-parse HEAD)"test "$actual_sha" = "$expected_sha"這只是一般 Git 專案的驗證示意；各 agent 的 Plugin manager 可能使用自己的 cache、sandbox 或 package format。若 manager 沒有公開實際 resolved commit，也就不能把設定中的 pin 宣稱為已驗證的安全保證。
暫時無法確認時怎麼降風險
無法確認 agent 版本、Plugin SHA 或修補狀態時，先做可回復的限制：
- 暫停該 Plugin 的 auto-update 與自動載入；不要為了保持便利而讓未知版本繼續取得新 token。
- 停用不必要的 shell、browser、寫檔、network 與 production credential，讓 Plugin 只看到測試 workspace。
- 保存 agent version、Plugin repository、實際 HEAD、安裝時間與 log；不要先刪除可能有用的證據。
- 用乾淨 checkout 或經驗證的 image 重新安裝，再做最小權限 smoke test。
- 如果 Plugin 曾能讀取高敏感 token 或執行外部副作用，依組織 incident policy 評估撤銷與輪替，不要只重新下載同一個 branch。
Plugin4Shell 的核心提醒不是「所有 Git Plugin 都不能用」，而是要把來源可信度、版本固定、實際 resolved commit 和執行權限視為四個分開的控制點。
AI coding agent 的最小權限檢查表
| 控制點 | 低風險預設 | 需要額外審查的訊號 |
|---|---|---|
| Repository | 只讀或測試 branch | 可 push、merge、改 CI 或讀取多個 repository |
| Secrets | 無 Secret 或單一短期 token | production key、長期 PAT、cloud credential、SSH key |
| Shell | allow-list 指令或隔離 container | 任意 shell、sudo、套件安裝、讀取 home directory |
| Network | 預設拒絕或只開必要 host | 任意外連、webhook、下載執行檔、上傳 workspace |
| 更新 | 人工 review 後切換固定版本 | branch auto-update、無法讀回 commit、背景自動安裝 |
| Recovery | branch／worktree、可重建 image、保留 log | 直接覆寫工作目錄、沒有 rollback 或 audit trail |
如果你正在整理 Codex Plugin 本機權限，也可以參考 Codex Plugin 目錄權限檢查清單。那篇聚焦目錄、檔案 owner 與本機權限；本文補上跨 agent 的 Git SHA 與 supply-chain 驗證。
不要把社群訊號當成修補證明
Threads、issue、轉貼與安全研究可以幫助你發現名稱、版本和產品範圍，但它們不能代替：
- vendor release notes 或 security advisory。
- 實際安裝版本與 resolved commit。
- 可重複的本機檢查、sandbox log 與最小權限測試。
本文查核日是 2026-09-21；Copilot、Gemini CLI 與各 agent 的修補狀態可能在之後變動。遇到新的公告時，先更新 inventory 與版本證據，再決定是否恢復自動更新。
常見問題
Q: 設定檔裡已經寫了 commit SHA，還需要讀回 HEAD 嗎？
A: 需要。設定值是輸入，git rev-parse HEAD 是 checkout 後的結果；兩者一致才能證明目前目錄停在預期 commit。若 manager 沒有暴露結果，就把它列為無法驗證的風險。
Q: 升級 Codex 或 Claude Code 後，既有 Plugin 會自動安全嗎？
A: 不要假設。先確認目前 agent 版本，再重新盤點 Plugin cache、實際 HEAD、權限與 token。升級 binary 不一定會重建每一份既有 checkout。
Q: Plugin4Shell 有 CVE 編號嗎？
A: 本文查核的 CSA 研究摘要指出當時沒有 CVE。這不影響你做版本、commit、權限與 auto-update 盤點，也不要把「沒有 CVE」解讀成「不需要處理」。
Q: 沒有企業資安團隊，也需要做這麼多檢查嗎？
A: 至少做 inventory、實際 HEAD 比對、停用不必要權限與一個乾淨 workspace smoke test。這四項成本低，卻能避免把未驗證的 branch 與高權限 token 同時交給 agent。
參考資料：
Cloud Security Alliance：Plugin4Shell AI coding agent supply-chain research note