Chrome V8のゼロデイCVE-2026-85046。sortの最適化で入れ替わる要素種別と組織の更新の回し方

業務端末が一日のうちに実行する未信頼のコードは、そのほとんどが外部のWebサイトから届くJavaScriptです。V8はそれを速く動かすために実行時コンパイラを持ち、値の型を観測して「この配列は整数しか入っていない」といった前提を置いた機械語を出します。前提が実行中に崩れたとき、生成済みの機械語は崩れたことを知りません。CVE-2026-85046は、その崩れ方の一つです。

Googleは2026年9月3日、Chrome Stableを152.0.7977.82と.83へ更新し、12件のセキュリティ修正のひとつとしてV8の型混同CVE-2026-85046を挙げたうえで、この脆弱性の悪用が実際に存在することを把握していると記載しました。CISAは翌9月4日にKnown Exploited Vulnerabilities(KEV)カタログへ追加し、米国の連邦文民行政機関に対する是正期限を9月18日としています。

この記事は、ブラウザを管理する情報システム担当とWeb開発者に向けて、Chrome Releasesの告知、CVEレコード、NVD、CISAのKEVカタログ、V8の修正コミット、Chromiumの設計ドキュメントという一次情報をもとに、何が起きているのか、どの版まで上げるのか、なぜ更新が端末に届かないことがあるのかを整理します。攻撃を再現するコードは扱いません。検証を行う場合は自組織が管理する端末に限ってください。記述は執筆時点(2026年9月8日)に確認できた範囲に限ります。

一次資料で確定できる事実#

Chrome ReleasesのStable Channel Update for Desktop(2026年9月3日)は、12件のセキュリティ修正の先頭にこの脆弱性を挙げています。記載は「[$1,000][542403045] High CVE-2026-85046: Type confusion in V8. Reported by Salvatore Gulizia (nickname: Serotav) on 2026-08-04」で、報告日と報奨金の額まで書かれています。同じ告知の末尾に「Google is aware that an exploit for CVE-2026-85046 exists in the wild.」という1文があります。

主要な値を提供元とあわせて並べます。

CVEレコードのCNAコンテナには参照先としてChrome Releasesの告知とChromiumのissue 542403045が並びます。issueそのものは、Googleの方針により大半の利用者が更新を適用するまで閲覧が制限されることがあります。告知の冒頭にも、修正が第三者ライブラリに及ぶ場合を含めて制限を維持することがあると書かれています。

Chrome Releasesの2026年9月3日付「Stable Channel Update for Desktop」は、Stableチャネルを152.0.7977.82/.83(Windows/Mac)と152.0.7977.82(Linux)へ更新したこと、この更新に12件のセキュリティ修正が含まれることを記載しています。CVE-2026-85046はHighとして「Type confusion in V8」と記され、報告者はSalvatore Gulizia(nickname: Serotav)、報告日は2026-08-04、報奨金は1,000ドルです。同じ更新には、CrashReportingの領域外読み取り、Networkの不完全なクリーンアップ、Compositingの解放後使用、V8の競合状態、WebGLの領域外書き込みなどが含まれます。末尾には、CVE-2026-85046に対するエクスプロイトが実環境に存在することをGoogleが把握しているという記載があります。

影響を受ける版と修正版の対応#

CNAが記載した範囲とChrome Releasesの各告知を突き合わせると、次のとおりです。

同じ9月3日には、Early Stableチャネルのデスクトップが153.0.8010.27と.28へ更新されています。NVDが生成した照合条件は152.0.7977.82未満を対象範囲としているため、153系はこの範囲の外です。

版の確認で気をつける点が3つあります。

1つ目は、直前のStableとの見分けです。2026年9月1日にもStableの更新があり、そのときの版は152.0.7977.75と.76でした。数字が近いため、152.0.7977.7xで止まっている端末を「更新済み」と読み違えないようにします。判定は最終セグメントが82以上かどうかで行います。

