お問い合わせ
AIセキュリティ

AIが6日で作ったChromeフルチェーン – 防御の鍵は修正の反映速度

·

何が起きたのか

自律型オフェンシブセキュリティ企業のXBOWは、2026年10月13日（米国現地時間）、Chromeのフルチェーン攻撃コードを作った経緯を公式ブログで公開しました。韓国ではデジタルデイリーが10月14日にこのニュースを報じています。

フルチェーンとは、複数の脆弱性をつなぎ合わせてブラウザの保護レイヤーをすべて突破する攻撃です。今回のチェーンは1つのWebページから始まり、Windows端末のサンドボックス外で任意のプログラムを実行しました。ユーザーがファイルをダウンロードしたりリンクをクリックしたりする必要はなく、ページを開くだけで足りた点が要点です。

項目内容
発表2026年10月13日（米国現地時間）、XBOW
作成期間2026年8月2日〜8月7日、6日
参加XBOWの研究者1名 + OpenAIの公開モデルで動くAIエージェント
費用約4万ドル（XBOWが利用記録から推計したAPI費用）
報奨金GoogleのChrome脆弱性報奨金プログラム（VRP）フルチェーン報奨金25万ドル
対象Windows版Chrome。XBOWは影響ユーザーを約10億人と推計
現在の状況3件の欠陥はすべて修正済み。実際の攻撃に使われた事例は報告なし

XBOWによれば、今回の報奨金は、Googleが2026年4月に改定したVRP規定のもとで初めて支払われたChromeフルチェーン報奨金です。The Hacker Newsは、25万ドルがChrome VRPの単一の報告に対する最高額だと伝えています。

チェーンを構成した3つの欠陥と修正バージョン

Chromeは、JavaScriptエンジン内部のV8サンドボックスと、OSがレンダラープロセスの権限を制限するレンダラーのサンドボックスの2層でWebページのコードを閉じ込めています。今回のチェーンは、異なるコンポーネントにある3つの欠陥で両方の境界を突破しました。

段階コンポーネント識別子分類修正バージョン（Windows）
1V8（JavaScriptエンジン）CVE-2026-85045High、サンドボックス内でのコード実行（CVEの説明）152.0.7977.82/.83（9月3日）
2アニメーションWebP画像デコーダーCVEなし（Chromium issue 548509153）V8サンドボックス境界の回避（XBOWの説明）リリースノートに個別の記載なし
3Crashpad（Chromeのクラッシュハンドラー）CVE-2026-78952High、サンドボックス外でのコード実行（Windows、CVEの説明）152.0.7977.64/.65（8月25日）

情報源を読む際には、注意すべき点が2つあります。

  • CVE番号の表記の違い：XBOWの発表文とそれを引用した一部の報道は、CVE-2026-85045をWebPの段階として表記しました。Googleの9月3日のリリースノートとCVEの公式記録はこの番号をV8の欠陥に割り当てているため、確認作業は公式記録に従うのが正確です
  • 「悪用なし」という説明の出典：2つのリリースノートのどちらにも、XBOWが報告した欠陥が実際に悪用されたという記載はありません。実際の攻撃に使われていないという説明は、XBOWと報道に基づくものです

何が変わったのか – 時間と費用

この事例が注目される理由は、欠陥そのものよりも速度にあります。XBOWの研究者は、AI以前には4人で約6〜9か月かかっていたChromeフルチェーンの作成が、同社の最初の試みでは2か月、報奨金を受けた今回のチェーンでは6日になったと述べています。使われたモデルはセキュリティ専用モデルではなく、誰でも使える公開モデルでした。

XBOWは限界も明確にしています。対象の選定、文脈の提供、結果の検証、どのコンポーネントを組み合わせるかの判断は人が担い、同じ時間と費用があれば誰でもフルチェーンを作れるという意味ではないと説明しました。それでも、ハードルが大きく下がったという結論は変わりません。XBOWは、1年以内にエージェントが3つの欠陥をそれぞれ単独で見つけられるようになると予測しています。

観点変化企業にとっての意味
攻撃コードの作成数か月単位から数日単位へ（XBOWの事例による）修正の公開から攻撃コードの登場までの期間が短くなりうる
必要な人員専門チームから少数の研究者 + AIエージェントへ高度な攻撃能力がより多くの主体に広がりうる
欠陥の重複発見同じ欠陥を複数の主体が同時に見つける未公開の欠陥が長く秘密のまま残るという前提が弱まる
防御側同じツールで自社のコードを先に点検できる提供元の事前点検と修正反映の速度が差別化要素になる

Chrome 155セキュリティアップデートでも、AIの支援を受けて報告された脆弱性が複数ありました。脆弱性を見つける速度が上がるほど、修正をどれだけ早く端末まで反映できるかが企業セキュリティの変数になります。

企業の視点 – クリック不要の攻撃

「不審なリンクをクリックしない」という教育だけでは、この種の攻撃を十分には防げません。ページを開くだけで攻撃が始まるため、広告ネットワークや侵害された正規サイトを経由して攻撃ページに触れる可能性があります。ユーザー権限でサンドボックス外のコードが実行されると、マルウェアのインストール、認証情報の窃取、社内ネットワークでの横展開につながりえます。

