Plugin4Shell、AIエージェント4製品が確認を省く── 版を固定した記録は残っても、その版が実際に入ったかは確かめられておらず、確認の報告と確認の事実は別に見る必要がある

2026年9月17日、イスラエルのセキュリティ企業Airが、Claude Code・Codex・GitHub Copilot・Gemini CLIという4つのAIコーディングエージェントに、利用者が何も押さなくても外部のコードが動く欠陥「Plugin4Shell」があると公表した。AIエージェントが「確かめた」と報告したとき、その確認は誰が確かめているのか。4製品とも、版を固定したという記録は残したが、その版が実際に入ったかは確かめておらず、確認の報告と確認の事実を分けて見る仕組みを、利用者の側で持つ必要がある。

01AIエージェント4製品は、固定した版が入ったかを確かめていなかった

冒頭の問いに、今回の事例はかなりはっきり答えている。4製品のどれも、確かめていなかった。

Plugin4Shellの本体は、AIモデルの賢さや判断の誤りではない。AIエージェントが外部の拡張機能、つまりプラグインを取り込むときの手順に欠けがあった。手順の上では「この版を使う」と番号で固定している。ところが取り出したあと、手元に来たものがその番号の版と同じかを照らし合わせていなかった。発見者のAirは、これを4つの主要なコーディングエージェントすべてに共通する、利用者の操作を要しない遠隔コード実行の欠陥と位置づけている。

記録は正しい。表示も「成功」である。それでも、中に入ったのは別のコードでありうる。読者が持ち帰るべき結論は一つで、エージェントの「成功」「確認済み」という表示を、作業が正しく終わった証拠としてそのまま扱う運用は見直す必要があるということだ。以下、何が起き、どこまで届き、なぜ防げず、各社がどう動いたかを順に確かめる。

02欠陥は、コミットと同じ名前の枝を先に読むGitの規則を突いた

前節で「確かめていなかった」と書いたものの中身は、Gitの仕様と、取り込みの手順の組み合わせにある。

プラグインの配布元は、どの版を配るかを40文字のコミット番号で指定している。コミット番号は、その版の中身から計算される識別子で、同じ番号なら同じ中身だと期待できる。エージェントは、この番号を指定してプラグインの保管場所から版を取り出す。

Airと報道によれば、攻撃者がプラグインの保管場所に、その40文字と同じ名前の「枝」を作ると、取り出しの操作は番号の版ではなく同名の枝の側を読んでしまう。Gitの文書には、名前があいまいなとき、決まった順に規則を当てて最初に一致したものを採ると書かれている。今回の挙動はこの規則のとおりで、Gitの不具合ではない。

ここで線を引いておく。攻撃が成り立つ条件は、攻撃者がプラグインの保管場所に書き込めることだ。正規の開発者のアカウントが乗っ取られる、保管場所の管理が移る、といった経路が考えられる。攻撃の具体的な手順はこの記事では扱わない。論じたいのは手順の細部ではなく、エージェントが最後に出す「成功」が、番号を指定したという事実しか映していないという点である。

03被害は、開発者の権限を持つすべての作業環境と導入審査に及ぶ

仕組みが分かったところで、次はそれが働いたときに何に届くかを見る。

プラグインは、エージェントを動かしている開発者と同じ権限で動く。Cyber Security Newsは、その範囲として、手元のソースコード、クラウドの認証情報、SSH鍵、社内のリポジトリ、本番のシステム、各種の秘密情報を挙げている。開発者の端末で動くものは、開発者が触れられるものすべてに触れられる。

この範囲は開発部門の中にとどまらない。AIコーディングエージェントを業務に入れる会社は、たいてい導入の前に審査をする。どの製品を使うか、どのプラグインを許すか、どの権限を与えるか。その審査は「許可したものが、許可した形で動く」という前提の上に立っている。Plugin4Shellは、その前提そのものを外す。審査で許したのは番号で固定した版なのに、実際に動くのは別のコードでありうるからだ。

影響を受ける利用者の数について、Airは「数百万のエージェント」と表現している。これは発見者の言い方であり、独立に数えた数値ではない。ただ、4製品がいずれも主要なコーディングエージェントであることは確かで、どれか一つを使っている開発組織は少なくない。

04自動更新が、確認の省略を利用者の操作なしの侵入に変えた

権限の広さは被害の大きさを決める。けれど、誰も何も操作していないのに侵入まで進んだ理由は別にある。

原因は二つに分けて考えると分かりやすい。一つ目は、ここまで見てきた「着地を確かめない」手順で、4製品に共通していた。これだけなら、被害が起きるのは利用者がプラグインを入れる、あるいは入れ直すときに限られる。その場で何かがおかしいと気づく機会も、まだ残っている。

