Brotli脆弱性「HTTP2Shell」、複数ランタイムに広がった仕組みと修正版

自分のNode.jsサーバーが、外部のAPIをfetchしてその応答を使っている。そんな処理に心当たりがあるなら、2026年10月21日にNode.jsが出した緊急のセキュリティ更新は人ごとではない。原因はBrotliという圧縮ライブラリのデコーダにあるバグで、細工された圧縮データを送られるだけでサーバーのメモリが壊される。Node.jsだけでなく、Python・Bun・Envoy/Istioも同じ原因で同時に修正版を出した。なぜ1つのバグがこんなに広い範囲に飛んだのか、自分の環境は対象なのか、何を更新すればいいのかを順に確かめる。

Node.jsの緊急更新で何が直ったのか

Node.jsは10月21日、公式ブログで22.x・24.x・26.xの3系統すべてにセキュリティ更新を出した。この中でもっとも深刻度が高い(High)とされたのが、CVE-2026-111497と採番されたBrotliデコーダの境界外書き込みだ。コミュニティでは通称「HTTP2Shell」とも呼ばれている。

公式ブログの説明はこうなっている。不正な形式の圧縮入力を渡すと、デコーダが内部バッファの終端を越えて書き込んでしまう。node:zlibでBrotliデータを復号する処理があり、そのデータを攻撃者が用意できる状況なら、プロセスメモリが破壊される。結果はクラッシュ、メモリの漏えい、最悪の場合はリモートでのコード実行にまで至りうる。修正版はv22.23.4・v24.22.1・v26.12.1以降で、対応はバージョンを上げる以外にない。

ここまでなら「Node.jsを更新すればいい話」で終わる。だが同じCVE番号が、全く別の技術スタックのページに次々と出てきた。

なぜ複数のランタイムに広がったか

Node.js以外にも、同じCVE-2026-111497を公式に認めているページがある。

• GitHub Security Advisory: PyPIのbrotli・brotlicffi(Python)が対象。1.2.1系へ
• Envoy公式アドバイザリ: リバースプロキシのEnvoyが対象
• Bun公式アドバイザリ一覧: JavaScriptランタイムのBunが対象
• Istio公式告知: サービスメッシュのIstioが、内部で使うEnvoy経由で対象

Node.jsの更新ノートを読んだだけのときは、自分には縁のない話だと思いかけた。ところが見た目の全く違うソフトウェアの公式ページを一つずつ開くたびに、同じCVE-2026-111497が出てくる。言語もランタイムもプロキシも違うこれらのソフトウェアが、なぜ同じ日に同じ脆弱性を踏んだのか。

答えは、どれもGoogleが開発するBrotliというC言語の圧縮ライブラリの「デコーダのコード」をそのまま自分の中に取り込んで使っているからだ。ライブラリを外部から呼び出すのではなく、ソースコードごと複製して組み込むこのやり方を「ベンダリング」と呼ぶ。更新のたびに手元のコピーへ反映し忘れると、本家で直った不具合が自分の製品の中にだけ生き残る。

原因になった箇所は1つに絞り込まれている。GitHub Advisoryによれば、バグがあるのはBrotliのソースコードのうちc/dec/decode.cというファイルだ。Node.js、Bunの処理系、Envoyのプロキシ機能、どれもこの同じファイルのコピーを抱えている。では、そのファイルの中で何が起きていたのか。

8バイトのバッファで何が起きたか

Node.js公式ブログは、原因をこう説明している。デコーダは圧縮データの中の「ブロック切り替え」が無効な形だったとき、本来はそこでデータの形式エラーとして処理を止めるべきだった。ところが実際の実装は、このエラーを「まだ入力が足りない、続きをよこせ」という一時的な状態として誤って扱っていた。

