Plugin4Shellとは？Claude Code・Codex・GitHub Copilot・Gemini CLIのプラグイン供給網リスクを解説

当サイトではアフィリエイト広告を利用しています。

AIコーディングエージェントでは、プラグインやスキルを追加して、できる仕事を増やす使い方が広がっています。

その一方で、追加機能そのものが攻撃経路になる問題も見え始めました。

2026年9月17日にAIR Securityが公開した「Plugin4Shell」は、Claude Code、OpenAI Codex、GitHub Copilot CLI、Gemini CLIのプラグイン取得処理に共通していたSHA pinningの検証不足を突く供給網リスクです。

ポイントは、危険なプラグインを最初から入れる話ではありません。

一度レビューされ、特定のGitコミットへ固定されたプラグインでも、実際に展開されたコードがそのコミットと一致しているかをエージェント側が確認していなかったことが問題でした。

2026年9月29日時点では、Claude CodeとCodexは修正済みです。一方、GitHub Copilot CLIは公開情報から修正版を確認できず、Gemini CLIについてはAIRが「修正予定なし」と報告しています。ただしGemini CLIは一般ユーザー向けと企業向けで現在の扱いが異なるため、単純に「製品全体が終了した」とは言えません。

この記事では、Plugin4Shellが何を破ったのか、どの条件で影響するのか、4製品の現在の状況、今後プラグインを使うときに見るべき点を整理します。

Plugin4ShellはAIモデルではなくプラグイン配布の仕組みを狙う

Plugin4Shellは、ClaudeやGPT、GeminiといったAIモデルそのものの脆弱性ではありません。

対象になったのは、AIコーディングエージェントがマーケットプレイスなどからプラグインを取得し、ローカルへ展開するまでの処理です。

プラグインの供給元をGitリポジトリで管理する場合、レビュー済みのコードを特定のコミットへ固定するためにSHAが使われます。

たとえば、マーケットプレイス側で「このプラグインはこのコミットのコードを使う」と固定しておけば、リポジトリのmainブランチが後から変わっても、固定済みのコードを使い続けられるはずです。

この考え方自体は一般的な供給網対策です。

Plugin4Shellでは、固定したSHAを指定してGitからコードを取得したあと、本当にそのSHAのコードが展開されたかを確認していなかったことが問題になりました。

AIR Securityは、Claude Code、Codex、GitHub Copilot CLI、Gemini CLIで、この確認不足を利用した実証に成功したとしています。

なぜ「SHAで固定」していても別のコードが入ったのか

Gitでは、コミットIDだけでなく、ブランチやタグなどの名前も参照として扱います。

AIR Securityが示したClaude Code、Codex、GitHub Copilot CLIのパターンでは、特定条件下でコミットSHAと同じように見える名前を持つGit参照を、Gitがコミットより優先して解決することで、固定対象とは別のコードが展開されました。

重要なのは、SHAそのものが破られたわけではないことです。

暗号学的なSHA衝突を起こしたのでも、固定済みコミットを書き換えたのでもありません。

「指定した名前」と「実際に展開されたコミット」が同じかを最後に確認しなかったため、Gitの参照解決の挙動を使って別のコードへ誘導できました。

Gemini CLIでは別の参照名を利用する方法が報告されていますが、根本は同じです。

固定値を指定しただけで安心せず、展開後のHEADが本当に固定したコミットと一致するか確認する必要があるという話です。

OpenAIはCodexの修正PRで、Gitが要求されたコミットSHAをブランチ名として解釈する場合があることを明記し、チェックアウト後に実際のHEADを確認する処理を追加しました。

なぜゼロクリックRCEと呼ばれているのか

AIR SecurityはPlugin4Shellを「zero-click RCE」と説明しています。

ただし、すべての利用者が何もしなくても即座に攻撃されるという意味ではありません。

この呼び方の背景には、Claude CodeとCodexではプラグインのバックグラウンド更新が標準で使われる構成があり、すでに導入済みの信頼されたプラグインが後からすり替えられた場合、新しいインストール操作をしなくても更新経路から悪意あるコードが入る可能性があることがあります。

攻撃側には、少なくともプラグインの供給元リポジトリを支配できることが必要です。

考えられる経路は、

  • 最初は正常なプラグインを公開し、後から供給元を悪用する
  • 正規プラグインのリポジトリや管理権限を奪う
  • リポジトリ移転や管理権限の変化を利用する

などです。

つまり、Plugin4Shellは「誰でも遠隔から直接攻撃できる穴」ではなく、プラグイン供給網のどこかが乗っ取られたとき、本来その被害を止めるはずのSHA固定をすり抜けられる問題です。

影響はプラグインの供給元と使い方で変わる

Plugin4Shellの影響は、4製品を使っているだけで一律に発生するわけではありません。