2つ目は、ChromeOSです。Chrome Releasesで執筆時点に確認できるChromeOS Stableの最新告知は2026年9月2日のM-151(ブラウザ版151.0.7922.222)で、本件の修正を含むChromeOS Stableの告知は確認できていません。ChromeOS端末を業務で使っている場合は、管理コンソールでブラウザ版を確認し、配信を待つことになります。

3つ目は、iOS版のChromeです。Chromiumのドキュメントは、iOSではBlinkが使えず、WebKitが提供するWKWebViewをios/webがラップする構成だと説明しています。ページの描画とスクリプト実行がWKWebView側で行われるため、V8のこの問題がそのまま当てはまる構成ではありません。実際、今回の修正版の案内はデスクトップとAndroid向けに出ています。

V8が配列の中身をどう覚えているか#

型混同の中身に入る前に、前提を2つ押さえます。

ひとつは要素種別(elements kind)です。V8は配列の中身の種類を、配列そのものの構造情報であるマップに記録します。整数しか入っていない隙間のない配列はPACKED_SMI_ELEMENTS、オブジェクトへの参照を含む隙間のない配列はPACKED_ELEMENTSです。この2つは、バッキングストアがどちらもタグ付きスロットを並べたFixedArrayで、メモリ上の形が同じです。違うのは、スロットの中身を整数として読むか参照として読むかという解釈だけです。

もうひとつは値のタグ付けです。V8はスロットの下位ビットをタグに使い、小さな整数(Smi)とヒープオブジェクトへの参照を同じ幅の枠に収めています。ポインタ圧縮を使う64ビットビルドでは、いずれも32ビットに収まる表現になります。つまり、同じ32ビットの並びが、読み手の解釈次第で「整数」にも「ヒープ上の位置」にもなります。

要素種別は、より特殊なものからより一般的なものへ移るのが基本です。整数だけの配列にオブジェクトを入れればPACKED_ELEMENTSになりますが、逆方向へ勝手に戻ることは通常ありません。この一方向性が、コンパイラが置く前提の土台になっています。

sortのインライン最適化で要素種別が入れ替わる位置#

V8の最適化コンパイラは、Array.prototype.sortの呼び出し先を、条件がそろえば小さな挿入ソートとしてその場に展開します。組み込み関数とJavaScriptの境界を比較関数の呼び出しごとにまたぐ費用を避けるためです。展開されたコードは、おおよそ次の順で動きます。

1. 受け手のマップを検査する
2. 受け手の要素を一時的なFixedArrayへ複製する
3. 一時配列の上で挿入ソートを行い、比較関数を呼ぶ
4. 比較関数の副作用に備えて、受け手のマップと長さを再検査する
5. 一時配列の内容を受け手の要素へ書き戻す

問題は4番の再検査の意味です。ある呼び出し箇所が整数だけの配列とオブジェクトを含む配列の両方で訓練されていると、コンパイラは受け手として起こりうるマップの集合にPACKED_SMI_ELEMENTSとPACKED_ELEMENTSの両方を持ちます。修正前の再検査は「現在のマップがその集合のいずれかであること」しか確かめていなかったため、比較関数の中でマップが集合内の別の種別へ移っても検査を通過しました。

移す手段はArray.prototype.fillです。V8の組み込み実装には、全要素を置き換える場合には古い値が一つも残らないため、要素種別の連鎖をさかのぼる向きにマップを移し替えてよい、という分岐があります。バッキングストアの形が同じなので、確保し直しも起きません。結果として、比較関数の中で対象の配列を整数で埋めると、PACKED_ELEMENTSだった配列がPACKED_SMI_ELEMENTSに戻ります。

そのうえで5番の書き戻しが走ります。書き戻される中身は、一時配列に退避していたオブジェクトへの参照です。マップはPACKED_SMI_ELEMENTSなので、以後この配列は「整数しか入っていない配列」として扱われながら、実際には参照を保持した状態になります。

