Plugin4Shell：4つのAIコーディングエージェントが、一度も確認しなかったピンを信頼した

2026年9月17日、企業向けAIエージェントのセキュリティツールを開発するスタートアップのAIR Securityは、Plugin4Shellについて説明する研究を公開した。これは、AnthropicのClaude Code、OpenAIのCodex、GitHub Copilot、GoogleのGemini CLIという4つのAIコーディングエージェントに存在するゼロクリックのリモートコード実行脆弱性である。このバグはどのモデルにも存在しない。原因は、各エージェントがプラグインをインストールする際に行うgitチェックアウトと、4つのいずれもが、受け取ったコードがピン留めしたコードと同一であることを検証していなかった点にある。研究公開時点で、4つのうち2つにはパッチが存在した。残る2つには存在しなかった。このインシデントはOrca AI Incident Archiveの1件であり、悪用は報告されていない高深刻度のサプライチェーン脆弱性として記録されている。

エージェントが実際に何を間違えたのか

影響を受ける各エージェントはマーケットプレイスからプラグインをインストールし、各マーケットプレイスはプラグインがレビューされると、そのプラグインを特定の git コミット（40文字の SHA）に固定します。この固定がセキュリティモデルの全体です。レビュアーが1つの不変バージョンを承認し、エージェントは、その後ろのリポジトリが後で変更されても、そのバージョンを実行し続けることになっています。AIR はこの欠陥をプラグインの SHA 固定バイパスと表現しています。エージェントはマーケットプレイスが固定した正確なコミットをチェックアウトしますが、最終的に得られる作業ツリーがそのコミットであることを決して検証しません。研究者の言葉によれば、エージェントは「マーケットプレイスが固定した正確なコミットをチェックアウトするが、そこに到達したことを決して検証しない。そのため、プラグインのリポジトリを制御する攻撃者は、固定が依然として守られているように見せかけながら、チェックアウトを悪意あるコードに解決させることができる」のです。

Gitがその隙間を埋める。名前が有効なブランチでもありコミットオブジェクトでもある場合、gitはブランチを優先し、曖昧性の警告を表示するだけだ。プラグインのリポジトリを制御する攻撃者は、名前が固定された40桁の16進SHAそのものであるブランチを作成し、それを悪意のあるコードに向け、リポジトリのデフォルトブランチにする。すると通常のクローンでそのブランチがSHAの形をした名前のままローカルに持ち込まれ、その後のチェックアウトはそれに解決される。固定されたコミット自体は未変更のままでよいため、レビュー済みバージョンに何かおかしいところは見えない。AIRによれば、2つの条件が成立する必要がある。SHA名のブランチがデフォルトブランチであること（デフォルトでないブランチはリモート追跡refとしてのみ取得され、チェックアウトは実際のコミットにフォールバックするため）、およびgitホストが40桁の16進ブランチ名を受け入れることだ。GitHubはそのような名前を即座に拒否する。Bitbucketとセルフホストのgitサーバーは拒否しない。

Gemini CLIは別の経路で失敗した。固定されたコミットを取得してリポジトリのFETCH_HEADファイルに記録し、その後FETCH_HEADのチェックアウトを実行したが、このチェックアウトはそのファイルを読む必要がない。デフォルトブランチ自体がFETCH_HEADという名前であるリポジトリでは、チェックアウトが攻撃者制御のコンテンツへリダイレクトされ、取得されたコミットが黙って破棄される。Cybersecurity Newsによるこの仕組みの説明はAIRの説明と一致しており、2つの変種の区別も含まれている。

なぜ誰も何もクリックする必要がなかったのか

同じチェックアウトは、Claude Code と Codex ではデフォルトであるバックグラウンドのプラグイン自動更新中に再び実行される。これが、この攻撃を単に静かなものではなくゼロクリックにする理由だ。マーケットプレイスが固定された SHA を日常的な新バージョンへ引き上げると、すでにそのプラグインをインストール済みのすべてのエージェントが、プロンプトもユーザー操作もなしにチェックアウトを再実行する。AIR の指摘は、被害者が何かを不注意にインストールする必要はないということだ。必要なのは、信頼するマーケットプレイスから、設計がまさに意図するとおりにレビューされ固定された 1 つのプラグインをインストールしておくことだけである。

その位置に到達する方法は2つあり、どちらもマーケットプレイスを支配する必要はない。1つ目では、攻撃者がレビューを通過する真に無害なプラグインを公開し、インストール基盤を築き、通常のアップデートを配信し、その後になって初めて悪意ある名前のブランチを作成する。2つ目では、攻撃者が、他の誰かが作成しマーケットプレイスがすでに信頼しているプラグインの背後にあるリポジトリを乗っ取り、それをインストールしている全員に悪意あるバージョンを配信する。

