更新履歴に載らない修正｜Plugin4Shellと自動更新

「AIに使わせる道具の更新履歴は、毎週きちんと目を通している」——そう言える方は、すでにかなり慎重な使い方をしています。

結論から言うと、その慎重さでも届かない修正があります。2026年9月17日に公表されたプラグインの脆弱性で、Claude Code の修正版は公表の3か月前にすでに配られていて、しかもその修正は更新履歴に1行も書かれていません。

株式会社Fyveは、Claude Code と Codex を日常業務で使い、無人実行のジョブも毎日走らせています。この記事では、npm レジストリと更新履歴の全文を自分で引いて確かめた事実をもとに、「読む習慣」では守れない領域はどこで、代わりに何を点検すればいいのかを整理します。

結論——今回あなたを守ったのは、読む習慣ではなく「更新され続けていたこと」

先に答えを書きます。今回の件で読者の手元が守られていたかどうかは、更新履歴を熱心に読んだかではなく、道具本体の更新を受け取り続けていたかで決まっていました。

• 何が起きたか：プラグイン（AIに使わせる道具へ後から足す拡張）を「このコードで固定する」と指定しても、その指定を迂回して別のコードに差し替えられる欠陥が見つかりました。主要な4つの道具が同じ欠陥を踏んでいました
• Claude Code はいつ直ったか：2.1.179 で修正済み。npm レジストリで公開時刻を引くと 2026年6月16日（公表の約3か月前）です
• 更新履歴には何と書いてあるか：書いてありません。2.1.179 の項目は9件ありますが、この修正を説明する行は1件もなく、履歴全文（7,158行）を横断検索しても見つかりません
• 実害は出たのか：発見者も「実環境での悪用は確認されていない」としています。9月18日時点でCVE番号も割り当てられていません。恐怖で判断する話ではありません

つまり、公表された日に多くの人が受け取った知らせの中身は「新しい脅威が出た」ではなく、「とっくに直っていたことを、今日はじめて知った」でした。

2026年9月17日に公表された「固定したはずのコードが入れ替わる」欠陥

この脆弱性は「Plugin4Shell」と名付けられ、セキュリティ企業 AIR Security が2026年9月17日に公表しました（報道は9月18日）。対象は Claude Code・OpenAI Codex・GitHub Copilot・Gemini CLI の4つです。

40桁のハッシュと同じ名前のブランチを作る、という手口

プラグインを配るとき、安全のために「このリポジトリの、この40桁のコミットハッシュの状態を入れる」と固定する仕組みがあります。指定した一点の状態しか入らないので、後から中身を差し替えられない——はずでした。

報告によると、攻撃者がそのリポジトリを支配できる場合、固定されているハッシュとまったく同じ名前のブランチを作り、それを既定のブランチに設定するという手が使えます。すると取得時のコマンドは、コミットではなくブランチのほうを優先して解決してしまいます。発見者の記述では「名前がrefとしてもオブジェクトIDとしても有効なとき、gitはrefを優先する」という挙動が起点です。

結果として、固定したはずの状態ではないコードが入ってきます。利用者の画面には何も起きません。ボタンを押す操作が要らないので「ゼロクリック」と呼ばれています。

この仕組みが実際に使われている場所も確認できます。Claude Code の公式ドキュメントには、コミュニティ向けのプラグインカタログについて「各プラグインはカタログ内で特定のコミットSHAに固定されている」と書かれています。固定は実在の防御策であり、だからこそ迂回されると影響が出ます。

4つの道具が同じ欠陥を踏み、対応が4つに分かれた

公表資料と複数の報道で一致している対応状況は次のとおりです。

公表までの経緯も報告に記載されています。発見と実証が2026年5月、4社への通知が6月、Anthropicの修正確認が6月17日、Googleから「修正しない」という回答が8月4日、OpenAIの修正検証が8月12日、そして公表が9月17日。通知から公表まで約3か月あり、その間に直った側と直らなかった側に分かれました。

読者特典・無料ダウンロードClaudeのこの5つの設定、今すぐ見直した方がいい無料でダウンロード →↓

修正は、公表の3か月前に配られていた（npmレジストリの実測）

ここから先は、報道に書かれていない部分です。どの記事も「Claude Code は 2.1.179 で修正済み」と書きますが、それがいつ配られた版なのかは書いていません。配布元のレジストリを自分で引けば分かります。

npm レジストリの @anthropic-ai/claude-code の公開時刻を確認すると、次のようになっていました（2026年9月21日時点の実測）。

