はじめに
2026 年 7 月、AI セキュリティ企業 Manifold Security が、Anthropic のブラウザ拡張機能「Claude for Chrome」に未修正の脆弱性が 2 件残っていると報告しました。同社によると、この欠陥を悪用すると、悪意のある別のブラウザ拡張機能が、利用者本人のクリックや承認なしに Claude へ操作を実行させ、Gmail・Google ドキュメント・カレンダーの内容を読み取れる可能性があります。
Claude for Chrome はブラウザのサイドパネルで動作し、ログイン中の Web サービスに対して利用者の代わりに操作を行える agentic な拡張機能です。それだけに、乗っ取られた場合の影響範囲は通常の拡張機能より広くなります。本記事では、報告された 2 つの脆弱性の仕組みと影響範囲を整理し、パッチが提供されていない現時点でエンジニアが取れる現実的な対策を、実務目線でまとめます。
- Claude for Chrome に報告された 2 つの脆弱性(偽装クリックの受け入れ/承認スキップ)の仕組み
- 影響を受ける利用形態と、動作モードによる深刻度の違い
- インフラエンジニアの業務環境で想定すべき具体的なリスクシナリオ
- パッチ提供前に実施できる設定見直しと、組織単位での緩和策
結論を先に述べると、この脆弱性は Claude for Chrome を単体で使っているだけでは成立せず、claude.ai 上でスクリプトを実行できる別の拡張機能を併用していることが前提になります。「ask before acting(実行前に確認)」モードでは偽装された操作の前に承認ダイアログが残るものの、「Act without asking(確認せず実行)」モードを有効にしている場合は、承認なしで実行されます。パッチが未提供の現時点では、「Act without asking」を無効化し、claude.ai にアクセスできる拡張機能を棚卸しすることが、最も現実的な緩和策になります。

