Chromeゼロデイ CVE-2026-11645が悪用確認・KEV登録｜同一週に2度目の緊急更新—全社ブラウザを149.0.7827.102以降へ

結論：いますぐ chrome://settings/help を開き、149.0.7827.102以降（できれば6月11日版の.114以降）であることを全端末で確認する

ChromeのJavaScriptエンジンV8に、境界外の読み書きを引き起こす脆弱性CVE-2026-11645 が見つかり、Googleは「本脆弱性のエクスプロイトが実際に存在する」と認めた。細工されたWebページを開くだけで攻撃が始まり得る、悪用確認済みのゼロデイである。修正版は6月8日公開の 149.0.7827.102／.103（Windows・Mac）、149.0.7827.102（Linux）。米CISAは6月9日、悪用が確認された脆弱性カタログ（KEV）に本件を追加した。

さらにGoogleは6月11日、同じ週に2度目となる安定版更新（149.0.7827.114／.115）を公開し、28件の脆弱性を修正したと報じられている。つまり今週は「1週間にChromeを2回更新すべき週」だ。更新を社員任せにしている会社は、未更新端末の数だけ「Webページを開いただけで侵害される」確率を抱えることになる。

なお今週はWindows月例・Acrobat・Zoomなど更新が集中している。全体の段取りは6月第2週・全社PC更新チェックリストで整理しており、本稿はChrome単体の詳細と、ブラウザ更新を組織として統制する方法に絞る。

押さえるべき1点：ブラウザは全社員のPCに入っている数少ないソフトであり、攻撃面も全社員分ある。「個人が気づいたら更新」は統制ではない。バージョンを観測できて初めて統制である。

今週のChrome更新2回の中身

CVE-2026-11645はNVDでCVSS 8.8（High）と評価されている。JIT最適化に起因する境界外アクセスで、攻撃者が用意したHTMLページを開かせるだけでサンドボックス内での任意コード実行に至る。発見者は匿名の研究者で、4月27日に報告され55,000ドルの報奨金が支払われたと報じられている。Chromeで悪用が確認されたゼロデイは、CVE-2026-2441／3909／3910／5281に続き2026年に入って5件目と報じられており、4件目の経緯はChrome 146緊急アップデート（CVE-2026-5281）の解説にまとめている。

なぜ「個人任せの更新」が通用しないのか

Chromeは自動更新があるから大丈夫——は半分しか正しくない。自動更新はダウンロードまでで、適用にはブラウザの再起動が必要だ。何日もタブを開きっぱなしの社員の端末は、修正版公開後も旧バージョンのまま動き続ける。悪用済みゼロデイでは、この「再起動待ち」の数日がそのまま攻撃可能期間になる。

そして年5件ペースでゼロデイが出る以上、これは単発の事故対応ではなく繰り返し発生する運用イベントである。Windows月例（6月は史上最多200件）と同じく、ブラウザにも「誰が・いつまでに・どう確認するか」の決まった手順が要る。

全社ブラウザ更新統制の5項目チェックリスト

1. 即時アクション：全社員に chrome://settings/help を開かせ、更新適用と再起動まで実施させる（バージョン画面を開くと更新が走る）
2. バージョンの観測：MDM・IT資産管理ツールでブラウザバージョンを収集し、未更新端末を一覧できる状態にする
3. 強制ポリシー：Chrome Enterpriseポリシーで自動更新を強制し、未再起動が続く端末に再起動を促す設定（再起動通知・期限）を入れる
4. 派生ブラウザの確認：Edge・Brave等のChromium系ブラウザも同じV8を使うため、各ベンダーの修正版適用状況を確認する
5. 手順の定型化：「悪用確認済み（KEV登録）なら48時間以内に全端末適用」など、深刻度別の適用期限を文書化する

チェックの勘所：1回の号令で終わらせず、2の「観測」を仕組みにできるかが分かれ目だ。観測がなければ、適用率は「たぶん大丈夫」以上にならない。

ブラウザ更新を「社員任せ」にしないための管理観点

Chromeのゼロデイ対応で見るべき指標は、全社平均の更新率ではない。重要なのは、業務上インターネット閲覧が多い部門、管理者権限を持つ端末、VPNやSaaS管理画面へアクセスする端末が、期限内に更新されているかである。1台でも古い端末が残れば、フィッシングや水飲み場攻撃の入口になる。

管理側では、バージョン確認、強制更新、再起動期限、例外端末の承認、未更新端末の隔離を一連の運用として定義する。今回のように同一週で複数回更新が出る場合、初回更新で満足せず、最新安定版への到達を確認することが必要だ。

よくある質問（FAQ）

Q. 自動更新を有効にしていれば何もしなくてよいか？ A. 不十分である。適用には再起動が必要で、再起動していない端末は旧バージョンのまま稼働する。悪用確認済みの脆弱性では、全端末の再起動完了までを対応範囲とすべきだ。

Q. 6月8日版（.102）を適用済みなら、6月11日版は急がなくてよいか？ A. 6月11日版で悪用確認済みの追加報告は出ていないが、同一週に2度目の更新が出る週は攻撃側の関心も高い。通常の適用サイクルに乗せて早期に展開することを勧める。

Q. 情シスが1人で、全端末のバージョン確認まで手が回らない。 A. まずは即時の全社アナウンスと再起動指示で穴を塞ぎ、並行してMDM・資産管理によるバージョン可視化を整備すべきだ。可視化はブラウザ以外のパッチ運用にもそのまま効く投資である。

社内で今日確認する実務チェック

