HTTP2Shell とは｜node2shellの正体は上流Brotliの問題、HTTPでBrotliを展開する多くのライブラリに波及

HTTP2Shell とは何か。先に広まった node2shell（Node.js の Brotli デコーダの RCE・CVE-2026-111497）が「進化した」と報じられましたが、正確には新しい脆弱性ではありません。分かったのは、そのバグが Node.js 固有ではなく、上流の Brotli ライブラリ（google/brotli）にあること、そして HTTP で Brotli を展開する多くのライブラリ・言語に及ぶ、という影響範囲の広さです。この広さを、セキュリティ企業 Aikido が HTTP2Shell と名付けました。名前は node2shell→http2shell の語呂で、HTTP/2 というプロトコルとは関係ありません。依存する部品の問題が横に広がる構図はサプライチェーン攻撃とは｜手口・防御ツール比較・npm 12の新機構まで実践解説にもまとめています。この記事は、何が広いのか・どこが露出するか・何をどこまで上げればよいかを、実機点検つきで整理します。

HTTP2Shell とは：node2shell の正体は「上流 Brotli ライブラリ」だった

最初に広まった node2shell は、「Node.js が同梱する Brotli デコーダに境界外書き込みがあり、細工した Brotli でリモートコード実行に至りうる（CVE-2026-111497）」という、Node.js を主役にした捉え方でした。Node2shell の記事でも、fetch や Express 経由の露出と Node の更新を中心にまとめています。

その後にはっきりしたのは、問題の本体が Node.js ではなく、その内部で使っている上流の Brotli ライブラリ（google/brotli）にあることです。影響する Brotli の版は 1.0.3〜1.2.0で、修正版は 1.0.10・1.1.1・1.2.1です。Node.js はこの Brotli を同梱しているので影響を受けましたが、同じ Brotli を同梱・利用するものは Node.js だけではありません。だから「Node の話」から「Brotli を使う HTTP スタック全般の話」へと、見え方が広がりました。これを Aikido が HTTP2Shell と名付けた、という経緯です。深刻度は、Node.js プロジェクトは High としていますが、CVE 記録では Critical（CVSS 3.1 で 9.8）とされています。実環境での悪用は、現時点で報告されていません。

なぜ多くの HTTP ライブラリ・言語に及ぶのか

理由はシンプルで、1つの上流ライブラリを、たくさんのランタイムやライブラリが内部に取り込んでいるからです。これは、1つの認証局のつまずきが各言語に波及したeMudhra の件と同じ「1つの共通部品、大きな影響範囲」の形です。

ポイントは、自分のコードに穴が無くても、使っているランタイムやライブラリが同梱・利用する Brotli の問題で露出しうること。そして、同梱しているものがそれぞれ上流の修正版を取り込まないと直らない、という点です。

Brotli は HTTP の圧縮方式として広く使われているため、理屈のうえでは Node.js や Bun に限らず、攻撃者が制御できる Brotli を展開するあらゆる HTTP クライアント・サーバーが対象になりえます。だからこそ Aikido は「多くのライブラリとアプリケーションに影響する」と表現し、HTTP2Shell と呼びました。とはいえ、実際に露出するかは「そのコードが信頼できない Brotli を展開しているか」で決まるので、名前の派手さに引きずられず、自分の経路を落ち着いて確かめることが大切です。なお、影響を受ける全てに修正が出そろっているわけではない段階なので、使っている部品の更新情報は継続して追う必要があります。

どこで攻撃者の Brotli が展開されるか

実害を左右するのは、「攻撃者が制御できる Brotli を、アプリが知らないうちに展開するか」です。

・Express 5・body-parser 2.x：json()・urlencoded()・text()・raw() が、要求ボディの Brotli を展開します
・Koa のボディパーサ：要求ボディの Brotli を展開します
・@fastify/compress：要求の展開を有効にしている場合に対象です
・組み込み fetch()：応答の Brotli を既定で展開します。攻撃者が内容に影響できる URL を取得しているコードも対象です

逆に、素の Node HTTP サーバー（フレームワーク無しで http を使うだけ）は、受信した Brotli を自動展開しません。「要求や応答で Brotli を自動展開しているか」が、露出を見分ける最初の問いです。

直す：Brotli を上流の修正版へ（npm の brotli ではない）

直す対象は、ランタイムやライブラリが同梱・利用している上流の Brotliです。Node.js なら本体を 22.23.4 / 24.22.1 / 26.12.1 以上へ上げれば、同梱 Brotli が修正版に差し替わります。いちばん間違えやすいのが、npm にある brotli という名前のパッケージを上げてしまうことです。これは今回の脆弱な部品ではなく、上げてもランタイムの同梱 Brotli は変わりません。確認は版の比較で、環境ごとに見ます。

# Node の版（修正版 22.23.4 / 24.22.1 / 26.12.1 以上か）
node --version

# Node が同梱する Brotli の版を直接見る（1.0.10 / 1.1.1 / 1.2.1 以上なら対応済み）
node -p "process.versions.brotli"

これは判定ではなく構成の確認で、この結果だけでは安全とは言えません。利用しているライブラリが独自に Brotli を展開している場合など、この2つだけでは拾い切れないからです。確実なのは、各環境でランタイムを修正版へ上げ切ることです。

まとめ：1つの上流ライブラリ、大きな影響範囲

HTTP2Shell という派手な名前がついていますが、中身は「node2shell と同じ Brotli のバグが、Node.js だけでなく、その Brotli を同梱・利用する多くの HTTP スタックに及ぶ」という話です。新しい脆弱性でも、HTTP/2 の問題でもありません。重要なのは、1つの上流ライブラリを多くのものが取り込んでいると、その1つの不具合が一気に広がること、そして同梱している各自が上流の修正版を取り込まないと直らないことです。

やることは派手ではなく、ランタイムとライブラリを修正版へ上げ切ること、そして影響を受ける部品の更新情報を追い続けることです。同じ「ランタイムの処理が入口になる」構図はNode2shellやRuby の Onigmo の件とも地続きで、使っている基盤を最新に保つことが、結局いちばん効く備えになります。

参照ソース

・Node2Shell evolves into HTTP2Shell（Aikido） — HTTP2Shell の命名と影響範囲（研究元・2026-10-24 確認）
・node2shell (CVE-2026-111497): What to Patch and How to Find Exposed Services（Cycode） — 影響する Brotli の版・Express/Koa/Fastify の露出・npm の brotli は別物
・Node.js October 2026 Security Releases（公式ブログ） — CVE-2026-111497 と Node の修正版
・Node2shell（Node.js 同梱 Brotli デコーダのRCE・当サイト） — Node を主役にした捉え方と fetch/Express の露出