主に次の条件が関係します。

  • マーケットプレイスなどからプラグインを導入している
  • そのプラグインの供給元リポジトリを攻撃者が支配できる
  • 利用中のエージェントが未修正版である
  • 利用するGitホスティングが攻撃に必要な参照名を許可している
  • 自動更新などによって再取得が発生する
  • プラグインがアクセスできるファイル・認証情報・ネットワークの範囲が広い

特に最後の項目が重要です。

プラグインがエージェントと同じ権限で動くなら、プラグインの侵害は、そのままエージェントが触れられるファイル、APIキー、Gitリポジトリ、クラウド環境などへのアクセスにつながります。

AIエージェント本体の権限を狭くする考え方は、Plugin4Shellのような供給網リスクにも有効です。

権限設計については別の記事で詳しく整理しています。

AIエージェントにどこまで権限を与える？ファイル・コマンド・ネット接続の安全な考え方
AIエージェントにどこまで権限を与えるべきかを、読み取り・書き込み・コマンド実行・ネット接続・フルアクセスの5段階で解説。CodexやClaude Codeにも共通するサンドボックス、承認、最小権限の考え方を整理します。
nekopy-kaimono-lab.com
2026.09.02

GitHub上のプラグインは同じ条件では攻撃できない

Claude Code、Codex、GitHub Copilot CLIで使われた「SHAのような名前を持つブランチ」の方法には、Gitホスティング側の制限も関係します。

GitHubは、実際のGitオブジェクトIDと混同する40桁の16進数だけで構成されたブランチ名やタグ名を禁止しています。

そのため、GitHub上のリポジトリでは、AIR Securityが示したSHA形式のブランチ名を使う方式はそのまま成立しません。

The Hacker Newsは2026年9月18日時点で、AnthropicのコミュニティカタログやClaude Code、GitHub Copilotの標準カタログに載っていたプラグインの供給元がGitHubだったことも確認しています。

一方で、Bitbucketや自社Gitサーバーなど、同じ名前を許可する環境では条件が変わります。

また、Gemini CLIで報告された方式はSHA形式のブランチ名とは異なるため、GitHubのこの制限だけで4製品すべての問題を解決できるわけではありません。

このため「マーケットプレイスが安全か」だけではなく、実際のプラグイン供給元がどこかまで確認する必要があります。

4製品の修正状況｜2026年9月29日時点

公開情報を基にすると、状況は次のとおりです。

製品現在確認できる状況確認ポイント
Claude CodeAIR Securityは2.1.179で修正済みと報告2.1.179以上へ更新
OpenAI Codex0.146.0で修正済み。OpenAIの公開PRでHEAD照合を確認できる0.146.0以上へ更新
GitHub Copilot CLIAIR Securityは修正版なしと報告。9月29日時点で公開情報から修正バージョンを確認できず外部Gitホストのプラグイン利用を含め、最新のセキュリティ情報を確認
Gemini CLIAIR Securityは修正予定なしと報告一般向けはAntigravity CLIへ移行。企業・APIキー利用はGoogleの現行案内を確認

Claude Codeは2.1.179以降へ更新

AIR Securityによると、Anthropicは2026年6月17日にClaude Code 2.1.179で修正を確認しています。

Claude Codeの公開CHANGELOGには、2.1.179の項目として複数の修正が載っていますが、Plugin4Shellという名前やSHA検証の詳細は明記されていません。

そのため、Plugin4Shell修正バージョンの根拠はAIR Securityの開示情報になります。

Codexは0.146.0以降で修正済み

Codexは公開情報で修正内容まで確認できます。

OpenAIのPR「Verify Git plugin SHA checkouts」では、固定したSHAをチェックアウトしたあと、実際のHEADを取得し、要求したSHAと一致しなければエラーにする処理へ変更されています。

この修正はCodex 0.146.0に含まれました。

現在のCodexはさらに新しいバージョンが公開されているため、通常どおり最新へ更新していれば修正を含む世代になります。

GitHub Copilot CLIは修正バージョンを確認できない

AIR Securityは公開時点で、GitHub Copilotにはクライアント側の修正が提供されていないと報告しています。

GitHub側には40桁のGitオブジェクトID風ブランチ名を拒否する制限があるため、GitHubホストのリポジトリでは主要な攻撃パターンを抑えられます。

一方で、GitHub Copilot CLIは外部マーケットプレイスやプラグイン供給元も扱えるため、AIR Securityはホスティング側の制限だけでは十分ではないと指摘しています。

9月29日時点で公開されているCopilot CLIのCHANGELOGやリリース情報から、Plugin4Shell対応を明示した修正バージョンは確認できませんでした。

Gemini CLIは「一般向け終了」と「企業向け継続」を分けて見る

AIR Securityは、GoogleがGemini CLIを修正せず、Antigravityへの移行を案内したと報告しています。