修正コミットの説明文は、この筋道をそのまま述べています。訳すと、受け手の要素種別を合流させるとポリモーフィックなフィードバックは個々の受け手が持たない種別を生む、反復系の組み込み関数は受け手を読むだけなので問題ないが、インライン展開されたsortは要素を退避して比較関数を実行し合流後の種別に特化した形で書き戻す、比較関数は生きている受け手を集合内の別の種別へ狭められる、という内容です。修正は、MaglevとTurbofanの両方で、インライン展開の前にすべての受け手のマップが同じ要素種別で一致することを要求します。単形の呼び出し箇所と、要素種別を共有するポリモーフィックな呼び出し箇所は影響を受けず、種別が混ざる箇所だけが汎用の組み込み関数へ落ちます。

V8の修正コミット e0562d87(2026年8月7日、Fixed: 542403045)は「[compiler] Don't inline Array.prototype.sort on mixed elements kinds」という表題で、src/compiler/js-call-reducer.cc(Turbofan)とsrc/maglev/maglev-graph-builder.cc(Maglev)、および回帰テストを変更しています。説明文には、{PACKED_SMI,PACKED}の合流がPACKED_ELEMENTSになること、比較関数がa.fill(0)によって受け手をPACKED_SMI_ELEMENTSへ狭められること、コールバック後の検査が元の集合に含まれるという理由でそのマップを受け入れてしまうこと、書き戻しによって退避していたHeapObjectがSmi要素の配列へ格納されること、そしてその配列をSmiとして扱う側は書き込みバリアなしにそれらを移動させることが書かれています。

型混同が任意の読み書きへ変わる筋道#

要素種別の取り違えは、それ単体ではクラッシュしません。効いてくるのは、そこから2つの基本操作が組み上がる点です。

ひとつは、オブジェクトの位置を数値として読み出す操作です。配列のマップがPACKED_SMI_ELEMENTSになっているため、マップを見て処理を選ぶ経路は中身をSmiとして読みます。参照のビット列が整数として観測できることになり、任意のオブジェクトがヒープ上のどこにあるかを知る手がかりになります。

もうひとつは、書き込みバリアの省略です。書き込みバリアは、ヒープ上の参照が書き換わったことをガベージコレクタへ知らせる記録処理です。整数しか入らない配列にはコレクタが追跡すべき参照がないという前提があるため、この記録が省かれます。前提が崩れた配列の上で要素をずらす操作を行うと、コレクタの知らない参照がヒープに残ります。修正コミットの説明にある「Smi consumers of the resulting array read those HeapObjects as Smis and move them without write barriers」は、この省略を指しています。

この2つがそろうと、V8のヒープ上で任意の位置を読み書きする状態に到達します。発見者が公開した解説も、位置の読み出しと参照の偽装を組み合わせてJavaScriptヒープ上の任意読み書きへ持ち込んだと述べており、さらにn-dayのサンドボックス脱出と連鎖させてv8CTFのフラグを取得したと書いています。v8CTFはGoogleが運営する制度で、Googleの用意した環境上で動くV8を攻略してフラグを持ち出し、有効な提出には1万ドルの報酬が支払われるというものです。実環境での攻撃とは別の枠組みで、Googleが公表した「エクスプロイトが実環境に存在する」という記述とv8CTFの提出とは別々の事実として扱う必要があります。

最適化コンパイラが攻撃面になり続ける理由#

この種のバグがV8で繰り返し見つかるのは偶然ではありません。V8チーム自身が、サンドボックスの解説記事で構造的な事情を説明しています。

同記事によれば、2021年から2023年までの3年間に実環境で捕捉されたChromeのエクスプロイトはすべて、レンダラプロセスのメモリ破壊から始まっており、そのうち60パーセントがV8の脆弱性でした。そしてV8の脆弱性は解放後使用や領域外アクセスのような古典的なメモリ破壊ではなく、結果としてメモリ破壊を引き起こす微妙な論理の誤りである、と述べられています。歴史的に、V8で見つかり悪用されたバグのおよそ半分はコンパイラのいずれかに関するものだったという記述もあります。

