HTTP2Shellとは ―Node.jsやPythonに広がるBrotli脆弱性の影響と対策

Share
HTTP2Shell(CVE-2026-111497)とは?影響製品と対策を解説アイキャッチ画像

WebサイトやAPIの安全性を確認する際は、外部からのリクエストだけでなく、アプリケーションが受信するレスポンスにも注意が必要です。HTTP2Shell(CVE-2026-111497)は、GoogleのBrotliデコーダーに存在する脆弱性で、細工された圧縮データの展開によって、情報漏洩や任意コード実行につながるおそれがあります。Node2Shellとも呼ばれるこの問題は、Node.jsに加え、Python関連パッケージやBun、Envoyなど幅広い製品に影響します。本記事では、主な攻撃経路、影響を受ける製品、修正版と対策を解説します。

HTTP2ShellとNode2Shellの関係

Brotliは、Webコンテンツなどのデータを小さくするために使われる圧縮方式です。HTTP通信では、本文がBrotli形式で圧縮されていることをContent-Encoding: brというヘッダーで示します。本脆弱性は、当初Node.jsへの影響が注目されたことから「Node2Shell」と呼ばれていました*1。その後、Brotliを利用する複数の製品にも影響が及ぶことが明らかになり、「HTTP2Shell」という呼称も使われるようになりました。なお、名称にHTTPが含まれていますが、HTTP/2通信に限定された脆弱性ではありません。

問題があるのは、圧縮されたデータを元に戻すデコーダーです。不正なデータの処理を打ち切るべき場面で処理が続き、内部バッファの範囲を超えて書き込むことがあります。結果として、プロセスの停止やメモリ内の情報漏洩、条件によっては遠隔からの任意コード実行(RCE)につながります。

Googleが登録したCVEレコードの評価はCVSS v4.0で9.2、深刻度はCriticalです。一方、Node.jsの公式告知ではHighに分類されています*2。確認すべきなのは、脆弱なBrotliデコーダーを使用し、攻撃者が用意したデータがそこに届くかどうかです。

HTTPリクエストとレスポンスの両方が攻撃経路になる

受信側では、WebアプリケーションがBrotli圧縮されたリクエスト本文を展開する経路が問題になります。Impervaは、Express 5やbody-parser 2系でBrotli圧縮された本文を展開する構成で、細工したデータがNode.jsに内包されるデコーダーへ渡るケースを検証しています*3。⁠

もう一つは、アプリケーションがHTTPクライアントとして通信する経路です。Node.jsの組み込みfetchがBrotli圧縮された応答を展開すると、接続先のサーバーが返したデータがデコーダーに届きます。公開APIへの入力対策とあわせて、外部サイトから情報を取得する機能にも目を向ける必要があります。

図1:HTTP2Shellで確認する二つの攻撃経路

脆弱なBrotliデコーダーに細工されたデータが届く二つの攻撃経路を示した概念図
出典:Imperva, Inc.、Bunプロジェクトの公開情報をもとに作成。
※任意コード実行の成立条件は製品や構成によって異なります。

影響を受ける製品と修正版

影響調査では、開発言語の名前だけで範囲を区切らないことが大切です。Pythonの場合は、Python本体全体の問題として扱うのではなく、Brotliやbrotlicffiといったパッケージの導入状況を調べます。urllib3やrequestsなどは、これらのパッケージが利用できる環境でBrotli応答を自動展開するため、アプリケーションのコードにBrotliの呼び出しが見当たらなくても確認が必要です。

表1:主要コンポーネントの修正版と確認する条件

コンポーネント修正版確認する条件
Google Brotli1.0.10/1.1.1/1.2.11.0.3~1.0.9、1.1.0、1.2.0
Node.js22.23.4/24.22.1/26.12.1各系列の未修正版。内包するデコーダーの利用経路を確認
Python関連パッケージBrotli 1.2.1
brotlicffi 1.2.1.0
仮想環境やコンテナーごとの導入状況を確認
Bun1.4.41.0.21以上1.4.4未満。コンパイル済み実行ファイルも確認
Envoy1.40.0/1.39.3/1.38.6/1.37.8/1.36.12Brotli展開フィルターを設定した環境
Istio1.31.2/1.30.6/1.29.9Brotli展開を有効にした環境。1.29系はサポート終了
出典:Google LLC、Node.jsプロジェクト、GitHub Advisory Database、Bunプロジェクト、Envoy Proxyプロジェクト、Istioプロジェクトをもとに作成。
※主要コンポーネントの修正版と確認条件を整理しています。バージョン番号は各開発元の公表値です。影響製品を網羅したものではなく、利用環境に応じて各製品の公式情報を確認してください。

