Chrome・Windows の脆弱性連鎖｜更新確認と侵害調査の分け方

はじめに

2026 年 9 月 21 日（米国時間）、Volexity は、同社が UTA0565 と呼ぶ攻撃者が Google Chrome と Microsoft Windows の脆弱性を連鎖させ、偽サイト経由でマルウェア CLEANGULP を配布していたとする調査結果を公開しました。攻撃は 2026 年 9 月 3〜4 日に観測されています。同じ攻撃コードは、9 月 9 日に Volexity と Proofpoint が別の攻撃者による利用を報告しており、今回はその追加報告にあたります。

対象となる脆弱性は、Chrome の CVE-2026-85046、CVE-2026-87491 と、Windows の CVE-2026-85880 の 3 件です。いずれも修正版は公開済みですが、修正版の公開前から攻撃に使われていました。そのため、「Chrome は自動更新され、Windows の月例更新も配信した」という管理画面上の状態だけでは、自社端末の対応が済んだとは判断できません。

本記事では、情シス・端末管理の担当者が自社端末を確認する立場から、更新の完了確認と侵害の確認を分けて整理します。公式情報、研究者の観測・評価、編集上の運用提案は区別して記載します。筆者による実機検証や感染実験は行っていません。

結論として、Chrome は 153.0.8010.36 以降（執筆時点の Stable は 154.0.8037.57/.58）へ更新して再起動まで完了させ、Windows は OS ごとの 2026 年 9 月の累積更新以降のビルドであることを端末上で確認することを推奨します。そのうえで、更新前の期間に Windows 10 や Windows Server で Chrome を使っていた端末は、更新とは別の作業として、公開された IoC との照合を行うことをおすすめします。

Chrome と Windows の脆弱性連鎖で何が起きたか

今回の攻撃は、Web ページを開いた Chrome のレンダラープロセス内でコードを実行し、Windows カーネルの権限昇格でサンドボックスの外へ出る、3 段階の連鎖です。各脆弱性が越える境界を分けると、どの更新で何が防がれるかを判断しやすくなります。

3 件の脆弱性が越える境界

CVE-2026-85046（V8 の型混同）

Chrome の JavaScript エンジン V8 の型混同（Type Confusion）です。Proofpoint の解析では、攻撃コードはこの脆弱性で V8 のヒープ領域の任意読み書きを得ます。Google の CVE 記述は、細工した HTML ページによってサンドボックス内で任意のコードを実行できる脆弱性としています。

CVE-2026-87491（V8 の境界外書き込み）

Google は V8 の境界外書き込み（Out of bounds write）と分類しています。Volexity と Proofpoint は、WebAssembly の関連データを改ざんして V8 サンドボックスを脱出する段階と説明しています。V8 サンドボックスは V8 のヒープを閉じ込める仕組みで、ここを脱出してもコードが動くのは依然として Chrome のレンダラープロセスの中です。

CVE-2026-85880（Windows ALPC の権限昇格）

Windows の ALPC（Advanced Local Procedure Call）のヒープベースのバッファオーバーフローで、Microsoft はローカルの権限昇格と分類しています（CVSS 3.1: 7.8、攻撃元区分はローカル）。攻撃コードはこれでレンダラープロセスの権限を引き上げ、OS のプロセス隔離によるレンダラーのサンドボックスから出て、Chrome のブラウザープロセスへコードを注入します。

つまり、Chrome の 2 件はレンダラー内でのコード実行、Windows の 1 件はレンダラーのサンドボックスからの脱出を担います。CVE-2026-85880 は、単体でインターネットから認証なしに直接悪用できるリモートコード実行の脆弱性ではありません。ブラウザーなど別の経路で端末上のコード実行を得た攻撃者が、権限を引き上げるために使う脆弱性です。

参考: Volexity（第 1 報）
“to escape Chrome’s sandboxed renderer process”
（Chrome のサンドボックス化されたレンダラープロセスから脱出するため）
https://www.volexity.com/blog/2026/09/09/mind-the-patch-gap-multiple-chinese-threat-actors-chain-0-day-exploits-in-chrome-windows/

攻撃日・修正公開日・報告日の整理

日付は出典の表記に従っています。攻撃の観測日、修正版の公開日、調査報告の公開日は別のものとして読む必要があります。

Volexity は、UTA0565 の攻撃を脆弱性が未修正の時点での悪用と表現しています。一方、Chrome Releases では CVE-2026-85046 の修正版が 9 月 3 日に公開され、数日から数週間かけて配信されるとしています。残る 2 件の修正は 9 月 8 日です。連鎖全体としては修正前の攻撃と読めますが、CVE ごとに修正日が異なる点は区別が必要です。「ゼロデイとして悪用された」ことと「現在も修正がない」ことは別で、3 件とも執筆時点で修正版が公開されています。

