「承認済み」のはずのコードが、いつの間にか差し替わる
9月17日、AIセキュリティ企業AIRの研究者3名(Or Nevo氏、Dor Granat氏、Niv Hoffman氏)が「Plugin4Shell」と名付けた脆弱性を公表した。Claude Code、OpenAI Codex、GitHub Copilot、Gemini CLIという、いま最も広く使われている4つのAIコーディングエージェントすべてに存在する、ゼロクリックのリモートコード実行(RCE)脆弱性だ。ユーザーが何かをクリックしたり承認したりする必要は一切なく、プラグインのリポジトリを制御できる攻撃者が、すでに承認済みのコードを別のものにこっそり差し替えられる。AIエージェントのサプライチェーンを狙った、この種としては初めての脆弱性だとAIRは説明している。
SHA固定という約束を、4社が揃って見落としていた
技術的な核心はシンプルだ。多くのプラグインマーケットプレイスは、レビュー済みのプラグインを特定のGitコミットハッシュ(SHA)に固定する仕組みを持っている。「承認されたものだけが動く」という前提を担保するための、地味だが重要な安全装置だ。ところがAIRの調査によれば、Claude Code、Codex、Copilot、Gemini CLIのいずれも、インストール後に実際にチェックアウトされたコミットが、マーケットプレイスに記録された固定SHAと本当に一致しているかを検証していなかった。攻撃者は、そのSHA文字列そのものをブランチ名として使うことで、この一行だけの比較チェックをすり抜けられる。4社がそれぞれ独立に同じ一行のチェックを見落としていたという事実は、これが特定ベンダーの実装ミスではなく、業界全体がAIエージェントのプラグイン機構をどう設計してきたか、という共通の構造的な問題であることを物語っている。
プラグインは「開発者本人と同じ権限」を持っている
見過ごせないのが、この脆弱性がなぜ深刻なのかという点だ。AIエージェント向けのプラグインやスキル、拡張機能は、多くの場合それを動かしている開発者本人と同じ権限を継承する。ローカルのソースコード、クラウドの認証情報、SSHキー、社内リポジトリ、本番システム、機密情報まで、エージェントがアクセスできる範囲のすべてが攻撃対象になりうる。AIRは今回の脆弱性を「エージェント本人が何も操作していないのに、攻撃者が開発者と同じ視点でシステムに侵入できる」という意味で、AIエージェントエコシステム初のサプライチェーン脆弱性だと位置づけている。
対応は4社でまちまち
今回特に興味深いのが、開示後の各社の対応速度と姿勢の違いだ。AnthropicはClaude Code 2.1.179で、OpenAIはCodex 0.146.0で、それぞれ公開の数か月前(AIRが発見したのは5月、各社への通知は6月)にはすでに修正版を配布していた。一方、MicrosoftはGitHub Copilotについて、9月21日時点でも修正パッチを出していない。GitHub側は「SHAのような文字列をブランチ名・タグ名として使うことをプラットフォーム側でブロックしている」と説明しているが、AIRはBitbucketや自前ホストのGitサーバー上のマーケットプレイスであれば、その防御を迂回できる可能性があると指摘している。GoogleはGemini CLIのコンシューマー版そのものを廃止する方針を示し、修正を行わない代わりに後継の「Antigravity」への移行を促している。同じ脆弱性に対して、迅速に修正する会社、防御をプラットフォーム側に部分的に委ねる会社、製品自体を畳む会社と、対応の分かれ方そのものが各社のセキュリティ運用体制の違いを映し出している。
実際の悪用は確認されていない
一つ安心材料を挙げるとすれば、AIRは今回の脆弱性について、実際の悪用が確認された証拠は見つかっていないとしている。CVE番号もまだ割り当てられていない。AIRが概念実証コードを作成したのは5月で、各社への通知から公開まで約3か月の猶予期間を置いた、責任ある開示のプロセスを踏んでいる。
エンジニアとして見ておきたいこと
Claude CodeとCodexを使っているなら、まずバージョンをそれぞれ2.1.179、0.146.0以降に更新することが最優先だ。GitHub Copilotを使っている場合は、GitHubホストのマーケットプレイス以外からのプラグイン導入を避け、サードパーティプラグインの自動更新を可能な限り無効化しておくのが当面の現実的な防御策になる。Gemini CLIについては、Googleが明言している通り修正の予定がないため、Antigravityへの移行を検討する必要がある。より本質的な教訓は、AIエージェントのプラグイン機構において「レビュー済みのハッシュに固定する」という仕組みは、実際にそのハッシュが正しく検証されているかを別途確認しない限り、名ばかりの安全装置になりかねないという点だ。ベンダー側の恒久対策としては、インストール後に実際のHEADの値とマーケットプレイス側の固定SHAを照合する、という一行の検証を確実に組み込むことが求められる。