CVE-2026-85046 Chrome ゼロデイ｜修正版と確認手順

はじめに

Google は 2026 年 9 月 3 日、デスクトップ版 Chrome の Stable チャンネルを更新し、12 件のセキュリティ修正を公開しました。このうち V8 の Type Confusion である CVE-2026-85046 について、Google は実環境に exploit が存在することを確認したと明記しています。CISA は翌 9 月 4 日に本脆弱性を Known Exploited Vulnerabilities（KEV）カタログへ追加しました。

Chrome は自動更新が既定で有効なため、多くの端末では放置していても最終的には修正版へ移行します。ただし段階的なロールアウトが前提であること、更新ファイルの適用後に Chrome を再起動しないと修正版が稼働しないことから、実悪用が確認されている状況では手動での確認と再起動が現実的な選択肢になります。

結論から示します。対応は「152.0.7977.82 以降へ更新し、Chrome を再起動したうえで、バージョンを再表示して修正版が稼働していることを確認する」までを 1 セットとして実施することを推奨します。更新ファイルがダウンロード済みという状態は完了条件になりません。また、Edge や Brave などの Chromium 系ブラウザーは Chrome とバージョン体系が異なるため、152.0.7977.82 という数字を判定基準として流用せず、各ベンダーのリリース情報で個別に確認する必要があります。

CVE-2026-85046 の概要と実悪用状況

本脆弱性は Chrome の JavaScript／WebAssembly エンジンである V8 に存在する Type Confusion です。細工された HTML ページを開くことで、Chrome のサンドボックス内で任意コードを実行される可能性があります。

V8 と Type Confusion の関係

V8

Chrome および Chromium が JavaScript と WebAssembly を実行するために使用するエンジンです。Web ページを開いた時点で、そのページが持つスクリプトが V8 上で処理されます。

Type Confusion（CWE-843）

あるメモリー領域を、実際に格納されている型とは異なる型として扱ってしまう不具合です。CVE Record は本脆弱性の CWE を CWE-843 として登録しています。

サンドボックス

Web コンテンツを処理するプロセスの権限を制限し、OS 側への影響を封じ込める仕組みです。CVE Record は本脆弱性で到達し得る範囲をサンドボックス内と記載しています。

想定される影響の範囲

CVE Record が示す影響は、細工された HTML ページを経由してサンドボックス内で任意コードを実行される可能性です。

参考: CVE Record（CVE-2026-85046）
“allowed a remote attacker to execute arbitrary code inside the sandbox”
（リモートの攻撃者がサンドボックス内で任意のコードを実行することを許していた）
https://www.cve.org/CVERecord?id=CVE-2026-85046

この記載の範囲では、CVE-2026-85046 単独で端末や OS 全体を掌握できると断定することはできません。ホスト側へ影響を広げるには、サンドボックス回避や権限昇格といった別の脆弱性との組み合わせが必要になる可能性があります。一方で、サンドボックス内での任意コード実行であっても、ブラウザー処理の改ざんや後続の攻撃の足掛かりになり得るため、影響が軽微であることを意味しません。ただし、実際に取得できる情報の範囲や、サンドボックス回避との組み合わせが成立するかどうかは、公開情報から確認できません。

Google が確認したことと、公開していないこと

Google がリリース記事で述べているのは、実環境に exploit が存在するという事実のみです。

参考: Stable Channel Update for Desktop（Chrome Releases）
“Google is aware that an exploit for CVE-2026-85046 exists in the wild.”
（Google は CVE-2026-85046 の exploit が実環境に存在することを把握しています）
https://chromereleases.googleblog.com/2026/09/stable-channel-update-for-desktop_01882797386.html

攻撃者の属性、標的、攻撃件数、感染経路、悪用コードの詳細は公開されていません。Google は同じ記事で、多くのユーザーへ修正が行き渡るまで不具合の詳細やリンクへのアクセスを制限する場合があると説明しており、実際に本件の Chromium Issue も執筆時点で参照が制限されています。第三者メディアの解説には攻撃手法の推測が含まれることがありますが、それらを Google が公表した攻撃事例として扱わないよう注意が必要です。