同記事はさらに、コンパイラ自体が攻撃面の一部である場合、メモリ安全性をコンパイラが保証することはできない、と書いています。今回の事例はこの説明にそのまま当てはまります。fillもsortも個別には正しく動いており、破綻したのは「この呼び出し箇所の受け手はこの種別である」という最適化の前提の置き方でした。メモリ安全な言語への置き換えやメモリタグ付けのような手法は、この形の誤りには効きません。

v8.devの「The V8 Sandbox」(2024年4月4日公開)は、2021年から2023年に実環境で捕捉されたChromeのエクスプロイトがすべてレンダラプロセスのメモリ破壊から始まり、そのうち60パーセントがV8の脆弱性だったと述べています。あわせて、V8の脆弱性が古典的なメモリ破壊ではなく2次的な論理の問題であること、V8で発見され悪用されたバグのおよそ半分がコンパイラに関するものだったこと、コンパイラが攻撃面の一部である以上メモリ安全性をコンパイラが保証できないことを説明しています。

サンドボックスの内側で何ができて何ができないのか#

CVEの記述にある「サンドボックス内で任意のコードを実行できた」という表現は、Chromeに2種類のサンドボックスがあるため読み方に注意がいります。

ひとつはV8サンドボックスです。V8のヒープをプロセスの他の領域から隔離する仕組みで、攻撃者がV8サンドボックスの内側では任意に読み書きできるという前提を置いたうえで、その外側へメモリ破壊が広がることを防ぐ設計です。ポインタや64ビットのサイズ値をサンドボックス基準のオフセットやテーブル経由の間接参照に置き換えることで実現しており、64ビット版のChromeでは既定で有効です。ただしV8チーム自身が、強固なセキュリティ境界になるまでに解決すべき課題がまだ複数あると書いています。この記事で扱った型混同は、V8ヒープの内側で完結する読み書きなので、V8サンドボックスの想定する攻撃者像そのものです。

もうひとつはレンダラプロセスのサンドボックスです。Chromiumはブローカとなるブラウザプロセスと、権限を落としたターゲットプロセスに分かれます。Windowsであれば、制限付きトークン、ジョブオブジェクト、代替デスクトップ、整合性レベルの4つを組み合わせて、レンダラがOSの資源へ直接触れないようにしています。設計ドキュメントは、ホストを侵害するにはサンドボックスからの脱出が別途必要だと述べています。CVEの記述が「サンドボックス内」で止まっているのは、この脆弱性だけでは端末の掌握まで届かないという意味です。

とはいえ、レンダラが制御されたときに失われるものはゼロではありません。Chromiumの脅威モデルは、能動的なWebコンテンツがそのプロセスのアドレス空間にあるあらゆるデータを読めると想定すべきだ、という前提を明記しています。サイト分離は、この前提のもとで別サイトのデータを同じプロセスに置かないための仕組みですが、分離の単位はオリジンではなくサイトです。同じサイトに属する内容は同居しうるため、そのサイトのセッションに関わるデータは影響範囲に入ります。攻撃者が狙うのが端末の掌握とは限らず、セッションの持ち出しで足りる場面があることは、別の記事で整理しています。

あわせて読みたい

情報窃取型マルウェアがセッションCookieを盗んで多要素認証を回避する仕組み

Chromiumのサンドボックス設計ドキュメントは、ブローカ(ブラウザプロセス)がポリシーを保持しターゲット(レンダラなど)を監督する2層構造を説明し、Windowsでは制限付きトークン、ジョブオブジェクト、代替デスクトップ、整合性レベルを組み合わせて権限を落とすと述べています。サンドボックス内のコードは悪意あるコードとみなすという前提を置いたうえで、ホストを侵害するにはサンドボックスからの脱出が必要であり、レンダラはブローカが明示的に渡した資源以外へ到達できないと記載しています。

CVSSとSSVCとKEVを読み分ける#

