4つのAIコーディングエージェントはプラグインをコミットハッシュに固定した。届いたものを誰も確かめていなかった

主要なAIコーディングエージェントは、いずれも同じ方法でプラグインを導入する。マーケットプレイスがプラグインを公開し、エージェントが特定の git コミットにピン留めし、そのピンが安全性の保証になる、という仕組みだ。コミットハッシュはコンテンツアドレス方式であり、こっそり書き換えることはできない。ピン留めはパッケージエコシステムにおけるサプライチェーンリスクへの標準的な答えであり、だからこそコーディングエージェントのプラグインマーケットプレイスは「解決済みの問題」として扱われてきた。

ところが AIR Security の研究者が公開した報告によれば、主要4製品——Anthropic の Claude Code、OpenAI の Codex、GitHub Copilot、Google の Gemini CLI——はいずれも、ピン留めしたコミットを git に要求したうえで、返ってきたものが本当にそのコミットかを確認していなかった。研究者はこれを Plugin4Shell と名付けている。4製品のうち2つは修正を配布済み。残る2つは未対応で、そのうち1つは今後も修正されない。

ピンは確認された。結果は確認されなかった。

欠陥はハッシュ自体にあるのではない。コミットを要求することと、その後ワーキングツリーに実際に何が入っているかを検証することの間の空白にある。OpenAI 自身の修正メモはこの挙動を端的に説明している。git は「要求されたコミット SHA をブランチ名として解釈しうる」ため、エージェントは「ピン留めしたものとは別のコミット」を手にしうる、というものだ。プラグインのリポジトリが曖昧な参照名を許容する場所にホストされている場合、そのリポジトリの所有者は、マーケットプレイスが一度も審査していないコードへとピンを解決させることができる。

AIR による欠陥の要約はもっと短い。

エージェントはマーケットプレイスがピン留めした正確なコミットをチェックアウトするが、そこに実際に到達したかは決して検証しない。

深刻さは、その次に何が実行されるかから来る。コーディングエージェントは開発者のシェル、認証情報、ソースツリーを握っている。プラグインの中に入り込んだコードは、そのすべての内側に入り込む。

バックグラウンドの自動更新がゼロクリック化させる

プラグインの導入は、開発者が一度だけ下す判断だ。しかし最新に保つことは、エージェントが継続的に下す判断である。プラグインは既定でバックグラウンドで自動更新されるからだ。防御側が最も警戒すべきなのはこの点であり、研究者もそう明言している。

これはインストール時だけのバグではない。だからこそゼロクリックなのだ。同じ git チェックアウトがバックグラウンドの自動更新で再実行される。

つまり3月に精査して導入したプラグインが、開発者が何も触らないまま9月に差し替えられうる。確認ダイアログもインストール操作もなく、新しいコードを人間が承認する場面も存在しない。

修正状況

AIR によれば、この問題は5月に発見され、6月に4社すべてへ報告された。9月18日時点で CVE 識別子は割り当てられておらず、4社のいずれもセキュリティアドバイザリを公開していない。つまり、セキュリティチームが通常監視している経路では、この件はまったく把握できなかったことになる。研究者は実環境での悪用の証拠はないとしている。

GitHub は「自社は影響を受けない」と言う。それはホスティングについての主張であって、エージェントについての主張ではない。

GitHub の立場は、自社プラットフォーム上のリポジトリに付けられる名前を制限しているため、この問題は自社ユーザーには届かない、というものだ。

GitHub はコミット SHA に似たブランチ名やタグ名の作成をユーザーに許可していない……したがって報告された脆弱性を GitHub 上で悪用することはできない。

これはその限りでは正確であり、GitHub にホストされたプラグインがこの変種から守られている理由でもある。研究者の反論は、それでは修正を置く層が違う、というものだ。Copilot をはじめとするエージェントは、他所にホストされたマーケットプレイス——Bitbucket、自前の git サーバー、社内ミラー——からも導入できるが、それらは GitHub の命名規則を引き継がない。AIR の言葉では「修正はエージェント側で配布されなければならず、更新することだけが完全な緩和策である」。

この対立はこの一件を超えた意味を持つ。プラットフォーム側の制限は、そのプラットフォームの利用者を守る。一方でエージェントは、何を実行するかを決める部品であり、あらゆる提供元からのあらゆる導入に必ず介在する唯一の部品だ。Microsoft によれば Fortune 500 のおよそ90%が Copilot を利用しており、その企業向けの訴求力の一部は社内マーケットプレイスへの対応にある——まさに GitHub の命名規則がカバーしない構成である。

取るべき対応

Claude Code は 2.1.179 以降、Codex は 0.146.0 以降へ更新すること。いずれもそれで対応は完了する。Copilot には修正がないため、取りうる管理策は組織的なものになる。開発者が導入できるプラグインマーケットプレイスを制限し、Microsoft がクライアント側の変更を出すまでは GitHub ホストのものを優先することだ。Gemini CLI には修正が一切提供されないため、移行はロードマップ上の判断ではなくセキュリティ上の判断になる。

より広い論点は、コーディングエージェントを取り巻くプラグイン層が、それを審査する仕組みより速く育ってしまったことにある。AIR が同じエコシステムで先に行った調査では、セキュリティ審査を通過したあとに外部から取得するリソースを差し替えた偽のスキルが、削除されるまでに約26,000のエージェントに到達していた。Plugin4Shell はその同じ失敗が一段下の層で起きたものだ。審査は行われ、ピンは記録され、そして記録された意図と実際に動いたものとの間に隙間があった。

Sources: AIR Security: Plugin4Shell · Help Net Security · The Register · The Hacker News