コーディングエージェントはコミットを固定した。どこに着地したかは確かめなかった
By Surya Pratap
2026年9月21日
11 min read
AI & Technology
2026年9月21日
11 min read
要求はしたが確認しなかった固定Hover to explore深刻度スコア以上の価値を持つ種類のセキュリティ報告がある。仕組みそのものが、別の場所にも当てはめられる何かを教えてくれるからだ。これはその一つである。
詳細は AIR による公開を報じた The Register、Help Net Security、Cyber Security News による。修正状況とベンダーの立場は公開時点で報じられたものであり、その後動いている可能性がある。第7節に、何を主張していないかを書いた。仕組みの読み方と第4節以降はすべて筆者の見解である。
2026年9月17日、AIR の研究者が Plugin4Shell を公開した。主要なAIコーディングエージェント四つのプラグイン機構に存在する、ゼロクリックのリモートコード実行の欠陥である。発見は2026年5月、四つすべてに対して動作する実証コードを作り、6月に各ベンダーへ通知した。
公開時点で報じられた状況は次のとおり。
| エージェント | 状況 |
|---|---|
| Claude Code | 2.1.179 で修正 |
| Codex | 0.146.0 で修正 |
| Copilot | 未修正と報告 |
| Gemini CLI | 提供終了。修正予定なし、利用者は別製品へ誘導 |
独立した四つのチーム、別々の四つのコードベース、そしてそのすべてに同じ誤り。
最後の点が手がかりだ。四社の競合が同じバグを出荷したなら、それは四回の不注意ではない。誰も書き留めなかった共通の前提である。
プラグインのマーケットプレイスは、審査を経たうえでプラグインを特定のコミットハッシュに固定する。誰もが信頼している制御がこれだ。SHA を固定すれば、誰かが目を通したバイト列がそのまま手に入る。lockfile の背後にあるのと同じ発想である。
対象となったエージェントが実際にしていたことは、こうだ。
ここまでは問題ない。この部分は機能している。
これ単独でも正しい。
ブランチを a94a8fe5ccb19ba61c4c0873d391e987982fbbd3 と名づけるのを止めるものは何もない。ただの文字列だ。
見ていないからだ。研究者の言い方を借りれば、エージェントはマーケットプレイスが固定した当のコミットをチェックアウトするが、そこに着いたかを一度も検証しない。
Gemini CLI の変種は同じ場所への別経路である。FETCH_HEAD という名前のブランチが、取得したコミットからチェックアウトを逸らす。この一点があるからこそ、これは一社の失策ではなく欠陥の一類型になる。
一般化できる教訓
固定は完全性ではない。固定は完全性の要求である。完全性はそのあとの検証、つまり「本当に要求したものを受け取ったか」を問う一手から生まれる。そしてその一手こそが省かれる。圧倒的多数の実行で答えは「はい」であり、検査は死んだコードに見えるからだ。自分のシステムで、識別子を指定して何かを取得し、届いたものからその識別子を導き直さずに使っている箇所はすべて、これと同じ形をしている。
サプライチェーンの欠陥はふつう利用者の操作を必要とする。インストール、アップグレード、確認ダイアログの承認。Plugin4Shell はそのどれも要らなかった。理由は、誰もが好んでいる機能である。
Claude Code と Codex は既定で背後の自動更新を走らせる。マーケットプレイスが固定した SHA を差し替えると、エージェントは自分の周期でチェックアウトを再実行する。攻撃者が悪意あるブランチをすでに用意していれば、入れ替わりは静かに起こる。ダイアログもインストールもなく、その場に誰もいない。
これは通常の助言を裏返す。
通常の依存関係であれば、「自動更新を有効にせよ」はよいセキュリティ助言だ。自動更新が運んでくるものの大半は修正だからである。しかし更新経路そのものが脆弱な部品である実行面では、自動更新は配送の仕組みになる。この二つはポリシー文書の上では見分けがつかず、挙動は逆を向く。
「プラグインの脆弱性」と読むと、封じ込められた問題に思えてしまう。そうではない。小さなチームがこれをどれだけ真剣に受け取るべきかは、この節で決まる。
コーディングエージェントのプラグイン機構を通じて実行されたコードは、研究者の表現によれば、そのエージェントを動かしている従業員と同じだけ、会社のシステムとデータに手が届く。ふつうの開発端末では、それは次を意味する。
プライベートリポジトリを含むソースコード。 ローカルにチェックアウトされているすべてへの読み取りと、その開発者が push できるすべてへの書き込み。
生きているクラウドのセッション。 ターミナルで既に認証済みのものすべて。クラウド CLI の資格情報、kubeconfig、データベースへのトンネル。資格情報を盗む必要はない。セッションは開いている。
環境ファイルとシークレットの置き場。 .env ファイル、ローカルのキーチェーン項目、面倒だからと回さないままシェルのプロファイルに残っているトークン。
エージェント自身のツール面。 そのエージェントが既に呼び出しを許されている連携のすべてが、利用者の承認履歴を背負ったまま、他人のコードに動かされる。
開発端末は、多くの会社で最も分離されておらず、最も広く届く機械である。そこで動くのが人間の選んだコードであるうちは、それでよい。更新経路が、誰も変更を決めていないのに実行されるものを変えられるとなれば、話はまったく別だ。
ここが構造的な論点であり、この件が一度の修正サイクルを超えて重要だと考える理由でもある。
アプリケーションの依存関係には統治がある。lockfile があり、スキャナがあり、誰かがパッケージを足すときのレビュー段階があり、求められれば出す SBOM がある。この仕組みを業界が組み上げるのに二十年かかり、おおむね機能している。
エージェントのプラグイン、スキル、拡張、マーケットプレイスからの導入には、そのどれもない。
アプリケーションの依存関係は、たいてい権限の絞られた ID を持つサービスの内側で動く。エージェントのプラグインは、人間の権限をまるごと持った作業端末で動く。レビューの薄い層のほうが到達範囲が広いのは、まさに逆である。そしてこれは事故として起きた。プラグインは生産性の機能として現れ、ソフトウェアのサプライチェーンとして現れなかったので、誰もサプライチェーンの仕組みを取り付けなかった。
私が話す多くのチームは、「チーム全体でどのエージェントプラグインが、どのバージョンで、どの作者のものが入っているか」に、机を一つずつ回らずには答えられない。これは怠慢ではない。それが問いであることを、誰も伝えてこなかっただけだ。
四つ。おおむね半日で、どれもセキュリティチームを必要としない。
Claude Code は 2.1.179、Codex は 0.146.0 以降。未修正や提供終了と報じられているものについては、そもそもプラグイン面を残すかどうかの判断になる。直っていない更新経路は監視するものではなく、止めるものだ。
チーム全体で導入済みのエージェントプラグイン、スキル、拡張を、作者とバージョン付きで。たいていは短い一覧で、一時間で終わる。長い一覧になったなら、それ自体が発見である。
エージェント本体は自動更新でよい。こうした修正はそこから届く。プラグインの更新は、少なくともコードを実行できるものについては人を一枚挟むことを検討する。これは別々の判断であり、今の多くのチームは両方をまとめて既定のまま決めている。
短命のクラウド資格情報、シェルのプロファイルに長命の本番トークンを置かない、データベースのトンネルを一日中開けたままにしない。次にどのエージェントがバグを出しても効き続ける対策であり、だから最初にやる価値がある。
そして、何を作っているにせよ自分のコードに足すべきことが一つ。
識別子を指定して取得している箇所をすべて洗い出す。コミット、ダイジェスト、モデルのバージョン、ドキュメント ID。そのうえで、実際に届いたものからその識別子を導き直している処理があるかを確かめる。答えが「要求したのだからそれのはずだ」なら、自分のシステムに Plugin4Shell と同じ形がある。塞ぐのに要るのは数行で、そうでなくなる日までは見えないままだ。
実環境での悪用は確認されていない。 これは動作する実証コードを伴う脆弱性公開であって、インシデント報告ではない。悪意あるプラグインが何台のエージェントに届きうるかとして出回っている数字はシナリオの試算であり、侵害された導入数の集計ではない。意図的に本文から外してある。
修正状況は公開の最中に動いており、情報源によって食い違う。 Claude Code と Codex は上記のバージョンで修正済みと一貫して報じられている。Copilot の露出についての報道は一貫していない。未修正とする記述もあれば、プラットフォーム側の制御で緩和済みとする記述もある。この表ではなく、自社が使うベンダーの告知を確認してほしい。
これは Git の脆弱性ではない。 Git が曖昧な参照を文書化された順序で解決するのは、仕様どおりの動作である。バグは、その結果が要求と一致していると仮定したエージェント側にある。道具のせいにするのは誤った教訓であり、それでは何も直らない。
筆者はいずれも再現していない。 第2節はすべて、公開された仕組みの説明に対する筆者の読みであって、独立した検証ではない。
ここで興味深いのは、四つのコーディングエージェントにバグがあったことではない。四つが共有していた前提が何だったかである。すなわち、あるものを正確に名指すことと、それを受け取ったと確認することは同じだ、という前提だ。
この前提はいたるところにある。正しい ID が付いているという理由で webhook を信じる連携、中身を検証せずキーで返すキャッシュ、latest を取ってきて再現可能だと称するパイプライン。ハッシュへの固定が安全に感じられたのは、ハッシュが具体的だからだ。しかし具体性は検証ではなく、その隙間こそがこの類型の住処である。
一方で実務上の露出は、地味で、いますぐそこにある。誰も変更を承認していないのに開発者の端末で実行されるものを変えうるコード経路が、社内で最も分離されていない機械の上にある。
今日エージェントを更新すること。そのうえで一時間かけて、チームにどのプラグインが入っているかを調べること。いまそれは多くのチームが答えられない問いであり、そして最初の本格的な顧客セキュリティ審査が投げてくるのと同じ問いだ。
出典：The Register, "AI coding agents' 0-click RCE flaw could hand attackers keys to the kingdom"、2026年9月17日。公開までの経緯、二つの攻撃経路、各ベンダーの立場について。Help Net Security, "Zero-click RCE vulnerability hit four major AI coding agents"、2026年9月18日。2026年5月の発見、6月の通知、修正版 2.1.179 と 0.146.0、そして実行されたコードが引き継ぐ権限の記述について。Cyber Security News。40文字のブランチ名による仕組みと、Gemini CLI に影響する FETCH_HEAD の変種について。研究は AIR によるもの。第2節の一般化、第3節の自動更新をめぐる議論、第5節の棚卸しの議論、および推奨事項はすべて筆者のものである。この分野で前に起きたサプライチェーンの事案はRubyGems のパッケージ洪水を、侵害されたプラグインの到達範囲を抑える権限モデルはエージェントの権限システムを参照。
IdeaToMVP Academy
4-week live cohort for founders. Learn to ship AI agents, scope MVPs, and automate your business — taught by the same team that writes these guides.