参考: Volexity（第 2 報）
“while the vulnerabilities were still unpatched”
（脆弱性がまだ修正されていない間に）
https://www.volexity.com/blog/2026/09/21/mind-the-patch-gap-part-2-fake-websites-used-to-deploy-chrome-windows-0-day-exploits/

CVE-2026-85046 は、修正が Chromium のオープンソースコードに反映されてから Chrome の配布版に届くまでに差があり、Proofpoint はこの期間を約 4 週間としています。Volexity と Proofpoint はいずれも、攻撃コードの作成者が公開済みの修正差分を解析した可能性を指摘しています（研究者の評価）。

CISA の KEV カタログには 3 件とも個別に掲載されていますが、追加日と対応期限はそれぞれ異なります。この期限は米国の連邦政府機関に向けた CISA の指令に基づくもので、日本企業に適用される義務ではありません。優先度を判断する参考情報として扱うのが適切です。

観測された攻撃の範囲と先行事例との違い

Volexity の第 2 報によると、UTA0565 はアジアの政府機関に中国語の攻撃メールを送ったほか、米国のシンクタンク Center for American Progress を装うメールも送っていました。リンク先は正規サイトに似せた chinadigitaltimes[.]top や americanprgoress[.]top で、後者は正規サイトのコンテンツを読み込みつつ、非表示の iframe で攻撃コードを読み込んでいました。UTA0565 を中国の攻撃者とする帰属は、Volexity の評価です。

攻撃コードは Proofpoint が BlueMoon と名付けたもので、Proofpoint は 4 つの攻撃者による利用を報告しています。観測された標的は米国の NGO、鉱業、航空宇宙企業、ベトナムの製造業、インドネシアとシンガポールの政府・金融などで、今回確認した一次情報に日本の組織の被害は記載されていません。ただし Volexity は、公表された観測は 2 社によるものにとどまり、実際の範囲はより広い可能性が高いとしています。

先行事例で報告された GRIMWEDGE（UTA0560）や LONGTALE（JungleBamboo）は、今回の CLEANGULP とは別の攻撃者・別のマルウェアです。攻撃コードの中核は共通ですが、最終的に配置されるファイル、タスク名、通信先は異なります。本記事の痕跡の表は CLEANGULP に限定しているため、先行事例の IoC は各報告を参照してください。

観測された攻撃コードは、Windows 上の Chrome 以外では次の段階へ進まないよう絞り込まれていました（Volexity 第 1 報）。これは攻撃者の実装上の条件であり、脆弱性の影響範囲とは別です。Google は Chrome の 2 件について Windows・Mac・Linux 向けに修正版を公開しています。Chromium を基盤とする他のブラウザーについて、CISA は影響の可能性を示していますが、本記事では Microsoft Edge などの修正状況を検証していないため、各ベンダーの公式情報で確認することを推奨します。

参考: CISA KEV（CVE-2026-85046）
“This vulnerability could affect multiple web browsers that utilize Chromium”
（この脆弱性は Chromium を利用する複数の Web ブラウザーに影響する可能性があります）
https://www.cisa.gov/known-exploited-vulnerabilities-catalog?field_cve=CVE-2026-85046

影響範囲と修正版を確認する

確認対象は、すべてのデスクトップ端末の Chrome のバージョンと、CVE-2026-85880 の影響製品にあたる Windows の OS バージョン・ビルドの 2 系統です。どちらも、管理画面で配信・承認した状態ではなく、端末上で更新が反映された状態を完了とみなします。

製品ごとの更新確認表

Chrome の初回修正版と推奨する更新先

2 件の修正は別のリリースに含まれており、CVE-2026-85046 だけを修正した 152 系では CVE-2026-87491 が残ります。Chrome 側の 2 件を両方ふさぐには 153.0.8010.36 以降が条件で、執筆時点（2026 年 9 月 24 日）では、9 月 22 日に公開された Stable の 154.0.8037.57/.58 以降への更新を推奨します。154 では、今回の 2 件以外の脆弱性も多数修正されています。

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

Extended Stable チャネルを使っている組織は注意が必要です。Extended Stable は 152 系で更新が続いており、9 月 22 日時点で 152.0.7977.140 ですが、Extended Stable の告知には CVE-2026-87491 の修正の有無が記載されておらず、筆者は確認できていません。確認できるまでは、対象端末を Stable の 153.0.8010.36 以降へ切り替えるか、Google の公式窓口で修正状況を確認することを推奨します。

