研究者たちは、AIコーディングエージェントがプラグインを取得・検証する仕組みを悪用することで、信頼できる承認済みバージョンを使用するようエージェントに指示していた場合でも、悪意あるコードを実行できることを突き止めました。
OpenAIのCodex、AnthropicのClaude Code、GoogleのGemini CLI、そしてMicrosoft傘下のGitHub Copilotといった主要なAIコーディングエージェントに、ゼロクリック攻撃を可能にする脆弱性が存在していたことが分かりました。この脆弱性を悪用すれば、オンラインマーケットプレイスで配布されている信頼済みプラグインを悪意あるものにすり替えることで、開発者の操作を一切介さずに悪意あるコードを実行でき、攻撃者が企業の開発環境に侵入する足がかりを得る可能性がありました。
サイバーセキュリティ企業AIRの研究者たちは、この脆弱性を発見し「Plugin4Shell」と名付けて各ベンダーに報告しており、木曜日に公開したブログ記事によれば、対象ベンダーの大半はすでにパッチをリリースしているとのことです。
研究者たちは、これは「マーケットプレイス側では修正できない欠陥であり、利用者自身がエージェントを更新する必要がある」と記しています。
Claude Code、Codex、GitHub Copilotはどのように悪用されたか
企業は通常、プラグインを利用してAIコーディングエージェントの機能を拡張し、コードの生成や修正にとどまらないタスクをこなせるよう、追加のツール、コマンド、外部サービスへのアクセスをエージェントに与えています。
開発者がプラグインをインストールすると、エージェントは通常Gitリポジトリからそのコードをダウンロードし、Gitコミットを使って、開発者によるレビューと承認を経た正規のコードを実行しているかどうかを判定します。
この確認作業は、各Gitコミットに割り当てられる一意の暗号学的識別子であるセキュアハッシュアルゴリズム（SHA）を用いて行われます。開発者は、レビュー済みコミットのSHAをエージェントに与えることで、そのプラグインの特定のバージョンを実行するよう指示できます。
しかし研究者たちによると、Claude Code、Codex、GitHub Copilotは、信頼済みのプラグインコードの代わりに悪意あるコードを実行するよう騙される可能性がありました。これらのエージェントは、プラグインのコードをチェックアウトする際にSHAをそのままGitに渡す一方で、Gitが実際にそのSHAに対応するコミットをチェックアウトしたかどうかを事後に検証していなかったためです。
つまり、プラグインのリポジトリを掌握している攻撃者――当初は無害なプラグインを公開しておいて後から悪意あるものに変える手口、あるいは既存の信頼済みプラグインのリポジトリを乗っ取る手口のいずれでも構いません――は、悪意あるコードを含む新しいバージョンのリポジトリを作成し、正規コミットのSHAを名前として使うことで、この抜け穴を突くことができると研究者たちは説明しています。
その結果、エージェントがGitに対してそのSHAのチェックアウトを要求すると、Gitは攻撃者が用意したバージョンをそのSHAとして解決してしまい、レビュー済みコミットを使うよう指示されていたにもかかわらず、エージェントは悪意あるコードを実行してしまうのだと研究者たちは述べています。
Plugin4ShellはどのようにGemini CLIを侵害したか
Gemini CLIでは攻撃の仕組みが少し異なりますが、エージェントがGitによるチェックアウトを検証していないという根本的な問題は同じです。
Gemini CLIはまずSHAを使って、取得すべき正規バージョンのプラグインをGitに伝えます。取得した後、Gemini CLIは「FETCH_HEAD」という名前を使ってそのコードをチェックアウトするようGitに指示します。
リポジトリを掌握している攻撃者は、悪意あるバージョンのプラグインを作成し、それに同じ「FETCH_HEAD」という名前を付けることでこれを悪用できます。これにより、Gemini CLIがコードを要求した際にGitが返却しうる、もう一つの「バージョン」が事実上作り出されてしまうのです。
この脆弱性は5月に初めて発見され、6月にベンダー各社へ開示されましたが、その後、影響を受けたコーディングエージェントの一部ではすでに対処が行われています。研究者たちによれば、AnthropicはClaude Codeバージョン2.1.179で、OpenAIはCodexバージョン0.146.0で、それぞれこの問題を修正しています。GoogleはGemini CLIを非推奨化したため修正パッチは提供しないとし、代わりにAntigravityへの移行を利用者に勧めています。
研究者たちによると、GitHubはCopilotに対する修正をまだリリースしていません。
GitHubの広報担当者はThe Registerに対し、コミットSHAに酷似したバージョン名やタグ名の作成にはすでに制限を課しており、GitHub上やGitHubマーケットプレイスのプラグインについては報告された脆弱性を悪用できないようになっていると説明しました。しかしAIRの研究者たちは同メディアに対し、プラグインのマーケットプレイスはBitbucketなど他のプラットフォーム上にもホストされ得るため、GitHubの命名制限だけではPlugin4Shell攻撃を防ぐには不十分な可能性があると指摘しています。
Plugin4Shellが企業システムへのリスクを拡大させる恐れ
Pareekh Consultingのプリンシパルアナリスト、Pareekh Jain氏によれば、この抜け穴に加えて、影響を受けるコーディングエージェントを運用している企業の多くがまだパッチ適用やアップデートを済ませていない可能性が高いことも相まって、開発環境が侵害されたプラグインを通じた攻撃にさらされかねないといいます。
同氏は「サードパーティ製プラグインを組み込んだAIコーディングエージェントを使用している企業は、特にそれらのエージェントがソースコード、認証情報、クラウドシステム、あるいはCI/CDツールにアクセスできる場合に、最もリスクが高くなる可能性があります。これらのプラグインの多くは、開発者や従業員本人と同じ権限で動作するためです」と述べています。
Jain氏はさらに、これらの悪意あるプラグインが、攻撃者によるソースコードへのアクセス、APIキーやクラウド認証情報の窃取、リポジトリの改ざん、さらにはCI/CDやその他の企業システムへの侵入の足がかりになりかねないと付け加えました。
企業はリスクを軽減するために何ができるか
Jain氏は「セキュリティチームは、これら脆弱なエージェントを実行しているマシンを調査すべきです。注意すべき重要な兆候としては、不審なプロセスやネットワーク接続、想定外のプラグインファイル、変更されたソースリポジトリ、不審なGitの活動、開発者用またはクラウド用認証情報の異常な使用などが挙げられます」と述べています。
同氏はさらに「EDR、Git、CI/CD、クラウドのIAM、そして認証ログは調査すべき有力な手がかりです」と付け加えました。
同アナリストによれば、その他の対策としては、コーディングエージェントが自動更新される設定になっているかを確認し、ベンダーが適用したパッチを確実に受け取れるようにすることも挙げられます。
ただし、こうした対策はリスクを軽減するにとどまり、根本的な脆弱性そのものを解消するものではありません。
Jain氏は「この根本的な脆弱性は、突き詰めればベンダー側の責任です。というのも、これはエージェントが実行を指示されたコードをどのように検証するかという仕組みに起因しているからです。ベンダーは、実際に実行されるコードが、レビューされ承認されたコードそのものであることを確実に保証する必要があります」と述べています。
同氏は「企業側はプラグインの利用方法に対して統制を敷くことはできますが、コーディングエージェントがチェックアウトしたコードを検証する仕組み自体に存在する欠陥を修正することはできません」と付け加えました。