これら2つの経路に関する数字は、Plugin4ShellではなくAIRの以前の取り組みに由来する。同社がThe Story of Skillsと呼ぶキャンペーンでは、自社が開発したプラグインが配布停止される前に26,000以上のエージェントに広がったとしている。SkillJackingでは、すでに実際に使用されていた925個のスキルが元のメンテナーから乗っ取られ、134,000体のエージェントに到達したと報告した。Plugin4Shellの投稿の見出しでAIRは「数百万のエージェントが影響を受けた」と主張しているが、この調査は影響を受けたインストール件数を示しておらず、第三者もそれを公表していない。

タイムライン、そして修正が適用された箇所

AIRによると、2026年5月に4つのエージェントすべてに対する動作する実証コード（PoC）エクスプロイトを用いてこの欠陥を発見し、翌月に協調的脆弱性開示の下で各ベンダーに開示した。Anthropicは6月17日にClaude Code 2.1.179での修正を確認した。Googleは8月4日にAIRへ、Gemini CLIが廃止されるため修正は提供されないと伝えた。Codex 0.146.0は8月12日に修正済みであることが確認された。MicrosoftはGitHub Copilot向けの修正をまだ提供していない。

パッチバージョンは、その欠陥が実際に存在したことを、それを修正した2つの製品において公に裏付ける唯一のものだ。Anthropicが公開した2.1.179の変更履歴エントリには、接続切断の処理、WSL2のスクロール、サンドボックスのglobおよびインターフェースの修正が記載されており、ピン留め、プラグイン検証、またはいかなる種類のセキュリティ修正にも言及していない。The Next Webの報道によれば、The Hacker Newsも同じ点を指摘した。この調査の公開時点では、CVE識別子はまだ割り当てられておらず、Cloud Security Allianceによるこの欠陥に関する調査ノートも、ベンダーへの通知から3か月後にも識別子が存在しなかったことを繰り返し述べている。

4つのベンダー、3つの異なる回答

Googleはパッチを当てることを断るにとどまらず、さらに踏み込みました。Gemini CLIを非推奨にしたのです。つまり、既存のインストールは、人々がそれを使い続ける限り脆弱なままさらされ続けます。同社の助言は、より新しいエージェント型開発環境であるAntigravityへ移行することです。AIRによれば、Antigravityには回避対象となるマーケットプレイスプラグインのSHAピニングがないため、この攻撃は届きません。

GitHubの立場はまた異なる。GitHubの広報担当者はThe Registerに対し、プラットフォームではコミットSHAに似たブランチ名やタグ名をユーザーが作成することは許可されていないと述べ、「この緩和策により、報告された脆弱性はGitHub上では悪用できないことが保証される」と語った。AIRは、その緩和策の存在ではなく範囲について異議を唱えている。研究者らはThe Registerに対し、マーケットプレイスはBitbucketなどの他のプラットフォームでホストできると述べ、GitHub Copilotはそうしたプラットフォームのマーケットプレイスを引き続きサポートしているため、Copilotユーザーにとってブランチ名を使った変種は依然として到達可能だと指摘した。AIRはまた、Anthropic自身のドキュメントがBitbucketとセルフホスト型gitを有効なマーケットプレイスのバックエンドとして挙げているとも述べている。Anthropicの現在のマーケットプレイスに関するドキュメントでは、GitHubだけでなくgitリポジトリのURLからマーケットプレイスを追加する方法が説明されている。MicrosoftはThe Registerのコメント要請に応じなかった。AIRは、6月にこの問題を報告して以来Microsoftから回答を受け取っていないと述べ、同社が処理している開示の量を理由に挙げた。

これは、バグが存在するかどうかではなく、影響範囲の広さに関する意見の相違です。GitHubの緩和策はホストレベルの制限であり、AIRの指摘は、ピンがクライアント側で解決されるため、チェックはエージェント内部で行わなければならないというものです。

何が確立されており、何が確立されていないのか

• 立証済み：その仕組み。AIRの解説記事には、正確なgitコマンド、オブジェクトよりrefを優先する解決ルール、ブランチトリックが必要とする2つの条件、そしてGemini CLI向けの別個のFETCH_HEAD変種が示されている。The Register、Help Net Security、Cybersecurity News、InfoWorld、The Next Webはいずれも同じ内容を報じている。

• 確定： パッチ適用済みの2バージョン。AIRの開示タイムラインによると、Anthropicは2026年6月17日にClaude Code 2.1.179を確認し、OpenAIのCodex 0.146.0は2026年8月12日に修正済みであることが検証された。

• 判明していること：開示時点で2製品には修正プログラムが存在しませんでした。GoogleはGemini CLIを修正せず、廃止する方針です。MicrosoftはCopilotの修正プログラムをまだ提供していません。

• 未確立：独立した再現。公表されているすべての記述はAIR自身のブログ投稿に遡り、Cloud Security Allianceのリサーチノートは、第三者の技術的検証やエクスプロイトの独立した再現について明示的に述べていない。このため、アーカイブはこの記録の信頼度をBと格付けしている。

