ページを軽くする圧縮形式として、gzipと並んで広く使われているBrotliに、深刻度の高い脆弱性が見つかりました。Googleが10月21日に修正版を出し、カナダのサイバーセキュリティセンターも10月28日付で注意喚起を出しています。米国のCISAは10月27日に、実際に悪用が確認された脆弱性の一覧へこの件を加えました。

名前だけ聞くと「サイトの圧縮を止めないといけないのか」と身構えてしまいますが、問題があるのは圧縮されたデータを元に戻す側、つまり読み出しの処理です。どこを確かめればよいのかを、一次情報をもとに整理してみます。

読み出しの処理でメモリの外に書き込んでしまう

対象はGoogleのBrotliライブラリの1.0.3から1.2.0までで、修正版は1.0.10、1.1.1、1.2.1の三つです。識別番号はCVE-2026-111497で、Googleは共通の評価基準で9.2(最も重い区分)と評価しています。

Brotliの圧縮データはブロックという単位に分かれていて、途中で符号の表を切り替えられる作りになっています。Node.jsの公表によると、不正な切り替えの指示が来たとき、本来は「データが壊れている」と判断すべきところを「入力が足りないだけ」と扱ってしまい、内部の小さな作業領域の外へ書き込みが続いていました。細工した圧縮データを読ませるだけで、処理の停止やメモリの中身の漏えい、場合によっては任意のコードの実行につながるとされています。ログインは必要ありません。

Brotliは単体で使われるより、ほかのソフトの中に組み込まれていることが多い技術です。カナダの注意喚起では、Node.js、.NET、PowerShell、Bun、Envoy、Istio、PythonのBrotliとbrotlicffiのパッケージなどが影響を受けるものとして挙げられています。

WordPressのサーバーで見ておきたいところ

まず安心材料から書くと、ApacheのBrotliモジュールやnginxは、標準の設定では送るときに圧縮するだけで、受け取ったデータを読み出す処理はしないと報告されています。サイトの表示を速くするためにBrotliの圧縮を有効にしていること自体が、すぐ危険につながるわけではありません。

一方で、PHPにBrotliの拡張を入れている場合は話が別です。この拡張は内部にBrotliの写しを持っていて、10月25日に出た0.21.1で修正版に入れ替わりました。OSのライブラリを更新しても、拡張が持っている写しは古いままになりうるので、拡張の版を個別に確かめる必要があります。DebianなどのOSのbrotliのパッケージにも修正版が出ているので、サーバーの定期的な更新と合わせて当てておくと安心です。

サーバーの外へデータを取りにいく処理も入り口になります。ある検証記事では、Pythonの代表的な通信ライブラリが、Brotliのパッケージさえ入っていれば、こちらが圧縮しないよう頼んでも、相手が圧縮して返してくれば読み出してしまうことが確かめられています。外部の画像やRSSを取り込む処理、Webhookの送り先、リンクの見出しを取りにいく処理など、相手のサーバーを選べない通信は特に気にしておきたいところです。

Node.jsと手元の開発環境も見直す

Node.jsは10月21日に、22.23.4、24.22.1、26.12.1の修正版を出しました。公式のNode.jsはBrotliを本体の中に抱えているため、OSのライブラリを更新しても直りません。Express 5は標準で圧縮された送信データを読み出すので、Node.jsで受付の仕組みを作っている場合は優先して更新したいところです。すでにサポートが終わったNode.js 20系などには修正が出ないので、これを機に乗り換えを考える必要があります。

見落としやすいのが手元のパソコンです。先の検証では、Git for Windowsに同梱されたcurlが古いBrotliを使っていて、信頼できない相手からcloneすると応答が読み出される状態だったと報告されています。10月26日の2.56.0.windows.4で修正版に入れ替わったので、git versionで版を見ておくとよいでしょう。ビルドの道具としてNode.jsを入れている制作者の環境も同じく更新の対象です。

なお、Node.jsは同梱のBrotliの版を上げずに修正だけを取り込んだため、表示される版は1.1.0のままです。版の文字列だけで判断せず、Node.js本体の版で確かめるのが確実です。

すぐに更新できないときの考え方

カナダの注意喚起では、修正版をすぐに入れられない場合、信頼できない相手から来たBrotliの圧縮データを処理させないよう求めています。受け取る側なら、手前の中継サーバーで圧縮形式にbrが含まれる送信を断る、Expressなら送信データの読み出しを止める設定にする、といった手が挙げられています。あわせて、処理の予期しない停止や不審な動きがないかを見ておくことも勧められています。

今回の件は、ページを速くする技術が、いつのまにかサーバーや開発環境のあちこちに組み込まれていることを改めて気づかせてくれました。表に見える設定だけでなく、拡張や同梱物の中身まで含めて、どこで何が使われているかを一度洗い出しておくと、次に似たことが起きたときの動きがずっと速くなるはずです。