メインコンテンツまでスキップ

ClaudeBleed 再燃 — 「解決」がパッチではないとき

上級
What you'll learn
  • Claude for Chrome の 2 つのバイパスを理解する — 欠けた event.isTrusted チェックと、サイドパネルを自己昇格させる URL パラメータ
  • Anthropic が 6 月 9 日以前にトラッカーを「解決済み」にマークし、その後 8 つのリリース（v1.0.73 → v1.0.80）を変更なしで出荷したことが本当の話であると理解する
  • 一般的な防御パターンを学ぶ：別の拡張が同じ origin を共有する場合、クライアント専用の allowlist はセキュリティ境界にならない
  • 今すぐ 2 分未満で適用できる 3 つの具体的な緩和策を取る

2026 年 7 月 7 日、Anthropic は Claude for Chrome v1.0.80 をリリースした。Manifold Security は同日にテストし、5 月に提出した 2 つのバグレポートが v1.0.72 からバイトごとに再現可能であることを発見した。ブラウザ上で claude.ai にスクリプトアクセス権を持つ他の拡張 — 数千の Chrome 拡張が要求する権限 — が、Claude に静かに Gmail を開かせ、メッセージを読ませ、それに基づいて行動させることができる。承認ダイアログなし。ユーザージェスチャーなし。

物語は「拡張にバグがあった」ではない。Chrome 拡張は常にバグを出荷している。物語は、9 か月の精査と公開「ClaudeBleed」インシデントを経た出荷済みエージェント型ブラウザ製品が、依然として攻撃者が完全に制御する場所 — クライアント — で権限モデルを強制し、コードが変わらずにトラッキング Issue を Resolved とマークしていることだ。

2 つの欠陥を 1 枚の絵で​

2 つの独立したバグ。どちらか単独でも ハードコードされたすべてのタスクをトリガするのに十分だ。一緒に使えば、一方がトリガ（偽クリック）を、もう一方が静かな実行（自動昇格）を与える。

欠陥 #1 — 欠けた isTrusted チェック​

ブラウザがディスパッチするすべてのイベントには isTrusted ブール値がある。実際のユーザー動作 — 物理的なクリック、キー押下、タッチ — は isTrusted: true で届く。JavaScript が dispatchEvent(new MouseEvent(...)) で合成したものは isTrusted: false で届く。これはブラウザの唯一信頼できる ユーザー対コード シグナルであり、セキュリティ機微なハンドラが両者を区別できるようにするために存在する。

Claude for Chrome の content script は id #claude-onboarding-button の要素へのクリックをリッスンし、そのクリックが 9 個の allowlist されたタスク ID（usecase-gmail、usecase-gdocs、usecase-calendar、usecase-salesforce、加えて DoorDash、Zillow、3 つのオンボーディングチャレンジ）のいずれかに一致すれば、対応するプロンプトを Claude のサイドパネルに転送して実行させる。

ハンドラは event.isTrusted を決してチェックしない。研究者の言葉を借りれば：拡張の視点からは、偽のクリックと本物のクリックは区別できない。

これが重要なのは、見落としやすいアーキテクチャ上のポイントのためだ：https://claude.ai/* に一致する content_scripts を持つ、あなたがインストールしている他のどの Chrome 拡張も、Chrome の視点からは Claude の origin を共有し、ページにスクリプトを注入できる。 その権限は稀ではない — パスワードマネージャー、ノートクリッパー、翻訳ツール、広告ブロッカー、無数の「生産性」拡張が、当然のように要求する。そのページで一度スクリプトが動けば、#claude-onboarding-button に合成クリックをディスパッチするのは約 6 行のコードだ。Manifold のレポートは、まさにそのサイズを指摘してポイントを作っている：修正は if 文 1 つ、エクスプロイトは dispatch 呼び出し 1 つ。

9 プロンプトの allowlist は Anthropic の 以前の ClaudeBleed 緩和策だった — 「クリックが偽装されても、固定リストの安全なタスクしか動かせない」というアイデアだ。「Gmail 統合を実行する」がリストにあった瞬間、そのモデルは破綻する。Gmail を読み行動することは安全なタスクではない。

Pro tip
  • 教訓は「isTrusted を追加する」ではない — その下の教訓だ：「安全な」エージェントタスクの allowlist は、リスト上の最も安全でないタスクと同じだけの安全性しかない。細粒度で統合ごとのユーザー同意は、信頼できないフリーフォームトリガだけでなく、これらすべてのトリガに属する。