一方、Googleの公式発表では、2026年6月18日に無料ユーザーとGoogle AI Pro / UltraのGemini CLI利用を終了したものの、Gemini Code Assist Standard / Enterpriseや有料APIキー経由の利用は継続すると説明しています。

さらにGemini CLIのGitHubでは2026年9月23日に安定版0.61.0が公開され、別のセキュリティ強化も続いています。

そのため、2026年9月時点のGemini CLIは「すべての利用形態で完全終了した製品」ではありません。

ただし、AIR Securityが報告したPlugin4Shell向けの修正については、公開情報から確認できませんでした。

Plugin4ShellはPrompt InjectionやMCPの脆弱性とは別物

AIエージェントのセキュリティでは、Prompt InjectionやMCPのリスクもよく話題になります。

Plugin4Shellはそれらとは攻撃する場所が違います。

リスク主に狙う場所Plugin4Shellとの違い
Prompt InjectionAIが読むWebページ、メール、文書などモデルへの指示を悪用する
悪意あるMCP・外部ツールエージェントが接続する外部機能接続先やツール自体を信用できるかが問題
Plugin4Shellプラグインの取得・展開処理レビュー済みの固定コードと実際のコードが一致しない

Plugin4Shellでは、モデルをだます必要がありません。

AIが悪意ある指示を解釈した結果でもなく、モデルが判断を誤った結果でもありません。

エージェントが実行する追加コードをどこから、どの状態で受け取るかという、従来のソフトウェア供給網に近い問題です。

AIエージェントでは、その追加コードがファイル操作、シェル、クラウド認証情報などへ届きやすいため、通常のエディタ拡張機能以上に影響が大きくなりやすい点が特徴です。

今後プラグインを使うときに確認したいこと

Plugin4Shellから得られる実務上のポイントは、「プラグインを使わない」ことではありません。

確認する場所を増やすことです。

1. エージェント本体を最新にする

Claude CodeやCodexのように修正版がある製品では、まず本体を更新します。

マーケットプレイス側だけを更新しても、Plugin4Shellの根本原因だったクライアント側の検証不足は直りません。

2. プラグインの供給元を確認する

プラグイン名やマーケットプレイス名だけでなく、実際のソースリポジトリを確認します。

見るポイントは、

  • GitHub、Bitbucket、自社Gitなど、どこから取得しているか
  • 管理者やOrganizationが変わっていないか
  • リポジトリが移転していないか
  • 自動更新が有効か

です。

3. 「固定されている」だけで安全と判断しない

SHA固定は重要ですが、Plugin4Shellは固定した値と実際に展開されたコードの一致確認が必要であることを示しました。

開発基盤や社内マーケットプレイスを作る側では、取得後のコミットIDや成果物のハッシュまで検証する設計が重要になります。

4. プラグインへ渡す権限を必要な範囲へ絞る

供給網対策を完全にしても、別の脆弱性が出る可能性は残ります。

そのため、

  • 開発フォルダだけを書き込み可能にする
  • 秘密情報を作業環境から分離する
  • 本番認証情報を常時置かない
  • ネットワーク接続先を絞る
  • 重要操作には承認を残す

といった権限設計を組み合わせます。

プラグインが侵害されても、届く範囲が狭ければ被害も限定できます。

現時点で実被害が広がった証拠は確認されていない

Plugin4Shellでは、AIR Securityが4製品に対する実証を行い、The Hacker Newsも基礎となるGitの挙動を再現しています。

一方、2026年9月29日時点で、Plugin4Shellを使った大規模な実被害や侵害事例が発生したことを示す信頼できる公開情報は確認できませんでした。

そのため、現状は攻撃経路が実証された脆弱性と、現実の被害が確認されたインシデントを分けて見る必要があります。

まとめ

Plugin4Shellの本質は、「レビュー済み」「SHAで固定済み」という情報だけを見て、実際に展開されたコードまで確認していなかったことです。

AIコーディングエージェントでは、プラグインやスキルがエージェント本体と同じ開発環境で動くため、追加機能の供給網も重要なセキュリティ境界になります。

2026年9月29日時点では、

  • Claude Codeは2.1.179以降で修正済み
  • Codexは0.146.0以降で修正済み
  • GitHub Copilot CLIは公開情報からPlugin4Shell対応版を確認できない
  • Gemini CLIは一般向けがAntigravityへ移行済みだが、企業・APIキー利用は継続しており、Plugin4Shell修正は確認できない
  • GitHubホストのリポジトリでは、SHA形式ブランチを使う主要パターンはGitHub側の制限で成立しない
  • 実被害が広がったことを示す公開情報は現時点で確認されていない

という状況です。

プラグインを使うときは、マーケットプレイスの審査だけでなく、エージェント本体の修正版、供給元リポジトリ、更新経路、実際に展開されたコード、プラグインへ渡す権限まで一続きで見る必要があります。

公式情報・参照先

タイトルとURLをコピーしました