業務サイトしか使わないユーザーも例外ではありません。1つのブラウザで業務システムと外部のWebを併用する環境では、外部ページへの1回の接触が業務端末全体のリスクになります。

企業が今確認すべきこと

確認項目基準方法
Chromeのバージョン最低152.0.7977.82（Windows・Macは.83を含む）。実務上は最新のStable資産管理ツールまたはchrome://version
再起動が完了していない端末アップデート後の再起動まで完了RelaunchNotification・RelaunchNotificationPeriodポリシーで再起動期限を設定
ほかのChromiumベースのブラウザ開発元の該当修正を反映したビルド開発元のセキュリティ情報とバージョン情報を確認
Chromiumを組み込んだ業務アプリElectronなどで作られた業務アプリのChromiumバージョン提供元のアップデート予定を確認
信頼度の低い外部サイトJavaScript JITの制限を検討DefaultJavaScriptJitSetting・JavaScriptJitBlockedForSitesポリシー。性能低下とWebAssemblyの制限が生じる可能性があるため、試験導入後に拡大
端末の不審な挙動の検知ブラウザプロセスによる通常と異なる子プロセスの起動EDRの検知ルールとセキュリティ監視アラートを点検

JITの制限は、Googleがブラウザをより安全な構成で動かす選択肢として提供しているポリシーですが、特定の欠陥を防ぐことを保証するものではありません。根本的な対策はアップデートです。

BrowZenの視点 – エンジンの欠陥はエンジンの修正で、データはポリシーで

BrowZenはChromiumベースの業務用ブラウザです。Chromiumエンジンの欠陥は同じコードを使うすべてのブラウザに共通する課題であり、BrowZenは次の対応方針で対応します。

段階内容
確認Googleのセキュリティ情報を毎日確認し、修正項目ごとにBrowZenへの反映状況を確認します
反映反映が必要な修正は修正版ビルドを準備し、導入企業の管理者に案内します
公開修正版ビルドの配布前は、影響の詳細を公開しません

セキュアブラウザがエンジンの脆弱性をなくすわけではありません。防御はレイヤーごとに役割を分ける必要があり、セキュアブラウザが担う部分は次のとおりです。

防御レイヤーこの種の攻撃に対する役割担当
ブラウザエンジンのセキュリティ修正欠陥そのものを取り除く根本的な対策ブラウザの提供元・企業のパッチ管理
OSのセキュリティ機能攻撃コストを上げるが、単独では防げないOS・端末管理
EDR・セキュリティ監視端末が乗っ取られた後の不審なプロセスと挙動を検知セキュリティ監視
ブラウザ内の業務ポリシー通常業務の中で貼り付け・アップロード・キャプチャによってデータが外へ出る経路を統制。端末が乗っ取られた後は効果が限られるセキュアブラウザ

そのため、業務用ブラウザを選ぶ際には、機能一覧と同じくらいエンジンのセキュリティ修正の反映基準と履歴を見る必要があります。導入を検討する場合は、提供元にChromiumセキュリティ修正の反映基準、反映履歴、顧客への案内方法を求めてください。業務用ブラウザを標準化すれば、バージョンと再起動を管理する対象も減らせます。

おわりに

今回の事例が示したのは、Chromeが弱いという事実ではありません。世界で最も堅牢に作り込まれたソフトウェアの1つであっても、AIの支援を受けた少人数が、事前の準備をもとに数日で最後まで突破できるようになったという事実です。攻撃コードを作る時間が短くなった分、防御は修正を端末まで反映する時間を短くする方向に進む必要があります。

BrowZenの機能と導入環境はBrowZen製品ページで、セキュアブラウザの基本概念はセキュアブラウザ(SEB)とは何かでご確認いただけます。

参考資料

公式情報と記録

発表と報道

よくある質問

今回のChromeフルチェーンは実際に悪用されましたか？

XBOWと報道によれば、実際の攻撃に使われた事例は確認されておらず、3件の欠陥はすべて修正されています。ただし、9月3日の同じセキュリティアップデートに含まれていた別のV8脆弱性CVE-2026-85046は、Googleが実際の悪用を確認し、米国CISAの既知の悪用された脆弱性カタログ（KEV）にも登録されました。このアップデートを先送りした端末は、両方のリスクにさらされます。

EdgeやWhaleなど、ほかのChromiumベースのブラウザも確認が必要ですか？

確認が必要です。V8とWebPデコーダーの欠陥はChromiumの共通コードにあり、Crashpadの欠陥はWindowsが対象です。各開発元が該当する修正を反映したビルドを配布したかを、セキュリティ情報とバージョン情報で確認してください。ElectronのようにChromiumを組み込んだ業務アプリも同じ確認の対象に含めてください。

セキュアブラウザを使えば、このような攻撃を防げますか？

ブラウザエンジンの欠陥を取り除く根本的な対策はエンジンのセキュリティ修正であり、Chromiumベースのセキュアブラウザも同じ修正を反映する必要があります。セキュアブラウザの役割は、修正の反映を提供元が責任を持って管理すること、そして通常業務の中でデータがブラウザの外へ出る経路をポリシーで統制することです。端末が乗っ取られた後の不審な挙動は、EDRなど端末側のセキュリティレイヤーが併せて担う必要があります。

あわせて読みたい