• 2.1.179 の公開＝2026年6月16日（協定世界時 17時51分。日本時間では6月17日未明）
• 公表日（9月17日）に配布されていた版は 2.1.275、記事執筆時点の最新は 2.1.278
• 安定版として案内されているタグは 2.1.267＝修正版から版番号で88も先に進んでいます

言い換えると、この道具を普通に更新しながら使っていた人は、6月中旬以降ずっと修正版の側にいました。公表を知った時点で、やることはもう残っていなかった、という状態です。

逆に、何らかの理由で更新を止めて6月より前の版に留まっていた人だけが、公表までの3か月間、直っていない状態のまま気づく機会もなく使い続けていたことになります。ここが今回いちばん覚えておく価値のある非対称です。

そして、その修正は更新履歴に書かれていない

私が確かめたかったのは「では6月16日の更新履歴を読んでいれば気づけたのか」でした。答えはいいえです。

公式の更新履歴で 2.1.179 の項目を数えると9件あり、内容は接続が途中で切れたときの挙動、WSL2でのマウスホイール操作、サンドボックスの設定が大きくなりすぎてセッションが使えなくなる問題、アンケートの誤検知、歓迎画面のバナー、サブエージェント表示の不具合など、どれも今回の欠陥とは関係のないものでした。

履歴全文は7,158行あります。checkout・branch・sha・pin といった語で横断検索しても、2.1.179 の範囲にこの修正を説明する行は見つかりませんでした。

同じ「プラグインの取得」で、書かれている対策はある

ここが対比として効きます。まったく同じ領域——プラグインをどう取得するか——の安全対策が、別の版ではきちんと書かれているのです。

• 2.1.275（2026年9月17日公開＝公表当日）：npm 由来のプラグインを npm pack --ignore-scripts で取得し、整合性を検証するように変更。パッケージのインストール用スクリプトが走らなくなった、と明記されています
• 2.1.277：公式マーケットプレース由来のプラグインがコミット情報を記録せずに登録されていた問題、およびコミット固定のプラグインを更新しても古いコミットが残る問題の修正が明記されています

つまり書く／書かないは、重要度で決まっていません。公表前に静かに配られた修正は書かれず、公表後に入れた対策は書かれています。

これは隠しているという話ではありません。直る前に手口を公開しないのは、むしろ当たり前の運用です。ただ、読む側から見たときの結果は同じ——読んでも分からない、です。

「更新履歴を読む」に条件を足す

私は以前、この媒体で「道具は告知なしに毎日変わるのだから、更新履歴を見る日を決めよう」と書きました。その処方は今も正しいと考えています。

ただ今回、その処方が届かない領域があると分かったので、条件を足します。

更新履歴の読み方そのものは、以前まとめた手順が今も使えます。あわせて読むと、今回の「読んでも届かない領域」との境目が分かりやすくなります。

Claude CodeClaude Code更新履歴の読み方｜新機能より「直った」欄

自動更新の評価が裏返る——ただし「経路ごと」に違う

ここが今回いちばん判定の割れるところです。

報告では、この欠陥がゼロクリックになる条件としてプラグインがバックグラウンドで自動更新されることが挙げられています。利用者が何も押さなくても、取得処理が再び走ったときに差し替わりうるからです。自動更新は攻撃の入口だったという側面は事実です。

しかし同時に、道具本体の更新を受け取り続けていた人は、公表の3か月前から守られていました。自動更新は防御の手でもあったのです。

だから結論は「自動更新を切れ」にも「放っておけ」にもなりません。切っていた人ほど、直っていない版に長く留まります。評価する対象を変える必要があります。

既定でオンになっているのはどこか（公式ドキュメントの記述）

ここは推測せず、公式ドキュメントの記述で確認できます。プラグインの自動更新について、次のように書かれています。

• 公式マーケットプレース（claude-plugins-official）、他の公式マーケットプレースの多く、claude.ai から追加したマーケットプレースは自動更新が既定で有効
• それ以外のサードパーティ・ローカル開発用のマーケットプレースは、自動更新が既定で無効
• 更新の確認はセッション開始後、最大10分のランダムな遅延を置いて行われる（動いているセッションは起動時に読み込んだ版を使い続ける）

あわせて、報道では「コミットハッシュに見えるブランチ名・タグ名は GitHub 側で作れない」という指摘も出ています。公式・コミュニティのカタログは GitHub 上にあるため、既定でオンになっている経路は、今回の手口が成立しにくい場所だという整理になります。

逆に言えば、自分で追加した外部の配布元は既定では自動更新されない代わりに、オンにしたときだけ的になりうる。同じ「自動更新」という言葉でも、経路によって意味が反対になります。

だから点検するのは「更新」ではなく「自動で入ってくる経路」