NVDのページに出る8.8という数字は、Googleが付けた値ではありません。NVDのCVSS v3.1のエントリはsourceが134c704f-9b21-4f2e-91b3-4a467353bcc0でtypeがSecondaryであり、これはCISAのADPであるVulnrichmentの識別子です。ChromeのCNAコンテナにはCVSSが入っていません。

ベクトルで目を引くのはUI:Rです。攻撃には利用者が細工されたページを開くという操作が要ります。この1点があるため、スコアは9.8ではなく8.8に収まっています。CISAのSSVCの判定も、Exploitation: active(悪用が起きている)、Automatable: no(攻撃工程を全自動化できない)、Technical Impact: total(悪用後は資産を完全に掌握される)となっており、Automatableがnoである理由はこの操作要求と整合します。

KEVの期限にも差が出ます。CVE-2026-85046の是正期限は追加日の14日後で、フォレンジックトリアージの要求は付いていません。同じKEVでも、公開資産にあり自動化可能な脆弱性は3日程度の期限になることがあります。BOD 26-04が期限を決める変数は、資産が公開されているか、KEVに載っているか、攻撃を自動化できるか、悪用後の技術的影響が完全な掌握かの4つで、今回はAutomatableがnoである分だけ区分がゆるくなっています。この期限が拘束するのは米国の連邦文民行政機関であり、日本の組織にとっては優先度を決める材料です。

EPSSは補助的に見ます。2026年9月7日時点の値は0.01162でパーセンタイルは0.65152でした。KEVに載っている脆弱性としては低く見えますが、EPSSは大規模に観測される悪用の試行を推定するモデルであり、標的を絞った攻撃はもともと数字に出にくい性質があります。スコアの使い分けは次の記事で整理しています。

あわせて読みたい

脆弱性対応の優先順位付け。CVSSだけに頼らないEPSSとCISA KEVの使い方

Chromium系ブラウザへの波及#

CISAのKEVエントリは、この脆弱性がGoogle Chrome、Microsoft Edge、Operaを含むChromium系の複数のブラウザに影響しうると明記しています。棚卸しの対象はChromeだけではありません。執筆時点で各社が公表している内容は次のとおりです。

Microsoftのリリースノートは、9月2日のEdge 152.0.4191.62について、Chromiumチームが報告したCVE-2026-85046に実環境のエクスプロイトが存在すること、この更新にその修正が含まれることを明記しています。派生ブラウザは自社のリリース周期でChromiumを取り込むため、Chromeを更新しただけでは端末上の他のChromium系ブラウザが古いまま残ります。

Chromiumを同梱するデスクトップアプリケーションも、同じエンジンのコードを持ちます。ただし影響の有無は、そのアプリが未信頼のWebコンテンツを読み込む経路を持つかどうかで変わります。各アプリの公式アナウンスと同梱Chromiumの版を個別に確認する扱いになります。

Microsoftの「Release notes for Microsoft Edge Security Updates」は、2026年9月2日の項でMicrosoft Edge Stable Channel(Version 152.0.4191.62)を公開したと記載し、「The Chromium team reported that CVE-2026-85046 has an exploit in the wild, and this update contains a fix for it.」と明記しています。9月4日にはVersion 152.0.4191.66が公開されています。

更新が端末に届かない条件#

修正版が出ていることと、端末に適用されていることは別です。届かない条件をChromiumのドキュメントから拾うと、次の4つになります。

1つ目は、更新チェックの間隔です。Chromiumのupdaterの仕様書によれば、更新プログラムは1時間ごとに定期処理を走らせ、更新チェックの基本周期は4.5時間です。定期処理が1時間刻みのため、実際の周期は時間単位に切り上がります。さらに、多数の端末が同時に起動したときにチェックが重ならないよう、10パーセントの確率で通常の120パーセントの周期が使われ、チェックの実行自体も最大1分の乱数で遅らされます。