なお、Google は修正版の公開時点で、exploit が実環境に存在すると公表しています。この状況から本件は一般にゼロデイ脆弱性として扱われていますが、悪用が始まった時期や、修正版の公開前にどの程度の攻撃があったかは明らかにされていません。現在は修正版が提供されているため、未修正の脆弱性ではありません。

情報源ごとの評価の違い

本件では、重大度や評価の提供主体が分かれています。特に CVSS 8.8 を NVD 自身のスコアと誤解しないよう、提供主体を分けて把握しておくことを推奨します。

CISA-ADP が付与した CVSS v3.1 のベクターは CVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:U/C:H/I:H/A:H です。UI:R は悪用に利用者の操作が必要であるという評価で、細工されたページを開かせる必要があるという CVE Record の説明と整合します。

一方の S:U は、影響が同じセキュリティスコープ内にとどまるという CVSS 上の評価です。

参考: CVSS v3.1 Specification Document（FIRST）
“An exploited vulnerability can only affect resources managed by the same security authority.”
（悪用された脆弱性は、同じセキュリティ権限が管理するリソースにのみ影響し得ます）
https://www.first.org/cvss/v3.1/specification-document

サンドボックス内でのコード実行という影響範囲は、S:U から推定するのではなく、CVE Record の記述を根拠として扱います。

公開から KEV 追加までの時系列

影響を受ける Chrome と Chromium 系ブラウザーの範囲

「Chromium の脆弱性だから Edge も Chrome と同じバージョンへ上げればよい」という判断は成立しません。Chromium 由来のコードを共有していても、製品ごとにバージョン体系とリリース日が異なるためです。ここでは、執筆時点で一次情報から確認できる範囲と、確認できていない範囲を分けて整理します。

Edge を Chrome のバージョン番号で判定できない理由

Edge のセキュリティ更新のリリースノートでは、執筆時点の最新エントリーが 2026 年 9 月 2 日の Microsoft Edge Stable 152.0.4191.62 です。これは Chrome の修正版が公開された 9 月 3 日より前の日付であり、この時点で Microsoft が CVE-2026-85046 を修正対象として掲載しているとは確認できません。

また、同じメジャーバージョン 152 であっても、Chrome は 152.0.7977.82、Edge は 152.0.4191.62 と第 3 オクテット以降がまったく異なります。Chrome の 152.0.7977.82 を Edge の判定基準に使うと、正しく比較できません。Edge については Microsoft のリリースノートを、Brave・Opera・Vivaldi については各ベンダーのリリース情報を、それぞれ個別に確認することを推奨します。

CISA KEV のエントリー説明は、Chromium を利用する複数のブラウザーが影響を受け得ると述べています。これは注意喚起であり、各製品の修正版を示すものではありません。製品ごとの対応版は、必ずそのベンダーの情報で確認してください。

Android 版をどこまで修正済みとみなせるか

Android 版の Chrome 152（152.0.7977.82）はデスクトップ版と同日に公開されています。このリリース記事自体に CVE-2026-85046 の記載はありませんが、Android のリリースは特記がない限り対応するデスクトップ版と同じセキュリティ修正を含むと Google が明記し、今回のデスクトップ版リリース記事へリンクしています。この記述を根拠とする限り、Android 版 152.0.7977.82 は本脆弱性の修正を含むと読めます。バージョン番号が同じであることのみを根拠にしているわけではない点が判断の分かれ目です。

Chrome のバージョン確認と更新手順

個人端末や少数の端末では、GUI から確認と更新を完結できます。ここでの完了条件は、更新ファイルのダウンロードではなく、再起動後に修正版が稼働している状態です。

CVE Record が影響ありとしているのは 152.0.7977.82 より前のバージョンです。したがって、判定の境界としては 152.0.7977.82 以降であるかどうかを見れば十分です。

Google の公式ヘルプは、更新が不要な状態の見分け方を次のように説明しています。

参考: Update Google Chrome（Google Chrome ヘルプ）
“If you can’t find the “Relaunch” option, you’re on the latest version.”
（「再起動」の選択肢が見つからない場合は、最新バージョンを使用しています）
https://support.google.com/chrome/answer/95414?co=GENIE.Platform%3DDesktop&hl=ja