欠陥 #2 — パネル URL の ?skipPermissions=true​

Chrome 拡張のサイドパネルには独自の URL があり、その URL のクエリ文字列はパネル内で window.location.search から読める。Claude のサイドパネルは skipPermissions パラメータを読む。"true" に等しければ、パネルは permissionMode = "skip_all_permission_checks" で初期化される — ユーザーが手動で Act without asking を有効にしたときと同じ内部モードだ。

これはクライアント側の、自己サーブの権限昇格だ。パネルが自分自身に許可を求め、パネル自身が URL で受け取った値に基づいて yes と答えている — chrome.sidePanel.open({...}) を呼べる、あるいはパネルを navigate できるものが供給できる値だ。

Manifold はそのシナリオを CVSS 9.6 Critical と評価している。そのモードでは承認ボックスが一切ないためだ：9 つの allowlist されたプロンプトは静かに実行される。合成クリック欠陥単独（通常の承認ボックスが依然として表示される）は 7.7 High と評価されており、ユーザーが Enter を押す前にダイアログに気付ける可能性があるためだ。

修正の正しい形は「URL パラメータをサニタイズする」ではない。権限モード間の遷移には、パネルがロードされた後に実際の UI コントロールへの明示的で isTrusted なユーザージェスチャーが必要 — パネルが自身の URL、自身のストレージ、あるいは他のどの拡張も投稿できるメッセージチャネルから読み取った値ではならない。それはブラウザがすでに全画面表示、カメラ、クリップボード権限に適用しているのと同じアーキテクチャ制約であり、同じ理由からだ。

なぜ「Resolved」≠ パッチ — プロセス失敗​

タイムラインが、これをコードストーリーではなくガバナンスストーリーにしている：

Guided walkthrough1 of 5
  1. v1.0.72 に対し、2 つの別々のバグレポートを Anthropic に提出。

内在化する価値のある 2 つの失敗モード。この物語の外でも一般的だからだ：

  1. 緩和策の崩壊。 エクスプロイトの形を変える緩和策（「今度は 9 つのボタンのいずれかをクリックしなければならない」）が修正として扱われる。それらのボタンのトリガ自体が偽装可能なとき、緩和策はセキュリティを追加しない — 攻撃レシピを変えるだけだ。
  2. 「設計上解決」ドリフト。 バグ #2 は、拡張自身のみが skipPermissions を設定するという説でクローズされた。それは 意図 の説明であり、ブラウザの実際の強制 ではない。sidePanel アクセス、あるいはパネル URL 経由のリダイレクトを持つものは何でもそれを設定できる。

両方のパターンは、理由があってセキュリティレビューのアンチパターンリストに載る。自分のコードでも警戒すべきだ。

何が動き、どんなデータに到達できるか​

Manifold のレポートからの 9 つのハードコードされたタスク ID：

カテゴリタスク IDプロンプトが Claude に指示するおおよその内容
Googleusecase-gmail、usecase-gdocs、usecase-calendarGmail を読む（受信箱を反復する「プロモメールから配信停止」フローを含む）、Google Docs のコメントを読む、Calendar の空き状況を読みミーティングを作成
CRM / コマースusecase-salesforce、usecase-doordash、usecase-zillowSalesforce のリードを読み opportunities に変換；DoorDash / Zillow のフローを実行
オンボーディング3 つのオンボーディングチャレンジガイドツアーのプロンプト

到達範囲は被害者が有効にしたコネクタに依存する。Gmail が接続されていれば、usecase-gmail は Gmail を読む。Salesforce が接続されていれば、usecase-salesforce は CRM に触れる。パネルはユーザーが頼んだことをしている — ただしこのユーザーではなく、今ではない。

Watch out
  • 「Act without asking」は特別な開発者モードではない。Claude for Chrome 設定のチェックボックスだ。ON なら、欠陥 #1 単独で実際の Gmail / Docs / Calendar / Salesforce の読み取りをトリガする。OFF でも、欠陥 #2（?skipPermissions=true）がパネルのライフタイム中それを静かに再有効化できる。

今やる 3 つのこと（2 分）​

Guided walkthrough1 of 3
  1. Claude for Chrome 設定 → 「Act without asking」を無効化。承認プロンプトは煩わしいが、欠陥 #1 単独があなたに残す唯一のユーザーに見えるシグナルだ。