2つ目は、ポリシーで背景更新が止められている場合です。同じ仕様書は、背景更新をポリシーで完全に無効化できると述べています。ここで注意がいるのは、これらのポリシーが尊重される条件です。仕様書は、ドメイン参加済みの端末、Chrome Enterprise Coreに登録された端末、macOSではMDMで管理された端末に限って更新プログラムのポリシーが有効だと明記しています。管理されていない端末に配ったレジストリ設定は効きません。

3つ目は、Linuxの配布経路です。GoogleのLinuxソフトウェアリポジトリのページが示すとおり、Linux版はaptやyumのリポジトリを通じて配布されます。ブラウザ自身が更新するのではなく、OSのパッケージ管理の仕組みに載るため、リポジトリの同期と適用の運用に依存します。

4つ目が、実務では最も引っかかる点です。ダウンロードが終わっても、ブラウザを再起動するまで新しいコードは動きません。ChromeのRelaunchNotificationポリシーの定義文は、この設定を入れない場合はメニューの見た目が控えめに変わることで再起動の必要を示す、と説明しています。RelaunchNotificationPeriodの既定値は604800000ミリ秒、つまり1週間です。通知期間の3分の1が経過するとメニューの表示が変わり、3分の2でその色が変わり、期間が満了するとさらに変わります。裏を返せば、既定のままでは、利用者がブラウザを閉じない限り1週間近く古いコードが動き続ける余地があります。

更新を確実に適用させるポリシー#

適用までの時間を縮める設定は、ChromeとEdgeで同じ名前のポリシーとして用意されています。定義文にある挙動は次のとおりです。

再起動を伴う設定は業務の中断を伴うため、恒久的にRequiredへ倒すかどうかは組織の判断になります。悪用が確認された脆弱性が出たときだけ通知期間を短くして適用を早め、落ち着いたら戻す運用であれば、影響を抑えつつ時間を縮められます。RelaunchNotificationとRelaunchNotificationPeriodはいずれも動的に反映される設定として定義されています。

なお、再起動の後は開いていたタブとウインドウが復元されると定義文に書かれています。利用者への説明ではこの点を先に伝えると、先送りされにくくなります。

ChromiumのRelaunchNotificationポリシー定義は、この設定を入れない場合はメニューの控えめな変化で再起動の必要を示すこと、Recommendedでは繰り返しの警告を出し利用者が先送りできること、Requiredでは通知期間の満了後に再起動が強制されることを示す警告を出すことを記載しています。既定の期間はChromeで7日、ChromeOSで4日で、RelaunchNotificationPeriodで変更できること、再起動後にセッションが復元されることも書かれています。

配信後の数日で回す手順#