段階的ロールアウト中でも手動で確認する意味

Google はリリース記事で、今回の更新が数日から数週間かけて展開されると記載しています。自動更新に任せた場合、端末によっては修正版が届くまで日数が空くことになります。実悪用が確認されている脆弱性では、この待ち時間がそのまま脆弱な期間になります。

「Google Chrome について」を開くと、その場でオンデマンドの更新確認が行われます。ただし、段階的な配信の状況によっては、修正版を直ちに取得できない場合があります。画面に最新版と表示されても、バージョンが 152.0.7977.82 未満であれば対応完了とは判断しません。その場合は、次に示す Google 公式のトラブルシューティングや、組織で利用している通常のソフトウェア配布手段による適用を検討します。

更新に失敗する場合

更新が完了しない、エラーが表示されるといった場合は、Google 公式のトラブルシューティングを参照することを推奨します。原因が組織のポリシーによる更新停止である場合もあるため、管理端末では管理者への確認も必要になります。

Chrome の更新に関する問題を解決する（Google Chrome ヘルプ）

すぐに更新できない端末が残る場合は、限定的なリスク低減として、信頼できない Web コンテンツへのアクセスを制限する、当該端末での Web ブラウジングを一時的に停止するといった運用上の措置が考えられます。JavaScript の全面無効化は業務影響が大きく、対応状況を確認していない別の Chromium 系ブラウザーへの切り替えは同じ脆弱性を抱えたままになる可能性があるため、確実な回避策としては扱えません。

組織で管理する Chrome の対応手順

組織の端末管理者にとって難しいのは、更新の指示を出すことではなく、更新が完了していない端末を最後まで追い切ることです。ここでは、特定の資産管理製品を前提としない形で、影響確認から対応記録までの流れを整理します。

再起動が完了条件になる根拠

Chrome Enterprise の管理ドキュメントは、更新が端末へ適用された後に何が必要かを明記しています。

参考: Manage Chrome updates（Chrome Enterprise and Education Help）
“users need to restart Chrome browser for it to take effect”
（更新を有効にするには、利用者が Chrome ブラウザーを再起動する必要があります）
https://support.google.com/chrome/a/answer/9838774?hl=ja

更新の配布と適用完了の間に、利用者の再起動という工程が挟まる構造になっています。インストール済みバージョンの更新と、Chrome の再起動の両方を完了条件とします。ソフトウェアインベントリーがインストール済みファイルだけを確認する仕組みの場合、その結果だけでは稼働中のプロセスが修正版へ切り替わったことを証明できません。

ポリシーの適用状況を確認する

更新が進まない端末では、ポリシーによって自動更新が抑止されていないかを確認します。Chrome 側では chrome://policy で適用中のポリシーと Status を確認できます。Windows の Google Update については、ログファイルが次の場所に出力されます。

C:\Program Files (x86)\Google\GoogleUpdater\updater.log
%LOCALAPPDATA%\Google\GoogleUpdater\updater.log

上がシステム全体へインストールした場合、下がユーザー単位でインストールした場合のパスです。Google Update の更新確認はおよそ 5 時間ごとに行われるため、ポリシーを変更した直後に結果を確認できるとは限りません。なお、Windows でグループポリシーから Google Update のコンピューターポリシーを適用する場合は、Windows または Microsoft Entra ID のドメイン参加、もしくは MDM 管理が前提になります。ここで触れた設定内容は Chrome の更新を管理する（Windows） に記載があります。Chrome のグループポリシー設定そのものについては、関連記事『Chrome のグループポリシー設定｜ADMX 追加とパスワード保存制限の手順』で ADMX の配置から適用確認までを扱っています。

バージョン固定や自動更新の停止を設定したまま運用している環境では、今回のような実悪用のある脆弱性でも修正版が届きません。棚卸しの機会に、固定を解除できる端末がないかを併せて確認しておくと、次回以降の対応時間を短縮できます。

KEV 掲載後の優先度と更新後の確認

