Chrome 156のセキュリティ更新：353件の修正と、再起動まで終える確認手順

ブラウザーはWebページ、画像、音声、PDFなど多くの外部入力を処理します。普段の業務で使う道具なので、サーバーの更新とは別に端末側の更新を回す必要があります。本稿はGoogleのStable Channel Updateを確認した解説です。発表は米国側の日付表記で2026年10月20日です。

Googleは数日〜数週間の段階的な配信を案内しています。これは更新を先送りしてよいという意味ではありません。管理者は配信状況とサポートされる経路を確認します。香港政府CERTの案内も更新と再起動を推奨しています。ChromeOSやAndroid、Chrome以外のChromium採用ブラウザーは、それぞれの配布元の版を別に確認してください。

CriticalはGoogleの分類です。本稿でCVSSへ換算してはいません。メモリ破壊はプログラムがデータを扱う領域を壊す問題、use-after-freeは使い終えて解放した領域を再利用する問題です。異常終了だけで終わると決めつけず、更新を優先します。一方、353件を「353件すべてがコード実行可能」「すべて悪用中」と言い換える根拠もありません。

Googleは、利用者の更新が進むまで詳細を非公開にする場合があると説明しています。確認した告知だけで、個々のCVEのすべての成立条件や実悪用を確定できてはいません。記事のために細工したページを開いたり、攻撃を再現したりする必要はありません。

1. 1未保存の編集や入力を保存し、Chromeの「Google Chromeについて」に相当する設定画面を開く。
2. 2更新が取得されるか、組織の管理で制限されているかを確認する。エラーや管理状態は記録して担当者へ渡す。
3. 3再起動が求められたら実施し、再び設定画面で実行中の版を確認する。ダウンロード済み表示だけで完了にしない。
4. 4SSO、業務システム、Web会議、印刷など、普段の操作を確認する。動かない場合にセキュリティ機能を無効化して回避しない。

管理者は、端末台帳にOS・チャネル・実行版・最終接続日時・再起動待ち・更新エラーを残します。更新済み端末の割合だけでなく、未完了の端末を誰がいつ確認するかまで決めると、常時起動したままの端末や社外持ち出しPCを取りこぼしにくくなります。

同じ週にはeMudhra中間CAの問題に対するGoogleの告知も出ています。Googleは10月17日に該当する鍵のSPKIをCRLSetで遮断し、この更新自体はブラウザーの再起動を必要としないと説明しています。これはChrome 156のメモリ安全性などの修正を不要にするものではありません。

ブラウザー本体の更新、証明書の失効・ブロック情報、OSの更新は、関連していても同じ配信物ではありません。端末管理ではそれぞれを確認し、HTTPSの鍵マークだけでアプリ全体の安全性を保証しないようにします。

以下は編集部が作成した棚卸し用の指示文です。LLMの回答は安全性の保証にはなりません。未確認項目を残し、担当者が公式資料と実際の稼働状態を照合してください。

点検指示文をダウンロード。基本の進め方は脆弱性のトリアージも参照してください。

確認日：2026年10月22日。公開された一次資料を確認した解説であり、編集部がこの脆弱性の攻撃やパッチ適用を実環境で再現したものではありません。手順のうち優先順位・台帳・回帰確認は編集上の提案です。