版の確認は、利用者に頼まずに管理側で取れる形にしておくと運用が軽くなります。ブラウザ上ではヘルプのGoogle Chromeについて(chrome://settings/help)を開くと確認と更新の取得が同時に行われ、chrome://versionでは詳細な版が読めます。ポリシーの適用状況はchrome://policyで確認できます。端末側からまとめて取るなら、次のような取得方法があります。

# Windows(PowerShell): 実行ファイルの製品バージョンを読む
(Get-Item "C:\Program Files\Google\Chrome\Application\chrome.exe").VersionInfo.ProductVersion

# macOS: アプリの Info.plist からバージョンを読む
defaults read "/Applications/Google Chrome.app/Contents/Info.plist" CFBundleShortVersionString

# Linux(deb系): パッケージの版を読む
dpkg -s google-chrome-stable | grep '^Version'

Chrome Enterprise Coreに登録している環境であれば、管理対象ブラウザの一覧からバージョンを集計できます。登録していない場合でも、資産管理ツールで実行ファイルの版を集める方式であれば同じことができます。

2026年にGoogleが悪用を公表したChromeの脆弱性#

Chrome Releasesの告知本文に「exists in the wild」という記述が付いた2026年の事例を、公開日順に並べます。

6件のうち3件がV8で、報告者にGoogleの脅威分析グループ(Threat Analysis Group)が入っているものが2件あります。一方でCISAのKEVに載っているのは、この6件のうちCVE-2026-2441、CVE-2026-3910、CVE-2026-11645、CVE-2026-85046の4件です。KEVへの掲載は判断の入力の一つであり、掲載がないから悪用されていないという読み方はできません。ベンダーの告知そのものを見る必要があります。

ゼロデイという語の指す範囲と、公表されてからの時間の扱い方は、次の記事で整理しています。

あわせて読みたい

ゼロデイ脆弱性とは。検知が難しい攻撃にどう備えるか

もう一点、今回の事例で見えるのは修正が公開されてから配信されるまでの時間です。V8のmainブランチへの修正コミットは2026年8月7日で、この修正を含むChrome Stableの公開は9月3日でした。Googleはissueの閲覧を制限しますが、オープンソースであるV8の変更そのものは公開リポジトリに入ります。修正の存在が読み取れる期間があるという前提で、配信されたら早く当てるという運用が効きます。

ブラウザのゼロデイに現実的に備える#

ブラウザの脆弱性は、出てから塞ぐまでの時間を短くする以外に決定打がありません。そのうえで、時間を稼ぐ層をいくつか置けます。

到達経路を細くすることは効きます。今回の攻撃は利用者が細工されたページを開く操作を必要とします。悪意ある広告、フィッシングのリンク、侵害された正規サイトという配信経路への対策は、そのまま到達確率を下げます。危険なページを開かせない仕組みと、開いてしまったあとに気づく仕組みの両方を持っておきます。

ブラウザ拡張機能の管理も同じ軸です。拡張機能はページより広い権限で動き、更新の統制も別系統になります。許可リスト方式での管理と、権限の棚卸しについては次の記事で扱っています。

あわせて読みたい

悪意のあるブラウザ拡張機能による情報窃取。後から武器化される手口と防ぎ方

端末側の検知も残しておきます。レンダラの制御だけで攻撃が完結しない以上、多くの場合は次の段階としてサンドボックス脱出や資格情報の持ち出しが続きます。プロセスの異常な生成やブラウザのプロファイル領域への不自然なアクセスは、ブラウザの脆弱性そのものを検知できなくても捕捉の手がかりになります。

そして更新の運用そのものを可視化します。修正版の公開から自組織の端末の何割が適用済みになるまでに何日かかったのかを毎回記録しておくと、通知期間の設定を変える判断も、版の固定をやめる判断も、数字で議論できるようになります。更新を後回しにしないための組織的な考え方は、次の記事で整理しています。

あわせて読みたい

ソフトウェア更新が脆弱性を塞ぐ仕組みと放置したときのリスク

対応チェックリスト#

まとめ#

CVE-2026-85046は、V8の最適化コンパイラがArray.prototype.sortをインライン展開するときに置いた前提が、比較関数の副作用によって崩れる問題です。要素種別が混ざった呼び出し箇所で、比較関数が対象の配列を整数で埋めるとマップだけが整数用の種別へ戻り、書き戻された参照が整数として扱われます。ここから位置の読み出しと書き込みバリアの省略が組み上がり、V8ヒープ上の任意読み書きへつながります。修正は、インライン展開の条件にすべての受け手の要素種別の一致を加えるという形で入りました。

実務としてやることは単純です。Chromeを152.0.7977.82以上へ上げ、Edgeやその他のChromium系ブラウザも各社が公表した版まで上げ、そして再起動させます。難しいのは最後の一歩で、ダウンロードが終わっていても再起動しなければ古いコードが動き続けます。既定の通知期間は1週間あるため、悪用が確認された修正のときは期間を短くする判断が要ります。

ブラウザのゼロデイは今後も出ます。V8チーム自身が、コンパイラが攻撃面の一部である以上メモリ安全性をコンパイラに保証させることはできないと書いており、V8サンドボックスも強固な境界になるまでに課題が残ると述べています。前提として置けるのは、修正が出てから自組織の端末に届くまでの時間を短くできるかどうかです。その時間を測って改善する仕組みを持っているかが、次のゼロデイのときの差になります。