EnvoyではBrotliの展開フィルターを設定した環境、IstioではEnvoyFilterなどを使ってBrotli展開を有効にした環境が確認対象です。製品名が一致するだけで、すべての構成が同じ攻撃経路を持つとは限りません。反対に、別製品に内包されたライブラリは、アプリケーションの依存パッケージ一覧だけでは見落とすおそれがあります。

コード実行の実証と実際の攻撃を分けて読む

Impervaは、公式のNode.js 24.22.0のLinux arm64イメージを用いた実験で、細工したBrotliデータによるコード実行を報告しています。修正版の24.22.1では同じ入力が拒否されました。ただし、実験環境では成功まで複数回の試行を要しています。この結果を、すべてのOSや構成で同じ攻撃が成立するという意味に広げることはできません。

また、研究環境での実証は、実際の組織に対する攻撃成功の報告とは別です。CVEレコードに収録されたCISAの評価では、2026年10月23日時点のExploitation(悪用状況)が「none」とされています。ただし、これは評価時点の情報であり、その後の悪用の有無を保証するものではありません。修正の優先順位は、被害報告の有無だけでなく、自社環境で攻撃者が用意したデータが脆弱な展開処理へ届くかどうかを踏まえて判断する必要があります。

Go向けBrotli実装にも関連する報告があります。Sweet Securityはv1.2.6でpanicと接続切断を再現しましたが、その実験ではアプリケーション全体は動作を続けていました。Go実装で任意コード実行やプロセス全体の停止が実証されたわけではありません*4。メンテナーは10月23日に修正コミット33c2a98による対応を報告しています*5。

更新する対象を実行環境まで追う

Node.jsを使う環境では、Brotliを内包するNode.jsランタイムそのものを更新する必要があります。Pythonでは仮想環境ごとにパッケージを確認し、コンテナーを使っている場合は、更新後の構成でイメージを再ビルドして再配置します。管理画面に表示された設定値だけでなく、稼働中のプロセスに修正が反映されていることまで確認します。

Bunでは、bun build –compileで作成した実行ファイルにランタイムが埋め込まれます。開発端末のBunを更新しても、すでに配布した実行ファイルは自動では直りません。公式告知はBun 1.4.4への更新と、該当する実行ファイルの再ビルドを求めています*6。製品に組み込まれたBrotliを修正するには、製品側の更新が必要になる点に注意してください。

図2:影響確認から修正の反映までの流れ

影響確認から修正版の適用までの対応を整理した概念図
出典:Node.jsプロジェクト、Aikido Security BV、Bunプロジェクト、Envoy Proxyプロジェクトの公開情報をもとに作成。
※暫定対策は修正版への更新を代替するものではありません。

更新までの暫定対策では展開前に止める

すぐに更新できない場合は、脆弱なデコーダーにBrotli圧縮データが渡らないようにすることが暫定対策となります。受信リクエストでは、Brotli形式の本文を展開する前に拒否する方法があります。外部サイトからのレスポンスについても、Brotli展開を無効にするか、展開前に拒否できるかを確認します。送信するAccept-Encodingからbrを削除するだけでは、接続先がBrotli圧縮されたレスポンスを返す可能性を排除できません。

回避策の設定方法は製品によって異なります。Bunの公式告知では、fetchの呼び出しにdecompress: falseを指定する方法が示されていますが、その呼び出しだけに適用される設定です。ほかのBrotli展開処理まで一括して無効になるわけではありません。回避策の対象範囲を確認したうえで修正版へ更新してください。

HTTP2Shellへの対応では、公開Webサーバーの点検に加え、外部と通信するアプリケーションや製品内の依存ライブラリまで確認を進めます。Brotliを含む実行環境を洗い出し、攻撃者のデータが届く経路を確認したうえで、稼働中のプロセスに修正が反映されたことまで確かめてください。外部から細工されたBrotliデータを受信・展開する可能性があった環境では、修正版の適用に加え、不審なプロセスの異常終了や関連ログなどを確認し、侵害の兆候がないか調査することも重要です。

Webアプリケーションのセキュリティ対策を見直しませんか?

公開WebサイトやAPIの安全性を維持するには、利用するソフトウェアの更新に加え、アプリケーション全体の脆弱性を継続的に確認することが重要です。ブロードバンドセキュリティ(BBSec)では、Webアプリケーションの脆弱性診断を通じて、企業のセキュリティ対策を支援しています。

SQATWebアプリケーション脆弱性診断サービスページバナーリンク

【参考情報】

編集責任:木下

ウェビナー開催のお知らせ

最新情報はこちら


Security NEWS TOPに戻る
バックナンバー TOPに戻る