Plugin4Shell：Git 參照遮蔽，讓外掛程式繞過已審查的版本固定

全面盤點實際執行中的客戶端執行檔與外掛載入器版本；受影響的 Claude Code 應升級至 2.1.179 或更新版本，Codex 則應升級至包含 0.146.0 修補的受支援版本，隨後驗證執行檔雜湊並進行受控的 SHA 遮蔽反向拒絕測試。Claude Code 的資安通告適用於低於 2.1.179 的版本，不得將相同的 CVE 或版本邊界逕行套用至其他客戶端。在尚未獲得已驗證修補版本前，應透過集中管理政策直接停用該外掛及其更新管道，絕不能單憑市集審查標章便予以放行。

外掛應該一律經由企業自己的安裝中介服務來安裝，由它提供經審查、位元組完全確定的外掛內容。中介服務對每個外掛版本保存一份綁定雜湊值的核准決定，把那份快照裝進客戶端的外掛目錄，再回傳一張安裝紀錄，客戶端讀回安裝後的雜湊值核對；客戶端自己完全不去 clone 發布者的儲存庫，所以上游那個與 SHA 同名的預設分支，或名為 FETCH_HEAD 的分支，就沒有東西可以遮蔽。市集每一次重新固定版本，也要當成重新審查的觸發條件，而不是例行更新：只要固定的 SHA、發布者狀態或儲存庫預設分支任一項改變，就讓先前的核准失效、先暫停該外掛的背景更新，並針對新解析到的 commit 與它實際的檔案樹重新跑一次審查，確認通過後才讓任何客戶端收到更新。前提是把客戶端指向這個中介服務或由它供應內容的內部市集；沒有走這條路安裝的外掛不在保護範圍內。

將客戶端、外掛程式及所有 hook 子程序完整納入經嚴格驗證的受管虛擬機（MicroVM）或作業系統原生沙箱中，隔離並排除開發者家目錄內的 secrets、主機 agent 通訊通訊端（socket）以及未受限的正式環境目錄掛載。此防護能有效侷限惡意替換程式碼啟用後所能存取的主機資源。若沙箱僅包覆模型工具呼叫層，將完全遺漏外掛載入器直接執行的程式碼；必須確保外掛載入器與背景更新程序均在同一外層沙箱邊界內運作。

在外掛匯入或任何 hook 程式碼執行前，完整盤點客戶端載入器可能讀取的外掛清單，將確切套件內容複製至受保護且不可變的預備暫存區，並依據獨立簽署的允許清單嚴格校驗發布者身分、版本與內容雜湊值，隨後僅載入該份通過驗證的位元組內容。單純檢查請求的 Git ref、指令執行成功回傳碼或由外掛自行回報的清單均不足以確認安全。此指引要求各主機環境具備專屬的啟用前檢查介面；在所有載入管道（包含 Gemini CLI 特殊的 checkout 路徑）均完成驗證前，需由受控客戶端或軟體供應商協同整合落實。

外掛目錄裡實際放的東西，要拿來和核准的固定版本重新比對。由一支用獨立唯讀身分執行的檔案完整性檢查工作，把每個已安裝外掛的 HEAD commit 與檔案樹雜湊值，對照市集核准的 SHA 和事先存好的檔案清單，只要不一致就產生發現，包括「要求的 ref 和實際解析到的 HEAD 不同」，以及 checkout FETCH_HEAD 卻解析到攻擊者命名分支這兩種情況；每次更新後、客戶端下次啟動前都跑一次。兩種變體被偷換的 checkout 它都抓得到，不過這是檔案寫入磁碟之後的偵測，能不能趕在啟用之前，取決於更新到下次啟動之間有多少時間，所以它是載入器檢查的輔助，不是替代。

萬一被偷換的外掛程式碼真的跑起來，至少要限制它連得到哪裡。在裝著客戶端、更新程式與 hook 的沙箱外層，對外連線預設全部阻擋，只放行市集、模型端點和任務需要的儲存庫，並從沙箱內實測原始 IP、重新導向、Proxy 與 DNS 是否真的被擋。這能阻斷啟用後的回連與大量資料外傳；但擋不住本機破壞，也擋不住它讀取沙箱仍暴露出來的東西，而且研究並沒有示範特定的外洩目的位址，所以這一步的效果是圍堵，不是已驗證的阻斷。

一旦確認某個外掛被分支遮蔽偷換，就要把它從所有能載入的地方清掉，不能只清發現問題的那一台。先列出每一台裝過受影響外掛或版本的客戶端，保留被偷換的檔案內容供鑑識，再移除外掛目錄與快取的 clone，並在安裝中介服務或市集把惡意的 commit 與檔案樹雜湊值列入拒絕名單，讓任何更新程式都拉不回來，最後依雜湊值確認沒有任何執行中的客戶端還留著它；重新安裝時只能用已審查的快照。這是事後應變，而且要靠前面幾項控制建立的盤點資料才做得到。