あなたのClaude Codeは大丈夫か — 4大AIコーディングエージェントを襲ったPlugin4Shell

数ヶ月前にインストールしたプラグインのことを、あなたは覚えているだろうか。

導入時にちゃんとコードを確認し、特定のバージョンに固定（ピン留め）した。だから安全なはずだ——多くのAIコーディングエージェント利用者が、無意識にそう信じている。私もその一人だった。

その前提が、いま静かに崩れている。Plugin4Shell と名付けられた脆弱性が、Claude Code・OpenAI Codex・GitHub Copilot・Google Gemini CLI という主要4ツールを同時に直撃したと報じられているからだ。しかも、利用者が何もクリックしなくても攻撃が成立する「ゼロクリック」型。あなたのエージェントが、あなたの承認なしに他人の書いたコードを実行してしまう、という類のものだ。

まず落ち着いて、自分の環境が該当するかを確認したい。この記事はそのための実用ガイドでもある。

Plugin4Shellとは何なのか

発見したのはイスラエルのセキュリティ企業 AIR Security。同社の公開情報によると、これは4つのAIコーディングエージェントに共通するプラグイン機構の欠陥で、AIエージェント・エコシステム初のサプライチェーン脆弱性だと位置づけている。かつてのLog4Shellになぞらえた命名からも、研究者たちの危機感が伝わってくる。

サプライチェーン脆弱性というのは、ざっくり言えば「あなたが直接書いたコードではなく、あなたが取り込んだ部品（ここではプラグイン）を経由して攻撃される」タイプの問題だ。npmの汚染パッケージ事件などが記憶に新しいが、それがAIエージェントの世界にも来た、ということになる。

怖いのは、これがゼロクリックである点だ。Claude CodeやCodexは、インストール済みプラグインをバックグラウンドで自動更新する仕様だと報じられている。つまり利用者が「更新する」ボタンを押さなくても、裏で勝手に最新版を取りに行く。もし攻撃者が悪意あるコードを差し込めば、承認も再インストールも不要で、それが実行されてしまう。RCE(リモートコード実行)が成立すれば、開発マシンの権限を丸ごと奪われかねない。

「SHAピンニング」という約束が破られた

ここが今回の肝なので、専門用語をかみ砕いておきたい。

プラグインを特定バージョンに固定するとき、多くのツールはSHA(コミットハッシュ) を使う。SHAとは、Gitのコミット一つひとつに割り振られる40桁の16進数の指紋のようなものだ。「このプラグインは、この指紋を持つコードだけを使う」と宣言しておけば、後からこっそり中身をすり替えられても検知できる——はずだった。これが「SHAピンニング」と呼ばれる、安全の約束事だ。

Plugin4Shellは、その約束の抜け穴を突く。報じられている手口はこうだ。攻撃者がプラグインのリポジトリを支配している場合、固定されているSHAとまったく同じ40桁の文字列を「ブランチ名」として作成する。Gitには、同じ名前が「ブランチ名」と「コミットID」の両方に該当するとき、ブランチ名を優先して解決するという挙動がある。結果として、エージェントは「固定したコミットを取ってきたつもり」で、実際には攻撃者のブランチ(=別のコード)をチェックアウトしてしまう。

指紋を照合しているつもりが、指紋の名を騙った別人を通していた、というわけだ。ピン留めは「検証」ではなかった、という点にこの脆弱性の本質がある。

ひとつ救いがあるとすれば、この手口には前提条件があることだ。GitHubは40桁16進のブランチ名を拒否するため、GitHub上でホストされたプラグインでは同じ手が使いにくいと報じられている。一方でBitbucketや自前構築のGitサーバーは、そうした名前を許容する。つまりプラグインがどこにホストされているかが、リスクの分かれ目になる。自分が入れているプラグインの配布元を一度棚卸しする価値はある。

影響範囲と各社の対応状況

各社の公開情報およびAIRの開示タイムラインとして報じられている内容を整理すると、対応にはっきり差が出ている。

ツール	対応状況（報道ベース）
Claude Code (Anthropic)	修正済み。2.1.179 でパッチとされる
OpenAI Codex	修正済み。0.146.0 でパッチとされる
GitHub Copilot (Microsoft)	明確なパッチは未確認。GitHubは緩和策があるとする一方、研究者はその範囲に疑問を呈していると報じられている
Google Gemini CLI	Googleは製品を終息させ、修正しない方針とされる。後継のAntigravityへの移行を推奨

数字はいずれもAIRおよび各報道が伝えるもので、本稿執筆時点で筆者が一次アドバイザリの原文まで突き合わせて確認できたわけではない。導入バージョンによって差異がありうるため、最終的には各自の環境で確認してほしい。なお、公開時点でCVE番号は付与されていないと報じられている。

タイムラインも押さえておくと、AIRが2026年5月に発見、6月に各ベンダーへ通知し、9月17日に一般公開したという流れだ。修正版は公開の数ヶ月前に出ていた計算になる。

あなたの環境をどう守るか

ここからが実用パート。難しいことはない。

1. まずバージョンを確認する。 Claude Codeなら claude --version を叩き、2.1.179 以上かを見る。下回っていたら即アップデートだ。Codexも同様にバージョンを確認し、0.146.0 以上に上げておきたい。バックグラウンド更新に任せきりにせず、自分の目で数字を見るのがこの脆弱性への一番確実な対処になる。

2. プラグインの配布元を棚卸しする。 前述のとおり、リスクはホスト先に依存する。GitHub外(Bitbucketや自前サーバー)から入れたプラグインがあれば、信頼できる発行元かを改めて見直す。使っていないプラグインは、この機会に外してしまうのが安全だ。

3. 自動更新の挙動を把握する。 「気づかないうちに更新される」のがゼロクリックの怖さの正体だ。自分のエージェントがプラグインをどう更新しているのかを一度確認し、可能なら手動承認に寄せておくと安心感が違う。

4. Gemini CLI利用者は移行を検討する。 修正されない方針とされる以上、使い続けるなら配布元の厳選が前提になる。Googleが案内するAntigravityへの移行も選択肢に入れておきたい。

筆者の正直な評価

正直に言うと、パッチ済みのバージョン番号を確認した瞬間、少しほっとした。同時に、ぞっともした。

技術的な派手さでいえば、40桁のブランチ名でSHAを騙るという手口は、Gitの仕様を知っていれば「言われてみれば」の類だ。だが、それを4つの主要エージェントが揃って見落としていたという事実のほうが、はるかに重い。SHAピンニングを「検証」だと思い込み、実際にチェックアウトされた中身を照合していなかった——この思い込みの共有こそが、今回いちばん怖い部分だと思う。

AIコーディングエージェントは、いまや外部プラグインやMCPサーバーを次々と取り込む「拡張前提」の設計になっている。便利さと引き換えに、取り込む部品ひとつひとつが攻撃面になる。Plugin4Shellは、その構造的なリスクが現実の脆弱性として初めて表面化した事例だと見ていい。今後、似た角度の指摘は続くだろう。

とはいえ、過度に怖がる必要はない。AnthropicとOpenAIは通知から数ヶ月で修正を出しており、対応の速さ自体は評価できる。利用者側がやるべきことも、バージョンを上げて配布元を選ぶという、地味だが確実な基本に尽きる。「便利なプラグインを、中身を読まずに信頼していないか」——この問いを一度自分に向けておくだけで、次に来る同種の攻撃への耐性はだいぶ変わるはずだ。