1人か少人数でAIを回している場合、入ってくる更新を全部レビューするのは最初から選べません。確認の総量が稼働時間の上限にぶつかります。だから現実的な設計はこうなります。

• 止められないものは、入手元の数を減らす（配布元が多いほど、そのうちの誰かが直さない確率が上がります）
• 入手元ごとに、過去に直した実績があるかを見る
• 本体の自動更新と、プラグインの自動更新は別々に扱う（Claude Code では DISABLE_AUTOUPDATER で本体側を止めつつ、FORCE_AUTOUPDATE_PLUGINS=1 でプラグイン側の自動更新だけ残す、という組み合わせがドキュメントに記載されています）

無人で回している人は、更新の通知を見られない

ここは自分の運用で引っかかった点です。私は毎日決まった時刻に、人が見ていない状態でAIのジョブを走らせています。この使い方をしていると、今回の話は少し形を変えます。

公式ドキュメントの記述を並べると、こうなっています。

• プラグインが自動更新されると、「/reload-plugins を実行してください」という通知が出るか、次回の起動で新しい版が読み込まれる
• 更新の確認はセッション開始後、最大10分のランダムな遅延を置いて走る。動いているセッションは起動時に読み込んだ版を使い続ける
• 配布元が「コマンドで解決する」形式のプラグインは、自動更新の設定や DISABLE_AUTOUPDATER とは別の周期で、セッションごとに1回コマンドが再実行される

つまり無人実行では、通知を読む人がいません。そしてジョブが数分で終わる設計なら、更新の確認が走る前にセッションが閉じることもあります。逆に長時間動き続けるジョブは、起動時に読み込んだ古い版を持ったまま走り続けます。

ここで大事なのは「危ないから無人実行をやめる」ではありません。無人のジョブは、版の管理を人の目から切り離した状態で回っていると認識することです。私は無人ジョブ側では入れる拡張を最小限に絞り、版の確認は対話セッション側で行うという分け方をしています。無人実行が黙って止まる・黙って挙動が変わる類の問題は、こちらでも整理しています。

Claude CodeAIの無人実行が止まる原因3つ｜エラーが出ない停止の見つけ方

なぜ「拡張の経路」が狙われるのか

1つの欠陥に4社が同時に引っかかったのは偶然ではありません。拡張を配る仕組みは、1回仕込めば一度に多数の環境へ届くという構造を持っています。攻撃する側から見れば、効率が段違いです。

報告した AIR Security は、この考え方が実際に通ることを以前の調査でも示しています。報道によると、同社が作った検証用のプラグインは取り下げるまでに26,000を超えるエージェントへ広がったとされています。さらに、すでに使われている925件の拡張が、元の作者の手を離れて別の管理下に移っていたという調査結果も示されています。

この数字の受け取り方には注意が必要です。これらは今回の脆弱性による被害ではなく、「配布経路は現実に乗っ取りが起きている領域だ」という傍証です。それでも、点検の優先順位を決めるには十分な情報だと考えています。自分のコードをいくら丁寧に検査しても、入ってくるものの経路を見ていなければ、検査の外側から入ります。

この観点を工程に落とす話は、監査を段階に分けて回す仕組みの記事と合わせて読むと繋がります。

Claude Codesecurity-audit-skillとは｜6段階と使う条件

提供元の対応が4つに割れた——道具を選ぶ軸が1つ増えた

同じ欠陥を4社が踏んで、対応が「直した／直した／修正版が出ていない／畳んだ」に分かれました。ここは読者の道具選びに直結します。

注意したいのは、「畳む」は最悪の対応ではないということです。Gemini CLI は修正されませんが、後継への移行が案内されています。移る先が示されているぶん、利用者は動けます。

そして修正版が出ていない側についても、危険だと断定はしません。配布元が GitHub 上にある経路では前述のとおり同じ手口が成立しにくく、影響範囲の評価そのものが割れている状態です。私が言えるのは「対応が割れている」までです。

そのうえで、道具を選ぶ軸として次の1行が増えたと考えています。

この提供元は、過去に見つかった不具合を「直す側」だったか、「畳む側」だったか、それとも「そのまま使わせ続ける側」だったか。

いちばん扱いに困るのは3つ目です。移行先の案内もなく、修正もない状態がいちばん動きづらい。選定時に1件だけでも過去の処理を調べておくと、この軸は簡単に入れられます。

今日できる4手

ここまでの内容を、手を動かせる形にまとめます。どれも15分あれば終わります。