CISA が KEV へ追加したことで、本脆弱性は「実環境での悪用について信頼できる証拠がある」と第三者機関が判断した状態になりました。KEV エントリーの内容は次のとおりです。

参考: Known Exploited Vulnerabilities Catalog（CISA）
“Stakeholders are responsible for evaluating each asset’s internet exposure”
（関係者は、各資産のインターネットへの露出状況を評価する責任を負います）
https://www.cisa.gov/known-exploited-vulnerabilities-catalog

Due Date が適用される範囲

KEV の Due Date は米国連邦文民行政機関（FCEB）に適用される期限であり、日本国内の一般企業へ直接課される期限ではありません。日本の組織にとっては、対応の優先度を判断するための参照情報という位置づけになります。

今回の Due Date は追加日から 14 日後です。Vulnrichment が記録した SSVC の値は Exploitation: active、Automatable: no、Technical Impact: total であり、KEV エントリーではフォレンジック調査の要否が No とされています。この組み合わせは、BOD 26-04 が定める区分のうち 14 日の階層と整合します。ここは編集上の読み取りであり、CISA が個別の該当行を明示しているわけではありません。BOD 26-04 の 4 変数と期限の対応関係は、関連記事『BOD 26-04 とは｜KEV と外部公開で決まる対応期限の読み方』で整理しています。

CVE-2026-85046 は、端末へ外部から直接接続する攻撃ではなく、利用者が外部の Web コンテンツを開くことで成立するクライアント型の脆弱性です。そのため、自組織での優先度は、Chrome を標準ブラウザーとして利用している端末数、外部サイトやメール内リンクを開く頻度、利用者の権限、端末で扱う情報の重要性、更新と再起動を完了できるまでの時間を軸に判断します。全社の標準ブラウザーが Chrome である場合、対象台数がそのまま全端末数になるため、期限そのものより配布と再起動の完了に要する日数のほうが制約になりやすい点も考慮に入れておくとよいでしょう。

脆弱な期間があった端末をどう扱うか

Google が修正版の公開時点ですでに実環境の exploit を確認していたため、更新前の端末には脆弱な状態で Web を閲覧していた期間が存在します。ここで注意したいのは、公開情報から判断できることと、できないことの線引きです。

Google は本件について、攻撃者、標的、攻撃経路を公開していません。執筆時点で、CVE-2026-85046 に固有の IoC（Indicator of Compromise）は公開されていません。したがって、「この通信先への接続があれば本脆弱性で侵害された」といった形の判定はできません。

EDR のアラート確認、ブラウザープロセスの異常終了やクラッシュレポートの確認、Chrome の子プロセスから予期しないプロセスが起動していないかの確認といった一般的な監視項目は、通常の運用として有効です。ただしこれらは本脆弱性に固有の検知方法ではないため、レポートや報告書で「CVE-2026-85046 の検知手法」として記載しないよう区別することを推奨します。

実務上の落としどころとしては、更新完了までの脆弱な期間を記録として残しておき、その期間に該当端末で発生した既存のアラートを事後に確認する、という進め方が現実的です。新たに本件固有の情報が公開された場合に、遡って確認できる状態を作っておくことに意味があります。

まとめ

CVE-2026-85046 は、Google が実環境の exploit を確認した V8 の Type Confusion であり、修正版はすでに提供されています。対応そのものは Chrome の更新で完結しますが、完了判定を「配布済み」ではなく「再起動後に修正版が稼働している」に置けるかどうかで、実際に残るリスクが変わります。

また、Chromium 由来という共通点だけで他ブラウザーの対応状況を推定しないことも、この種の脆弱性では毎回問われる判断です。

• Chrome は 152.0.7977.82 以降が修正版
• 更新後の再起動まで終えて初めて修正が有効になる
• 影響は CVE Record の記載ではサンドボックス内にとどまる
• CVSS 8.8 は CISA-ADP による評価で NVD 独自の値ではない
• Edge や Brave は Chrome のバージョン番号で判定できない
• KEV の Due Date は米国連邦機関向けで日本企業には参照情報
• 本件固有の IoC は未公開のため一般的な監視項目と区別する

以上、最後までお読みいただきありがとうございました。