チーム全体でエージェント型拡張を運用するなら、4 つ目を追加：エージェントが実際に何を実行するかのランタイム観察 — 保持している権限だけではなく。両方の欠陥は権限監査を通過し、挙動観察に失敗する。ユーザーが頼まなかったことをエージェントに させる からだ。そのギャップこそが Manifold 自身の推奨が着地するところで、この 1 製品を超えてよく一般化する。

Chrome extension audit prompt for Claude

Here is my current chrome://extensions export (or a list I'll paste): {LIST}.

For each extension:
1. Is its "site access" set to "All sites" or does it match claude.ai? Flag those.
2. From its Chrome Web Store description, what content_scripts permissions does it plausibly require? Is claude.ai a required domain for its stated function?
3. Rate each on a "trust to run a script inside my Claude tab" scale from 1 (dedicated password manager from a known vendor) to 5 (random productivity extension with <10k installs).
4. Give me a two-column recommendation: KEEP AS-IS / RESTRICT TO SPECIFIC SITES / REMOVE — with a one-line reason per row.

Do not soften. If something looks sketchy, say sketchy.

より広いパターン — クライアント専用の allowlist、エージェント型スコープ​

Claude for Chrome から視野を広げよう。同じ形が、増えつつあるエージェント型製品に現れる：

  • 信頼された UI（拡張、デスクトップアプリ、IDE プラグイン）が、ユーザーデータに対して実アクションを取れるエージェントを露出する。
  • リスクを制約するため、ベンダーは承認なしにエージェントが実行できるタスク／プロンプト／ツールの allowlist を追加する。
  • allowlist のエントリの トリガ は クライアント内部 に留まる — クリック、URL、保存された設定、他のコンポーネントが共有するチャネルのメッセージ。
  • 同じ信頼ゾーンの他のコード（同じ拡張ホスト、同じ origin、同じ IPC バス）はトリガを偽装できる。

各ラウンドが教える教訓は同じだ。参照：docs/security/agentic-browsers-same-origin.mdx（エージェントの SOP を超える読み取り）、docs/security/coding-agents-under-attack.mdx（自動承認は新しい攻撃表面）、docs/security/prompt-injection.mdx（信頼できないコンテンツは信頼できない指示になる）。すべてが 境界が攻撃者がすでに立つ場所に引かれている ケースだ。

付箋に書き留める価値のある 2 つの不変式：

  1. 攻撃者が呼べる権限チェックは権限チェックではない。 「このページの任意のスクリプト」「任意の URL パラメータ」「任意のストレージ値」「未知の origin からの任意の postMessage」のいずれかがエージェントを ask から act に切り替えられるなら、その切り替えはあなたがレンダリングした実 DOM 要素での isTrusted ジェスチャーの背後に属する。
  2. Allowlist は同意の代替ではない。 リスト上の単一のタスクが求められずに実行されるとユーザーを驚かせるなら（read my Gmail は該当）、allowlist は攻撃者の選択肢を減らすが、攻撃者の影響を減らさない。

クイックチェック​

Check yourself

0/4
  1. Claude for Chrome v1.0.80 で、claude.ai へのスクリプトアクセス権を持つ普通の Chrome 拡張が 9 つの allowlist されたタスクをトリガするのに十分な理由は？
  2. ?skipPermissions=true バイパスの実際のメカニズムは？
  3. Anthropic は 2026 年 6 月 9 日以前に根本トラッカーを「Resolved」とマークしたが、v1.0.80（7 月 7 日）は v1.0.72 とバイト一致だ。これが最もよく示す失敗モードは？
  4. Claude for Chrome ユーザーが今すぐ適用できる最強の単一緩和策は？
Key takeaways
  • Claude for Chrome の v1.0.80（2026 年 7 月 7 日）は、5 月に v1.0.72 で最初に報告された 2 つの Manifold バグ — 9 プロンプト allowlist の合成クリックバイパス、およびパネル URL の ?skipPermissions=true による自己昇格 — に依然として脆弱。
  • 両方のバグはクライアント専用の権限チェックだ。トラッカーの「Resolved」は緩和策（allowlist）を指しており、根本の強制ギャップの修正ではない。
  • 今すぐ：Act without asking をオフにし、claude.ai にスクリプトを注入できる他の Chrome 拡張を監査し、使っていないコネクタを切断する。
  • 一般ルール：ページ上の任意のスクリプトが呼べる権限チェックは権限チェックではない。モード遷移は URL / ストレージ / メッセージ値ではなく、実 UI 要素上の isTrusted ジェスチャーに乗らなければならない。

ソース & 追加読み物​