二つ目が、自動更新である。Cyber Security Newsによれば、Claude CodeとCodexは、入れてあるプラグインを既定で裏側で更新する。利用者が一度正規のプラグインを入れておけば、あとは製品が勝手に新しい版を取りに行く。すると、正規のプラグインが後から乗っ取られた場合、利用者が何もしないまま、乗っ取られた側のコードが取り込まれる。気づく機会がそもそも存在しない。Airが「ゼロクリック」と呼んだのは、この組み合わせのことだ。

どちらか一つでは、今回の形にはならない。着地を確かめていれば、自動更新があっても食い違いで止まる。自動更新がなければ、確かめない手順でも侵入の起点は利用者の操作になる。二つの設計が重なり、そこに開発者と同じ広い権限が加わったとき、確認の省略は侵入に変わった。

05修正は2社にとどまり、残る2製品は修正が確かめられていない

では、二つの原因に対して各社は実際にどう手を打ったのか。数えられる形で並べる。

Airによれば、欠陥を見つけたのは2026年5月で、6月に各社へ伝えた。AnthropicはClaude Codeの2.1.179で、OpenAIはCodexの0.146.0で修正した。なお、Claude Codeの修正版の番号は、私は公式の変更履歴では確かめられておらず、発見者と報道の記載による。

残る2社の対応は違った。報道によれば、Microsoftは6月に通知を受けたあともCopilotを修正していない。ただし、GitHubは対策済みだと主張しており、「未修正」は発見者と報道の見方である。Googleは8月4日にGemini CLIを廃止扱いにすると発表し、この欠陥を修正しなかった。

表から読めるのは、自動更新で被害が操作なしになる2製品が、同時に修正も済ませた2製品だという組み合わせである。更新を受け取る仕組みがあれば、修正も同じ経路で届く。ただしこれは2社の組み合わせから読める範囲で、自動更新が修正の理由だとまでは言えない。修正が確かめられない2製品では、利用者が手を打たない限り欠陥は残ると見て扱う。

06確認の表示を証拠から外し、着地を別に確かめる運用が要る

修正が半分にとどまると確かめたことで、利用者の側で決めなければならないことがはっきりする。

論点は三つある。一つ目は、エージェントの「成功」表示の扱いだ。4製品はいずれも、表示と実体を突き合わせていなかった。だから表示は報告であって、検証の結果ではない。完了の判定には使えず、入ったものを別の手段で照らし合わせる一段が要る。

二つ目は、自動更新の既定値である。導入のときに一度審査しても、そのあと中身が裏側で替わるなら、審査の結論は長くはもたない。既定で自動更新が入る製品では、更新を止めるか、更新してよい範囲を限るかを決める必要がある。審査は一度で終わらない。

三つ目は、修正されない製品の扱いだ。Copilotは発見者の見方では未修正で、Gemini CLIには修正の予定がない。使い続けるなら、その製品では外部のプラグインを入れない、入れるなら中身を別に確かめる、といった代わりの管理を利用者が決めることになる。

三つとも、AIの賢さでは決まらない。取り込む部品の出どころを確かめることは、NISTの安全なソフトウェア開発の枠組みが既に求めている実務でもある。新しいのは、その確認を人ではなくエージェントに任せ、任せた結果の表示を信じてしまう場面が増えたことだ。

07同じ前提は、AIエージェントが取り込む他の部品にも残っている可能性がある

三つの論点は、今回の4製品だけの話なのか。最後にその範囲を見ておく。

確かめられている事実は、プラグインの取り込みで着地が確かめられていなかったことまでである。一方、構造だけを見ると、外部の部品を名前や番号で指定して取り込み、結果を「成功」の表示で伝えるという形は、プラグイン以外にもある。エージェントがつなぐ外部の道具、取り込む設定、呼び出す接続先。どれも「指定した」という記録と「実際に来た」という事実が分かれうる。

そこに同じ種類の欠陥があるのか、まだ見つかっていないだけなのか、そもそも無いのかは、確かめられていない。ここは推論として書いておく。確かなのは、今回のように表示と実体を突き合わせない設計が一つ見つかれば、利用者は同じ問いをほかの取り込み口にも向けられる、ということだ。

導入する側にできることは、エージェントの表示を受け取ったあとに、照合を一段挟むことである。入った版の番号と中身を比べ、自動更新の範囲を限り、修正のない製品を分けて扱う。そうすれば、次に別の取り込み口で同じ欠陥が見つかっても、報告と事実を分けて見る仕組みは既に手元にある。

AIエージェントが「確かめた」と報告したとき、その確認を確かめていたのは、4製品のどれでもなかった。番号を指定したという記録は正しく、表示は成功だった。それでも、入ったものが指定したものと同じだとは、誰も見ていなかった。

確認の報告と確認の事実を分ける。入ったものを自分で照らし合わせる一段を、導入する側が持つ。エージェントに作業を任せることと、作業の結果を確かめることは、別の仕事である。