Claude for Chrome で報告された 2 つの脆弱性
今回報告された脆弱性は、いずれも「拡張機能の内部にある信頼境界」に関わるものです。Manifold の研究者は最新版 v1.0.80(2026 年 7 月 7 日リリース)で問題が再現することを確認しています。以下、2 つの欠陥を順に見ていきます。
偽装クリックの受け入れ(event.isTrusted 未検証)
1 つ目は、拡張機能がクリックの真正性を確認していない問題です。
Claude for Chrome の content script は、claude.ai 上の特定のボタン要素(#claude-onboarding-button)へのクリックを監視しています。クリックを検知すると、その要素の data-task-id を読み取り、あらかじめ組み込まれたタスク ID であればサイドパネルを開いて対応するプロンプトを読み込みます。
問題は、このハンドラーが event.isTrusted(実際の利用者のクリックか、スクリプトが発火させた合成クリックかをブラウザが区別するフラグ)を確認していない点です。その結果、claude.ai の DOM にアクセスできる拡張機能であれば、この要素を生成し、タスク ID を設定して合成クリックを発火させることができます。
参考: The Hacker News(Manifold Security の報告)
“The extension treats it as a genuine tap.”
(拡張機能はそれを本物のタップとして扱う。)
https://thehackernews.com/2026/07/claude-for-chrome-flaw-lets-other.html
偽装クリックで起動できるのは、拡張機能に組み込まれた 9 個の固定タスクに限られます。内訳は、オンボーディング用の練習プロンプトが 3 個、DoorDash・Salesforce・Zillow を操作するタスクが 3 個、そして Gmail・Google ドキュメント・カレンダーを読み取る usecase-gmail・usecase-gdocs・usecase-calendar の 3 個です。任意のプロンプトを注入できるわけではないため「何でも実行できる」性質のものではありませんが、後述するとおり、この 3 個の Google サービス系タスクだけでも情報漏えいには十分つながり得ます。
深刻度は動作モードによって分かれます。Manifold はこの欠陥を、ask before acting モードでは CVSS 7.7(High)、Act without asking モードを有効にした場合は 9.6(Critical)と評価しています。前者では読み取りの前に承認ダイアログが残りますが、後者では同じタスクが承認なしで実行されます。
skipPermissions パラメータによる承認スキップ
2 つ目は、承認ステップそのものを飛ばせてしまう構造上の問題です。
Claude のサイドパネルは、URL に ?skipPermissions=true が付いた状態で読み込まれると、承認チェックをすべて省略するモード(skip_all_permission_checks)で起動します。Claude が多くの操作を実行できる状態になったことを示す赤いバナーは表示されますが、それは特権セッションがすでに動き始めた後に出るため、バナーは「何が起きたか」を伝えるだけで、それを止めるものではありません。
ただし現時点では、この URL は拡張機能自身しか生成できないため、外部から直接到達する経路はありません。問題は、将来 URL を受け付けるメッセージハンドラーやパネル生成部の不具合、オプションページの XSS などによって、低い権限のコンテキストからこのパラメータを設定できるようになった場合、先ほどの偽装クリックと組み合わさって、完全に無言のアカウント読み取りに発展し得る点です。この 2 つ目の欠陥は Gmail の利用有無とは無関係な、拡張機能の設計そのものに関わるリスクとして押さえておく必要があります。
ClaudeBleed からの経緯と修正状況
今回の 2 件は、突然現れた新種の脆弱性ではなく、2026 年 4 月に公開された「ClaudeBleed」の対応の延長線上にあります。ClaudeBleed は、権限を持たない拡張機能でも Claude for Chrome にコマンドを送り込め、Gmail・GitHub・Google Drive からのデータ持ち出しやメール送信を行わせられるという脆弱性でした。
Anthropic はこの対応として、外部から渡せるプロンプトを固定タスクの集合に絞り込む初期緩和策を導入しました。今回 Manifold が指摘しているのは、その「固定タスクを起動する仕組み」自体がクリックの真正性を確認しておらず、緩和策を回避できてしまう、という点です。
Manifold は両方の問題を 5 月 21 日に v1.0.72 に対して報告し、Anthropic は翌日に受領したものの、いずれのレポートもクローズしました。偽装クリックの件は、根本にある信頼境界の問題が先行する ClaudeBleed のレポートで追跡済みであることを理由に、URL の件は「そのパラメータは利用者が無人実行を指示したタスクに対して拡張機能自身が設定するだけ」という理由でクローズされています。Manifold の研究者 Ax Sharma 氏は 7 月 7 日に再検証し、問題のコードが最初に報告したバージョンとバイト単位で同一のままだと確認しています。2026 年 7 月 14 日時点で、Anthropic は Manifold の指摘に対する公式な見解を公表しておらず、CVE も採番されていません。
なお、ClaudeBleed 以前にも、2025 年末に報告された「ShadowPrompt」(任意の Web ページから無クリックでプロンプトを注入できる脆弱性、v1.0.41 で修正済み)など、Claude for Chrome の信頼境界に関わる事案が複数報告されています。これら一連の事案の俯瞰と、共通する構造的な問題(confused deputy 問題)については、関連記事『AI エージェントのセキュリティリスク|2026 年の事案に共通する構造と対策』で整理しています。
影響範囲と前提条件
この脆弱性が成立する条件と、影響を受ける対象を整理します。ポイントは、Claude for Chrome を単体で使っているだけでは成立しないこと、そして被害の中身が「そのブラウザで何にログインしているか」に依存することの 2 点です。
対象バージョンと成立の前提条件
Manifold が再現を確認したのは最新版の v1.0.80 ですが、問題のコードは最初に報告された v1.0.72 と同一のままであり、その間にリリースされた版でも修正は入っていません。Claude for Chrome は現在もベータ版として提供されており、有料の Claude 契約者であれば誰でも利用できる状態です。
攻撃が成立する前提は、次の 2 つが同一ブラウザに揃っていることです。
- Claude for Chrome が導入され、ブラウザ操作が有効になっていること(オンボーディング完了後の既定状態)
- claude.ai の DOM にスクリプトを実行できる別の拡張機能が併存していること
2 つ目の「claude.ai 上でスクリプトを実行できる」権限は、拡張機能にとって珍しいものではありません。ページの読み取りや変更を行う拡張機能は広くこの権限を持つため、心当たりのない拡張機能が偽装クリックの起点になり得ます。
参考: SecurityWeek
“A ClaudeBleed-linked vulnerability reportedly persists across eight patches.”
(ClaudeBleed に関連するこの脆弱性は、8 回のパッチを経ても残っているとされる。)
https://www.securityweek.com/unpatched-claude-for-chrome-flaw-lets-extensions-read-gmail-calendar/
なお、この挙動はサイドパネルの Claude モデルを Opus・Sonnet・Fable のいずれに設定していても再現します。原因は拡張機能側にあり、モデルの選択では変わりません。
Gmail を使っていなくても対象になるケース
「Gmail を使っていないから無関係」と考えるのは早計です。判断基準は「Gmail をメインで使っているか」ではなく、「そのブラウザで Google アカウントにログインしているか」です。
Claude for Chrome はブラウザのログイン済みセッションを使って動作します。そのため、普段メールを別のクライアントで読んでいても、Chrome の同期や YouTube の利用のために Google アカウントへログインしていれば、usecase-gmail・usecase-gdocs・usecase-calendar の 3 タスクは動作し得ます。対象は Gmail 単体ではなく、Google ドキュメントとカレンダーも含みます。
また、固定タスクには Salesforce を操作するものも含まれます。DoorDash や Zillow は国内エンジニアの業務では実質的に無関係ですが、業務で Salesforce にログインしている場合は、こちらも射程に入ります。
動作モード別の深刻度
深刻度は、拡張機能をどのモードで使っているかで大きく変わります。
- ask before acting(実行前に確認)
-
偽装クリックでタスクがサイドパネルに読み込まれても、実際の読み取りの前に承認ダイアログが残ります。利用者がそのダイアログをクリックしない限り読み取りは実行されません。Manifold の評価は CVSS 7.7(High)です。
- Act without asking(確認せず実行)
-
同じタスクが承認ダイアログなしで実行されます。Manifold の評価は CVSS 9.6(Critical)に上がります。
つまり、承認ダイアログが唯一の防波堤として機能している状態が ask before acting モードであり、その防波堤を自ら外した状態が Act without asking モードです。この違いが、後述する対策で「Act without asking の無効化」を最優先に挙げる理由になります。
エンジニアが想定すべき具体的リスク
ここからは、報道では触れられにくい、インフラ・セキュリティエンジニアの業務環境に即した具体的なリスクを整理します。「9 個の固定タスクに限られる」という制約があっても、Google サービス系の 3 タスクだけで実務上の被害につながり得ることを、シナリオとして示します。
インフラエンジニアの受信トレイは攻撃者にとって高価値
エンジニアの受信トレイには、攻撃の起点になり得る情報が集中します。読み取り対象が Gmail であることの実害は、一般利用者の想定より大きくなりがちです。具体的には、次のような情報が含まれます。
- ベンダーサポートとのやりとり(サポートケース番号、対応中の障害内容、機器の設定に関する助言)
- 機器のライセンスキー・シリアル番号・保守契約に関する通知
- 監視・アラートメール(対象ホスト名、IP アドレス、検知内容など内部構成が推測できる情報)
- 各種サービスのパスワードリセット通知・多要素認証のコード
とりわけパスワードリセット通知や認証コードが読み取られる場合、単なる情報漏えいにとどまらず、他サービスのアカウント乗っ取りの足がかりになり得ます。受信トレイは「本人であることの証明」に使われる経路でもあるため、読み取りの影響は横方向に広がりやすい点に注意が必要です。
Google ドキュメント・カレンダー経由で漏れる設計情報
usecase-gdocs は「最新のドキュメントとそのコメント」を読み取ります。エンジニアが Google ドキュメントで管理しがちな構成設計書、手順書、レビュー中の設定変更メモなどが対象になれば、ネットワーク構成やセキュリティ設計の内部情報が外部に渡る可能性があります。コメント欄に残した補足情報まで含まれる点も見落とせません。
カレンダー(usecase-calendar)も同様です。メンテナンス作業の予定、参加者、会議のタイトルや説明には、作業対象システムや関係者、作業時間帯といった情報が含まれることがあります。これらは単体では些細に見えても、攻撃の計画段階では有用な偵察情報になります。


組織アカウント・共有ドキュメントへの波及
業務で Google Workspace を利用している場合、読み取り対象は個人のデータにとどまりません。共有ドキュメントや組織内で共有されたカレンダーにアクセス権があれば、それらも読み取りの対象範囲に入ります。個人の設定ミスが、チームや組織の情報にまで影響し得るという点で、これは個人利用よりも組織利用でこそ深刻に受け止めるべきリスクです。
同様に、Salesforce にログインしている環境では、顧客情報や商談情報が固定タスクの操作対象になり得ます。営業支援システムを扱う部門と、AI ブラウザ拡張機能を試用するエンジニア部門が同じ端末・同じブラウザを共有しているような環境では、想定外の範囲まで影響が及ぶ可能性があります。
パッチ提供前に実施できる対策
現時点で根本的な修正パッチは提供されていないため、以下は「脆弱性を消す対策」ではなく「悪用の成立条件を減らし、被害範囲を抑える緩和策」です。優先度の高い順に整理します。なお、Manifold の指摘によれば、後述するモード変更を行っても偽装クリックそのものを止められるわけではない点は、あらかじめ理解しておく必要があります。
「Act without asking」を無効化する
最優先は、動作モードを「Ask before acting(実行前に確認)」に戻すことです。「Act without asking(確認せず実行)」モードでは偽装されたタスクが承認なしで実行され得るのに対し、「Ask before acting」では実際の読み取りの前に承認ダイアログが残ります。この承認ステップが、偽装クリックに対する当面の防波堤になります。
モードは、拡張機能のサイドパネル(または Claude Desktop)のチャット入力欄にあるドロップダウンメニューから切り替えられます。公式のパーミッションガイドでは、それぞれのモードが次のように説明されています。
参考: Claude Help Center(Claude in Chrome permissions guide)
“Act without asking: Claude runs on its own and pauses to ask if anything looks unsafe.”
(確認せず実行: Claude は自律的に動作し、危険に見える場合のみ確認のため一時停止する。)
https://support.claude.com/en/articles/12902446-claude-in-chrome-permissions-guide
ただし、「Ask before acting」に戻しても偽装クリック自体は成立し、承認ダイアログを利用者がクリックすれば読み取りは実行されます。したがって、モードを戻したうえで、想定していないタスクの承認ダイアログが表示された場合は安易に承認しないことが重要です。あわせて、拡張機能の設定(拡張機能アイコン → サイドパネル右上の三点メニュー → 「Settings」→「Permissions」)から、「Always allow」を付与済みのサイトを確認し、不要なものは取り消しておくことをおすすめします。個別のアクションごとに承認する「Allow this action」が最も安全な運用とされています。
claude.ai にアクセスできる拡張機能を棚卸しする
偽装クリックの起点は、claude.ai の DOM にスクリプトを実行できる別の拡張機能です。そのため、そうした権限を持つ拡張機能を洗い出し、不要なものを削減することが有効な緩和策になります。
chrome://extensionsを開き、導入済みの拡張機能を一覧で確認する。- 各拡張機能の「詳細」→「サイトへのアクセス」を確認し、
claude.ai(および全サイト)へのアクセス権を持つものを把握する。 - 業務上必要のない拡張機能、提供元が不明確な拡張機能は削除する。
- 残すものについては、可能な範囲でサイトへのアクセスを「クリック時のみ」に絞り、常時アクセスを避ける。
心当たりのない拡張機能や、導入経緯を思い出せない拡張機能ほど、意図しない挙動の起点になりやすいため、この機会に見直すことをおすすめします。
組織での対応(Chrome Enterprise ポリシーと管理者コントロール)
個人の設定見直しに加えて、組織単位では次の 2 系統の管理策を組み合わせられます。個人利用よりも組織利用でこそ影響が大きいことは前述のとおりで、管理者側の対応が緩和の要になります。
- Chrome Enterprise(Google Admin console)側の拡張機能管理
-
Google 管理コンソールの「デバイス > Chrome > アプリと拡張機能」から、拡張機能の導入を統制できます。関連するポリシーには次のものがあります。
ExtensionInstallBlocklist: 特定の拡張機能のインストールを禁止する(*を指定すると既定で全拡張機能をブロック)。ExtensionInstallAllowlist: ブロックリストの対象から除外し、導入を許可する拡張機能を指定する。ExtensionInstallForcelist: 指定した拡張機能を強制導入する。
「全拡張機能をブロックし、許可リストで明示したものだけを導入可能にする」という許可リスト方式を基本にすると、claude.ai にアクセスできる拡張機能の併存を組織的に統制できます。また、管理コンソールの「アプリと拡張機能の使用状況レポート」(デバイス > Chrome > レポート)で、現在導入されている拡張機能とその利用状況を棚卸しできます。導入済み拡張機能の権限やリスクを把握したうえで、ブロック・許可の方針を決めることをおすすめします。
- Claude in Chrome 側の管理者コントロール
-
Team・Enterprise プランでは、Claude in Chrome 自体を組織単位で統制できます。オーナーアカウントで「組織設定 > Claude in Chrome」にアクセスし、次の設定が可能です。
- 拡張機能そのものの有効・無効を組織全体で切り替える(Enterprise プランでは既定で無効)。
- 許可リスト(Allowlist)/ブロックリスト(Blocklist)で、Claude がアクセスできるサイトを制限する。
公式ドキュメントでも、導入初期は制限的な許可リストから始め、挙動を確認しながら段階的に対象を広げる運用が推奨されています。
参考: SecurityWeek(ClaudeBleed の緩和策に関する記述)
“That update restricted which prompts an outside webpage could feed into Claude.”
(そのアップデートは、外部の Web ページが Claude に渡せるプロンプトを制限した。)
https://www.securityweek.com/unpatched-claude-for-chrome-flaw-lets-extensions-read-gmail-calendar/
AI ブラウザエージェントを業務利用する際の考え方
今回の脆弱性は、単一の実装ミスというより、「AI エージェントにブラウザの権限とログイン済みセッションを預ける」という利用形態そのものが持つ構造的なリスクを示しています。ログイン中のブラウザに操作能力を持つエージェントを置く以上、そのエージェントに到達できる別のコンポーネントは、エージェントが公開している機能を利用し得ます。
この構造は、正当な権限を持つプログラムが誤った依頼者のために動作してしまう「confused deputy 問題」として知られており、Manifold も今回の攻撃を、OWASP Top 10 for LLM Applications における間接的プロンプトインジェクションと過剰なエージェンシー(excessive agency)に対応づけています。プロンプト層だけを監視しても、エージェントが認識する環境そのものを操作される攻撃は捉えきれない、という指摘は、AI エージェントを業務に組み込む際の設計原則として押さえておく価値があります。
実務上の示唆は、「承認モード」や「アクセスできるサイトの範囲」を、利便性の設定ではなくセキュリティ境界として扱うことです。どのモードで動かすか、どのサイトにアクセスを許すか、どの端末・ブラウザプロファイルで試用するかは、いずれも信頼境界の設計判断として位置づけるのが妥当です。とりわけ機微な情報を扱う端末では、AI ブラウザ拡張機能を高リスクの拡張機能として扱い、他の拡張機能と同じ扇面に置かない運用が考えられます。
なお、2026 年には ShadowPrompt・ClaudeBleed をはじめ、Claude for Chrome や Claude Desktop Extensions(MCP)で信頼境界に関わる事案が複数報告されています。これら一連の事案に共通する構造と、AI エージェント全般のセキュリティ設計については、関連記事『AI エージェントのセキュリティリスク|2026 年の事案に共通する構造と対策』で体系的に整理しています。confused deputy 問題や OWASP Top 10 for LLM Applications での位置づけを詳しく知りたい場合は、あわせて参照してください。
まとめ
Claude for Chrome に、2026 年 7 月時点で未修正の脆弱性が 2 件報告されています。悪意ある別の拡張機能が偽装クリックを起点に、利用者の承認なしで Gmail・Google ドキュメント・カレンダーの読み取りを引き起こし得るもので、パッチが提供されるまでは設定と運用による緩和が現実的な対応になります。
- 未修正の脆弱性は偽装クリックの受け入れと承認スキップの 2 件
- 成立の前提は Claude for Chrome と別拡張機能の併存
- 被害範囲はログイン中の Google・Salesforce に依存
- 深刻度は動作モードで CVSS 7.7 から 9.6 に変化
- 当面の最優先は「Act without asking」の無効化
- claude.ai へアクセスできる拡張機能の棚卸しが有効
- 組織では拡張機能ポリシーと管理者コントロールを併用
以上、最後までお読みいただきありがとうございました。