この記事のテーマを自社に当てはめるときは、次の順で確認する。第一に、対象製品・対象バージョン・対象サービスが資産台帳に載っているか。第二に、インターネットや不要な社内セグメントから到達できないか。第三に、更新・緩和・監視の担当者と期限が明確か。第四に、委託先やクラウド運用先が関係する場合、回答を口頭ではなくチケットやメールで記録しているか。第五に、対応後にバージョン・設定・ログで完了を確認したかである。

脆弱性対応で最も危険なのは、「使っているか分からない」「担当が分からない」「ベンダーに任せているはず」という状態だ。今回の記事を読んだ時点で対象有無を即答できないなら、それ自体が改善テーマである。個別のパッチ適用だけでなく、資産台帳、脆弱性通知の受信経路、緊急対応の承認権限まで点検したい。

GXOへ相談する前に整理しておくと早い情報

相談前には、対象製品名、バージョン、設置場所、外部公開の有無、管理者、保守契約、更新可能な時間帯、過去の障害履歴を分かる範囲でまとめる。すべて揃っていなくてもよいが、「分からない項目」が多いほど、最初の支援はパッチ作業ではなく棚卸しと露出確認から始めるべきである。

30日で整える脆弱性対応ロードマップ

初日から3日目までは、対象有無の確認と暫定緩和に集中する。資産台帳、EDR/MDM、クラウド管理画面、保守ベンダーへの照会を使って、対象製品がどこにあるかを洗い出す。対象が見つかった場合は、外部公開の停止、アクセス制限、管理画面のIP制限、監視強化など、更新前にできる緩和策を先に入れる。

4日目から10日目までは、更新・設定変更・影響確認を進める。業務影響が大きい製品では、検証環境で更新手順を確認し、失敗時の切り戻し手順を用意する。更新後はバージョン表示だけでなく、実際に脆弱な経路が閉じているか、ログに不審なアクセスが残っていないかを確認する。

11日目から30日目までは、再発防止に使う。通知を誰が受けるか、KEVやJPCERT/CCなどの情報をどう優先度付けするか、休日・夜間の緊急判断を誰が承認するかを決める。今回のような高リスク通知に対して、次回は「対象有無を24時間以内に答えられる」状態を目標にする。

よくある失敗パターン

第一の失敗は、CVE番号やCVSSだけを見て、対象資産の有無を確認しないことだ。スコアが高くても自社に対象がなければ対応は不要であり、逆にスコアが中程度でもKEV登録や悪用確認があれば最優先になる。優先順位は、CVSS、悪用状況、外部公開、権限条件、業務影響を組み合わせて決める。

第二の失敗は、更新完了を「ベンダーに依頼した」で止めることだ。更新後のバージョン確認、到達制限、ログ確認、再起動状態、冗長系への反映まで確認しなければ完了とは言えない。特にアプライアンスや管理基盤では、片系だけ更新されてもう片系が古いまま残ることがある。

第三の失敗は、今回だけの緊急対応で終わることだ。脆弱性情報は毎月出る。対応のたびに担当者探しから始まる組織は、次回も同じ遅れを繰り返す。今回の対応記録を使い、対象確認テンプレート、判断フロー、連絡先一覧、夜間休日の承認ルールまで更新することが重要である。

成果物として残すべきもの

公開記事を読んで終わらせず、社内には少なくとも4つの成果物を残したい。対象有無確認表、対応判断メモ、更新・緩和作業の証跡、再発防止タスクである。これらが残っていれば、監査や事故後説明でも「いつ、誰が、何を根拠に判断したか」を示せる。

また、委託先が関係する場合は、委託先回答をそのまま保存するだけでなく、自社として受け入れた判断も記録する。セキュリティ運用では、作業を委託できても説明責任は委託できない。

判断表：読むだけで終わらせないための整理

この表を埋めると、記事の内容を「読んだ情報」から「社内で動かすタスク」に変えられる。特に重要なのはNGサインである。NGサインが1つでも出る場合、問題は個別ニュースではなく、社内の判断プロセスにある。

公開情報は日々更新されるため、記事本文の数値や期限をそのまま固定値として扱うのではなく、一次情報の最新版、社内の対象有無、実施記録をセットで確認する。これにより、速報記事を一過性の話題で終わらせず、監査・稟議・改善計画に使える材料へ変換できる。

いつGXOに相談すべきか

• 全社のブラウザ・OS・主要ソフトのバージョンを一覧できる仕組みがない
• ゼロデイのたびに号令だけで終わり、適用率を確認できていない
• 情シスが1人または不在で、パッチ運用の体制と基準を外部の力で整えたい

GXOはセキュリティ診断によるエンドポイント管理状況の可視化、セキュリティ顧問によるパッチ運用体制の構築を支援している。IT管理全体の成熟度を測りたい場合はDX成熟度診断も活用してほしい。→ ブラウザ更新統制の相談はこちら

関連記事

• 6月第2週・全社PC更新チェックリスト
• Chrome 146緊急アップデート｜CVE-2026-5281は2026年4件目のゼロデイ
• Windows月例パッチ史上最多200件｜BitLocker迂回ゼロデイ2件
• MDM/BYOD管理ガイド｜Intune・Jamf・CLOMO比較

参考資料

• Google「Chrome Releases: Stable Channel Update for Desktop」
• CISA「CISA Adds Three Known Exploited Vulnerabilities to Catalog（2026年6月9日）」
• Help Net Security「Google patches Chrome zero-day exploited in the wild (CVE-2026-11645)」（二次情報）
• Tenable「CVE-2026-11645」（NVD準拠データ）
• Security NEXT「Chromeに今週2度目のアップデート」（二次情報）

本記事は2026年6月12日時点の公開情報をもとに作成。6月11日更新の修正件数・バージョンは報道ベースであり、ゼロデイの詳細はGoogleが利用者への展開完了まで制限している。適用判断はChrome ReleasesおよびCISAの一次情報の最新版を必ず確認すること。