Chrome の更新は段階的に配信され、ダウンロード後もブラウザーを再起動するまで適用されません（Google Chrome ヘルプ）。長期間 Chrome を閉じない利用者の端末では、更新を取得済みでも旧バージョンのまま動作していることがあります。自動更新の停止やバージョン固定のポリシーが残っていると更新が届かないため、chrome://policy で適用中のポリシーも確認します。グループポリシーによる Chrome の管理手順は、関連記事『Chrome のグループポリシー設定｜ADMX 追加とパスワード保存制限の手順』を参照してください。

Windows の OS 別の修正ビルドと KB

Windows 側は、OS ごとに修正ビルドと KB が異なります。単一の KB を全端末共通の対策として扱わず、OS バージョンごとに修正ビルド以上かどうかで判定します。影響製品は Microsoft が CNA として登録した CVE Record とセキュリティ更新プログラムガイドの情報、攻撃コードの対象は Volexity と Proofpoint の解析に基づきます。

参考: Microsoft（CVE-2026-85880 の CVE Record）
“allows an authorized attacker to elevate privileges locally”
（承認された攻撃者がローカルで権限を昇格できる）
https://msrc.microsoft.com/update-guide/vulnerability/CVE-2026-85880

攻撃コードの対象外である OS も、Microsoft が影響製品としている以上は更新の対象です。観測された攻撃コードの対象表にないことは、その OS が安全であることを意味しません。反対に、攻撃コードの対象でありながら Microsoft の影響製品一覧にない Windows 10 2004〜21H1 と Windows 11 21H2 は、サポートが終了した版で、この CVE の修正更新を確認できません。これらを安全と判定せず、サポート対象の版への移行や、移行までの Chrome 利用の制限を優先することを推奨します（編集上の運用提案）。

攻撃コードの対象ビルドについて、Volexity は Windows 10 1809〜22H2、Server 2022、Windows 11 21H2 と記載し、Proofpoint はビルド 17763 を「Windows 10 1809／Server 2019」と記載しています。Server 2019 の扱いに表記差がありますが、両社ともビルド 22000 を超える Windows は対象外としています。Proofpoint は、Windows 側の脆弱性を古いビルドに限られるものと表現しています。

参考: Proofpoint
“present only in older Windows builds”
（古い Windows ビルドにのみ存在する）
https://www.proofpoint.com/us/blog/threat-insight/once-bluemoon-multiple-state-aligned-threat-actors-rapidly-adopt-novel-exploit

OS ごとの補足は次のとおりです。

• KB5122878 は Windows 10 ESU 向けの更新として公開されています。ESU の対象外の Windows 10 22H2 端末では受け取れないため、Windows 11 への移行状況とあわせて確認することを推奨します。
• Windows Server 2012／2012 R2 の更新も ESU として提供されており、Microsoft は ESU の最終期限を 2026 年 10 月 13 日としています。
• Windows Server 2022 Datacenter: Azure Edition のホットパッチ登録環境では、9 月はベースライン月のため、再起動を伴う通常の更新として配信されています。
• 9 月の累積更新では、リモートデスクトップや USB オーディオ機器の既知の問題が報告され、9 月 14 日に定例外更新が公開されています。症状別の整理は Windows 11 向けですが、関連記事『KB5129195 の定例外更新｜症状別の修正状況と残る既知の問題』も参考になります。

更新の適用から完了確認までの手順

管理画面での配信・承認と、端末上での適用完了を分けて確認します。

Get-ItemProperty "HKLM:\SOFTWARE\Microsoft\Windows NT\CurrentVersion" | Select-Object ProductName, DisplayVersion, CurrentBuild, UBR

(Get-Item "$env:ProgramFiles\Google\Chrome\Application\chrome.exe").VersionInfo.ProductVersion

更新状況と侵害の疑いから対応を判断する

更新は脆弱性をふさぐ処置であり、すでに配置されたマルウェアや永続化の設定を取り除くものではありません。更新の完了確認とは別に、更新前の期間に侵害の兆候がないかを端末ごとに判断します。

4 区分の対応判断表

侵害が疑われる端末では、更新のための再起動や再イメージの前に、隔離とメモリーを含む証拠の保全を優先することを推奨します。Volexity が公開した CLEANGULP の YARA ルールはメモリー上の文字列を対象としており、再起動するとこの手がかりは失われます。

調査対象期間の考え方

