Chrome CVE-2026-0628：Gemini WebView の脆弱性

CVE-2026-0628ではChrome拡張機能がDNR経由でGeminiの特権WebViewに影響できました。Chromeを143.0.7499.192以降に更新してください。^{[1], [3], [5]}

CVSS ベクトル

CVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:U/C:H/I:H/A:H^[3]

💡 わかりやすい解説 (ELI5)

Gemini Liveを、公共図書館の利用者向け窓口と、その奥にある職員専用の扉にたとえてください。Chromeは拡張機能がその扉を通るのを防いでいましたが、配送経路を変えるルールによってGeminiの窓口で読み込むスクリプトを差し替えられました。スクリプトはこの埋め込み窓口で実行され、そこにはブラウザー機能を要求するための職員用通路がありました。CVE-2026-0628では配送経路の確認が欠けていました。^{[2], [5]}

主要な概念と専門用語

特権WebView: ブラウザー管理の画面に埋め込まれ、通常のWebサイトには許可されない機能と通信できるページ。^{[2], [5]}
declarativeNetRequest (DNR): 一致するネットワークリクエストに宣言型ルールを適用するChrome拡張API。リダイレクトやレスポンスヘッダー変更などを行う。^{[2], [6]}
CVE-2026-0628: Googleが高重大度としたChromeの脆弱性。Chrome 143.0.7499.192より前ではWebViewタグのポリシー適用が不十分だった。^{[3], [4]}
BragJack / prompt forcing: 拡張機能によるブラウザーAIエージェントの制御を扱う2026年9月の研究報告。研究上の名称であり、別のChrome CVEではない。^{[2], [4]}

フレームワーク対応

このガイドで説明する弱点の CWE 参照： CWE-862

根本原因の分析 (Root Cause)

GoogleはCVE-2026-0628を、ChromeのWebViewタグにおけるポリシー適用不足と説明しています。Forever Securityの技術報告によると、Gemini Liveはブラウザー管理のchrome://glicページを使い、WebView内にgemini.google.comを埋め込んでいました。Chromiumは特権ページ自体への拡張機能の干渉を拒否していましたが、報告された欠陥により、declarativeNetRequest (DNR) を持つ拡張機能が埋め込みページの一致するHTTPSリクエストに影響できました。研究者はレスポンスヘッダーを変更し、スクリプトを差し替えて、埋め込みGemini origin内でコードを実行しブラウザーエージェントのブリッジと通信する手順を説明しています。これにより通常の拡張権限と特権パネル機能との境界を越えられる可能性がありました。報告ではページコンテキスト、ローカルファイル内容、スクリーンショットへのアクセスを実証し、カメラ／マイクへのアクセス可能性も述べています。これは研究者が報告した影響であり、実環境での悪用を示す証拠ではありません。このCVEではユーザーが悪意ある拡張機能をインストールする必要があります。GoogleはWindows/macOS向け143.0.7499.192/.193、Linux向け.192でWebView境界を修正しました。公開されたChromiumの修正で境界が確認できます。request.is_web_viewがtrueの場合、RulesetManagerは既存の許可判定より前にfalseを返します。ChromiumはChromeSignInWebViewTest.DeclarativeNetRequestRulesNotMatchedを追加しましたが、テストはMPArchをスキップするため、この回帰テストはその構成を対象にしていません。^{[3], [2], [5], [4]}

ステップ・バイ・ステップの攻撃フロー

ステップ 1

前提条件を確認

報告されたChrome経路には、影響を受けるビルドと、DNRおよび一致するホスト権限を持つ悪意ある、または侵害された拡張機能のインストールが必要です。Webページを開くだけで成立する攻撃ではありません。^{[3], [2], [6]}

ステップ 2

ブラウザー管理のエージェント画面を開く

Gemini Liveはブラウザーのchrome://glicページを使い、WebView内にGemini Webアプリを埋め込みます。このページは通常のWebサイトにはない機能を呼び出せます。^[2]

ステップ 3

WebViewのリクエスト境界を越える

研究者によると、特権画面への干渉が制限されていても、DNRルールは埋め込みWebView内で読み込まれるHTTPSリソースに影響できました。^{[2], [5]}

ステップ 4

特権ページの動作に到達

レスポンス方針とGemini originで読み込まれるコードを変更し、実証された連鎖はブラウザーエージェントのブリッジと通信できました。研究者はローカルファイルやスクリーンショットへのアクセスを報告していますが、実悪用の公開証拠はありません。^{[2], [3]}

ステップ 5

修正を適用し拡張機能の露出を抑える

Googleの修正はプラットフォーム別にChrome 143.0.7499.192/.193へ含まれました。現在の安定版へ更新し、広いホスト権限やDNR権限を持つ拡張機能を制限してください。^{[1], [3], [5]}

ソースコード比較：脆弱 vs 堅牢化

これは攻撃コードの再現ではなく、Chromium上流のC++変更です。既存の許可判定より前にWebView由来のリクエストを拒否し、Declarative Net Requestルールが適用されないようにします。ChromiumはChromeSignInWebViewTest.DeclarativeNetRequestRulesNotMatchedも追加しましたが、このブラウザーテストはMPArchをスキップするため、その構成の網羅性は示しません。^[5]

脆弱な実装

// 抜粋: extensions/browser/api/declarative_net_request/ruleset_manager.cc
// 修正前、この最終判定では WebView 由来かどうかを確認していなかった。
return true;

堅牢化されたセキュアパッチ

// 抜粋: extensions/browser/api/declarative_net_request/ruleset_manager.cc
// 既存の最終許可処理の前に入る Chromium の変更 9722f06a:
// Declarative Net Request のルールを
// WebView からのリクエストに適用してはならない。
if (request.is_web_view) {
  return false;
}
return true;

エンジニアリング＆システム堅牢化チェックリスト

✓管理対象のすべてのChromeチャネルとOSを現在の安定版に更新してください。Googleが示す最初の修正版は143.0.7499.192/.193です。^{[1], [3]}
✓declarativeNetRequestと広いホスト権限を持つ拡張機能を棚卸しし、未承認または未使用のものを削除して、管理された許可リストを使ってください。^{[6], [2]}
✓特権ブラウザーページが他のoriginを埋め込む場合、URLだけで分離が十分だと判断せず、埋め込みリクエスト全体に拡張ポリシーを適用してください。^{[2], [5]}
✓拡張機能のリダイレクトやヘッダー変更がブラウザー特権WebView内のリソースに作用しないことを確認するブラウザーテストを追加してください。^[5]
✓ブラウザーエージェント連携の多層防御策として、特権操作はオリジンに結び付いたブラウザーインターフェースの背後に置き、各操作でメッセージの送信元、frameの識別情報、要求の種類、ユーザー同意の状態を検証してください。^[2]
✓このCVEと後発のBragJack研究を区別してください。他ブラウザーでの広範な発見は、それらが同じCVEを持つことを意味しません。^{[2], [4]}