この誤判定の先にあるのは、わずか8バイトの内部バッファだ。複数のプロジェクトの公式資料を読み比べていて、自分もこの数字の小ささには少し驚いた。ストリーミング処理の都合上、デコーダは「続きが必要」と判断するたびに、このバッファへ入力バイトを追加していく。本来ならデータの終わりで止まるはずの書き込みが、エラーを継続状態と取り違えたことで止まらなくなり、8バイトという小さな領域の外側まで書き込み続けてしまう。これが境界外書き込みの正体だ。

壊れたデータそのものが危険だったのではない。壊れたデータを「エラー」ではなく「まだ続きがある」と分類してしまった、たった1箇所の判定ミスが、書き込みを止める仕組みごと無効にしていた。

GitHub Advisoryは、この脆弱性にCVSS v4で9.2(Critical)という基本スコアを付けている。認証もユーザー操作も要らず、ネットワーク越しに機密性・完全性・可用性のすべてへ高い影響を与えられる、という判定による。一方でIstio公式ページはCVSS v3.1で7.7、Node.js自身の評価はHighとしている。採点方式そのものが違ううえ(v3とv4は計算の仕組みが異なる)、評価元も複数ある。そのため数字をそのまま比べることはできない。ただ、どの評価でも「深刻」の水準にあることは共通している。では、自分の環境はこの中のどれかに当てはまるのか。

自分の環境は対象か

ここまでの登場人物を、公式に確認できた対象バージョンと修正版で並べる。

表を見て「自分はNode.jsしか使っていない」と思っても油断はできない。ビルド済みのバイナリやコンテナイメージの中に、気づかないままNode.jsやBrotliライブラリが同梱されていることがある。たとえばSBOM(ソフトウェア部品表)を生成するツールのcdxgenは、同梱しているNode.js経由でこの脆弱性の影響を受け、修正版が出ている。自分が直接インストールしたものだけでなく、使っているツールやイメージの中身まで対象になりうる。

CISAは、実際に悪用が確認された脆弱性を「Known Exploited Vulnerabilities Catalog」にまとめている。このデータを2026年10月25日時点で確認したが、CVE-2026-111497は含まれていなかった。公開されている情報の範囲では、実環境での悪用が広がっている段階ではない。ただし脆弱性の内容そのものは公開されているため、この状態が続く保証はない。

今すぐ確認すること

自分の環境が対象かどうかは、次の手順で確かめられる。

1. 本番サーバー・コンテナ・CI/CDのビルドエージェントで、動いているNode.js・Python・Bunのバージョンを確認する。node -v、Pythonなら仮想環境やコンテナ内のbrotli・brotlicffiのバージョンを見る
2. リバースプロキシやサービスメッシュにEnvoy・Istioを使っているなら、そのバージョンも確認する
3. 外部から取得したデータを圧縮解除する処理があるかを洗い出す。Content-Encoding: brを受け取るAPI呼び出し、node:zlibでの復号、Brotli展開を有効にしたプロキシ設定などが該当する
4. 対象バージョンに該当するものは、表の修正版以降へ更新する。コンテナはイメージの再ビルドと再配備が必要で、OSが提供する共有ライブラリを更新しただけでは、ソフトウェアの中に同梱されたコピーまでは直らない場合がある
5. すぐに更新できない場合は、リバースプロキシでContent-Encoding: brの受信を制限するなど、Brotli展開の経路を一時的に絞る方法がある。ただし正規の通信にも影響するため、適用前に確認が要る

まとめ

Node.jsの緊急更新として報じられたCVE-2026-111497は、Google Brotliのデコーダという1つのC言語コードが原因だった。そのコードをそのまま取り込んでいたNode.js・Python・Bun・Envoy/Istioに、同時に同じ脆弱性が見つかった。原因は、データの形式エラーをデコーダが「まだ入力が必要」な状態と取り違え、8バイトしかない内部バッファへの書き込みを止められなくなったことにある。

対応は単純だ。使っているランタイムやミドルウェアを表の修正版以降へ更新し、外部からの圧縮データを扱う処理があるかどうかを確認する。CISAの悪用済み脆弱性一覧には今のところ含まれておらず、落ち着いて対象を洗い出し、更新を済ませておける段階にある。