• 未確認：実際に何件の設置が露出していたか。「数百万」は見出しにおけるAIRの表現であり、測定された数値ではない。

• 未確定：影響を受けたエージェントを更新すると、すでに差し替えられたプラグインが削除されるのか、それとも次の差し替えが防止されるだけなのか。これを明らかにしている公開資料はない。

• 未確認:実世界での使用は一切ありません。記録内のどの情報源も、悪用、探索、攻撃者のインフラについて報告しておらず、アーカイブは実際の被害を虚偽として記録しています。これは報告が存在しないということであり、何も起きなかったという証拠ではありません。

第三者によるチェックが1件あることで、実務上の全体像は絞り込まれる。The Next WebはThe Hacker Newsによるチェックを要約し、AnthropicのコミュニティカタログならびにデフォルトのClaude CodeおよびCopilotのカタログ内のプラグインがGitHubリポジトリを指しており、自動更新は主にそれら組み込みマーケットプレイスでデフォルト有効になっていると報じている。GitHubはSHA形式のブランチ名を拒否するため、デフォルトのカタログを使い続けるユーザーにとって、ブランチ名を使うバリアントには到達しにくい。その推論は、ホストがブランチをどう命名するかに依存しないGemini CLIのFETCH_HEADバリアントをカバーしていない。

修正がどのような形であるべきか

AIR が推奨する修正は、単一のアサーションです。チェックアウト後に、作業ツリーに実際に存在するコミットを解決し、固定された SHA と一致しなければ中止します。研究者たちは、要求された ref ではなく、解決済みの HEAD を確認する必要があると強調しています。なぜなら、その区別こそが Gemini CLI の変種がすり抜けるポイントだからです。また、この処理はエージェント内部で実行する必要があります。ピンはクライアント側で解決されるため、どのマーケットプレイスも、自らが謳う保証を強制できないからです。

これらのエージェントを運用するチーム向けの実践的なアドバイス。AIR、Cybersecurity News、およびInfoWorldのアナリスト解説から引用：

• Claude Code を 2.1.179 以降に、Codex を 0.146.0 以降にアップデートしてください。パッチが存在する場合、アップデートすることが唯一の完全な緩和策です。

• パッチが存在しないエージェントでは、プラグインの自動更新を無効にしてください。これにより、脆弱性はゼロクリックから手動再インストールへと変わります。これは修正ではなく、露出の削減です。

• Google が来ないと明言したパッチを待つのではなく、Gemini CLI からの移行を進めましょう。

• プラグインのインベントリを監査し、可能な限りマーケットプレイスのソースを制限する。AIRは、SHA形式の名前を拒否するホストのみを許可することで、マーケットプレイスがブランチ名バリアントを弱められ、事実上GitHub専用になるが、それではエージェントが公式にサポートしているホストを禁止することになり、Geminiバリアントには何の効果もない、と指摘している。

• ワークステーションを露出境界として扱う。プラグインはエージェントの権限を継承するため、悪用に成功されると、開発者自身の権限でソースコード、SSHキー、クラウド認証情報、CI/CDトークン、社内リポジトリにまで到達される。Pareekh Consultingの主任アナリスト、Pareekh Jain氏はInfoWorldに対し、セキュリティチームはEDR、git、CI/CD、クラウドIAM、認証ログを確認し、異常なプロセス、想定外のプラグインファイル、変更されたリポジトリ、不審なgitアクティビティを探すべきだと述べた。さらに同氏は、こうした対策はリスクを低減するものの、同氏がベンダーのコードに起因すると考える根本的な欠陥を修正するものではないと付け加えた。「企業はプラグインの利用に統制を設けることはできます」と同氏はInfoWorldに語った。「しかし、コーディングエージェントがチェックアウトしたコードを検証する方法の欠陥を修正することはできません」。

なぜピン留めのバグが重要だったのか

SHAピニングは、AIRがすでに実証していたまさにその種の乗っ取りに対する業界の答えだった。公開リポジトリが侵害されても、エージェントは攻撃者がプッシュしたものを取得するのではなく、監査済みのハッシュを使い続ける。Plugin4Shellはハッシュを破らない。それが示しているのは、エージェントがピンを、単にハッシュのように見えるブランチ名に解決してしまい、その結果を照合しなかったということだ。その前提の下流にあるすべて——レビュープロセス、社内の許可リスト、開発者がピン留めされたバージョンに寄せる信頼——が、この失敗を引き継ぐ。

記録が裏付けていないのは、何かが持ち去られたという主張だ。これは見つかった脆弱性であり、4件のうち2件では修正されている。その記録の中に侵入を報告している情報源はなく、パッチを出していない製品は依然として待たされている。未解決の問いは最も納得のいかないものだ。未パッチのエージェント上でプラグインを実行した人にとって、実行されたコードが自分が承認したコードだったかどうかを判断する公表された方法はない。