調査期間の起点は、攻撃の観測時期から決めます。Proofpoint が攻撃キットの最初の利用を観測したのは 2026 年 8 月 28 日、UTA0565 の関連ドメインの登録日は 9 月 2〜4 日です。編集上の提案として、BlueMoon 全体を対象にするなら 8 月 28 日、CLEANGULP に絞るなら 9 月 2 日を起点とし、各端末で Chrome と Windows の更新が完了した日時までを確認範囲とする方法が考えられます。ログの保存期間がこの範囲に届かない端末は、判断できない区分として扱います。

Windows 11 は CVE-2026-85880 の影響製品に含まれておらず、観測された攻撃コードでもビルド 22000 を超える Windows では権限昇格の段階が実行されないとされています。調査の優先度は Windows 10 と Windows Server より下げられますが、これは今回の攻撃コードの実装に基づく観測であり、Chrome の 2 件は OS を問わず修正対象です。

CLEANGULP の痕跡を確認する

CLEANGULP の痕跡は、単一の項目で感染を確定できるものではありません。ファイル名やタスク名だけでなく、パス、ハッシュ、通信、実行履歴を組み合わせて判断します。以下は、Volexity の第 2 報と、記事末尾からリンクされた公式 IoC（GitHub の iocs.csv と YARA ルール）に基づきます。

痕跡と調査先の対応表

公開されたファイルハッシュ（SHA256）は次のとおりです。MD5 は 177652713dad3c128bd9195abf2b7603、SHA1 は 668aa5551315ab26b67118fbb29f8e4560a1e1af です。

8858ea412dc306b3558885af18006c5ca24689e8875733b5e13b3c2692e603cb

Proofpoint は、既定の BlueMoon では chrome.exe → cmd.exe → curl.exe という特徴的なプロセスツリーが生じると指摘しています。一方、Volexity によると、UTA0565 の変種は cmd.exe と curl を使わず、プロセス内でファイルをダウンロードし、COM 経由で Windows シェルから起動します。既定のプロセスツリーを前提にした検知ルールだけでは、今回の変種を拾えない可能性があります（編集上の推論）。

IoC が見つからないことは、侵害されていないことの証明にはなりません。攻撃者は関連ドメインを複数用意しており、ファイルや通信先は変更されうるためです。

観測済みの IoC と推定されたドメインの区別

悪性ドメインは無害化表記で記載しています。ブログ本文での位置付けと、公式 IoC（iocs.csv）の説明は次のとおりです。

ブログ本文では、thecovnresation[.]net と borneobulletins[.]top は登録パターンから推定したドメインとして扱われていますが、iocs.csv では Suspected の記載がありません。ホスト IP 96.9.125[.]52 はブログ本文にのみ記載されています。出典間で位置付けに差があるため、ブロックリストには両方を登録しつつ、検出時の評価では観測済みと推定を分けて扱うことを推奨します。

端末での確認コマンドの例

個別の端末で確認する場合の例です。スケジュールタスクは schtasks（Microsoft Learn）で一覧を取得し、タスク名で絞り込みます。/tn は既定でルートフォルダーを探すため、サブフォルダーに登録されている場合も拾えるよう、一覧から検索します。

schtasks /query /fo LIST /v | findstr /i "MicrosoftIME"

配置先のファイルは、Get-FileHash（Microsoft Learn）で全ユーザープロファイルを対象にハッシュを計算し、公開されたハッシュと照合します。他のユーザーのプロファイルを読むため、管理者権限で実行します。

Get-FileHash -Path "C:\Users\*\AppData\Local\Microsoft\IME\MicrosoftIME.exe" -Algorithm SHA256

結果が空でも未侵害の証明にはならない点は、前述のとおりです。EDR を導入している環境では、同じ条件を全端末へ横断検索する方が、停止中の端末やプロファイル単位の見落としを減らせます。

まとめ

今回の攻撃は、Chrome の 2 件でレンダラー内のコード実行を得て、Windows の権限昇格でサンドボックスの外へ出る連鎖でした。3 件とも修正版は公開済みですが、修正前から悪用されていたため、更新の完了確認と侵害調査を分けて進めることが対応の要点です。

• Chrome は 153.0.8010.36 以降が条件で、執筆時点では 154 系への更新を推奨します。
• Chrome の更新は再起動まで確認し、実行中のバージョンで完了を判定します。
• Windows は OS ごとの修正ビルド以上であることを、ビルド番号で確認します。
• 攻撃コードの対象外でも、Microsoft の影響製品は更新対象として扱います。
• 更新は既存の感染を除去しないため、更新前の期間は IoC 照合を別に行います。
• IoC や EDR の警告がある端末は、隔離と証拠保全を更新より優先します。
• IoC の未検出は未侵害の証明ではなく、ログ不足は判断不能として記録します。

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