• ①入れている拡張を一覧にする：Claude Code なら /plugin の Installed タブ、または claude plugin list で出ます。「入れたことを忘れていたもの」が必ず1つは出てきます
• ②それぞれの入手元を書き出す：公式マーケットプレース／コミュニティ／自社や第三者の配布元、のどれかを1行で。入手元の数がそのままリスクの本数です
• ③自動更新の有無を確認し、「止めたら何が起きるか」を1行書く：止めれば差し替えは入りませんが、直った穴も入ってきません。この1行を書けないなら、まだ判断材料が足りていません
• ④「自分は今どの版か」を即答できるようにする：claude --version で出ます。今回のように「修正版の番号」だけが報じられる場面では、この1行が答え合わせのすべてです

使っていない拡張を落とす作業は、起動時間と読み込みコストの削減にもそのままつながります。プラグインの導入と棚卸しの基本は、こちらでまとめています。

Claude CodeClaude Codeのプラグイン自動ロード｜置くだけで導入

よくある質問

結局、プラグインの自動更新は切るべきですか

一律には切りません。既定でオンになっているのは公式系の配布元で、そこは今回の手口が成立しにくい経路です。自分で追加した外部の配布元は既定でオフなので、オンにしているものだけを見直すのが手数として正しい順番です。

今回の件で、自分に被害が出たかを確認する方法はありますか

発見者も実環境での悪用は確認していないと述べており、9月18日時点でCVE番号も割り当てられていません。まず確認すべきは被害の痕跡ではなく自分の版番号です。2.1.179 より前で止まっていたなら、更新してから入れている拡張を見直してください。

更新履歴を読むのは、もう意味がないのでしょうか

いいえ。新機能・仕様変更・不具合修正は履歴からしか分かりません。今回はっきりしたのは「読む」の射程に入らない種類があるということで、読むこと自体の価値は変わりません。

プラグインを入れるとき、事前に安全性は確認できますか

公式ドキュメントも「プラグインとマーケットプレースは自分の権限で任意のコードを実行できる高い信頼を置く構成要素であり、信頼できる提供元からのみ入れること」と明記しています。入れる前に中身を読む余裕がないなら、入手元を絞るのが唯一現実的な手です。

コードの脆弱性そのものを機械的に見つける方法はありますか

コミット前に差分をスキャンする仕組みを工程に入れる方法があります。ただし今回のような「配布経路の欠陥」は、自分のコードを見ても出てきません。工程の検査と、経路の点検は別の作業だと分けて持ってください。

Claude CodeClaude Securityプラグイン｜コミット前に脆弱性検出

まとめ——安全を支えていたのは、知識ではなく習慣だった

公表された日、多くの人は「新しい脅威が出た」と受け取りました。実際に起きていたのは、3か月前にとっくに直っていたことを、今日はじめて知ったというできごとです。

そして同時に、もう1つ分かります。自分の安全を支えていたのは自分の知識ではなく、更新を受け取り続けるという習慣だったということ。読む努力の量では埋まらない領域があり、そこは仕組みのほうで埋めるしかありません。

私たちが顧問先の環境を見るときも、更新履歴を読んでいるかは聞きません。聞くのは「何が自動で入ってくる状態になっているか」「その入手元はいくつあるか」の2つです。今日の4手は、それを自分で棚卸しするための最小の形です。

拡張の棚卸しや、AIに任せる範囲の線引きから相談したい場合は、Claude Code 導入支援・保守のサービスでも承っています。

参考ソース

• AIR Security 公式ブログ「Plugin4Shell」（発見者による一次報告・2026年9月21日確認）https://www.air.security/blog-posts/plugin4shell
• Help Net Security（2026年9月18日）https://www.helpnetsecurity.com/2026/09/18/plugin4shell-ai-coding-agents-vulnerability/
• The Hacker News（2026年9月18日・GitHub側のブランチ名の制約に言及）https://thehackernews.com/2026/09/plugin4shell-lets-repository-owners.html
• Claude Code 公式 CHANGELOG（2.1.179／2.1.275／2.1.277 の記述・全文7,158行を2026年9月21日に横断検索）https://github.com/anthropics/claude-code/blob/main/CHANGELOG.md
• npm レジストリ @anthropic-ai/claude-code（各版の公開時刻・配布タグ／2026年9月21日実測）https://registry.npmjs.org/@anthropic-ai/claude-code
• Claude Code 公式ドキュメント「Discover and install prebuilt plugins through marketplaces」（自動更新の既定・コミットSHA固定・セキュリティの注意／2026年9月21日確認）https://code.claude.com/docs/en/discover-plugins

※本記事の対応状況・版番号は2026年9月21日時点で一次情報および公式の更新履歴で確認できた内容です。各社の対応は今後変わる可能性があるため、判断の際はその時点の提供元の案内をご確認ください。