HTTP2Shellとは？HTTP/2ではなくBrotliの脆弱性が広がる理由

HTTP2Shellの正体は、共通の展開部品の弱点

別々のソフトウェアが、それぞれ一から圧縮処理を作っているとは限りません。共通のライブラリを取り込んで使えば、その部品の弱点も一緒に取り込むことになります。

圧縮する側と、展開する側を分ける

Brotliは、送るデータを小さくして通信量を減らすために使われます。受け取った側は、元の内容を読める形へ戻します。この「元に戻す」処理が展開で、その処理をする部品がデコーダです。

今回の欠陥は、このデコーダにあります。Node.jsの公式説明では、壊れた入力を形式エラーとして止めるべき場面で、まだデータが足りない状態だと誤判定し、内部の小さな領域へ書き込みを続けてしまいます。確保された範囲を越える書き込みによって、プログラムのメモリが壊れます。

つまり、「WebサイトでBrotli圧縮を使っている」という情報だけでは不十分です。データを圧縮して送り出すことと、外から届いたデータを展開することは、別の処理だからです。

コード実行の可能性と、被害の確認は別

メモリが壊れると、処理が停止したり、メモリの情報が漏れたり、条件によっては外部から送り込まれたコードが実行されたりするおそれがあります。最後の状態が、遠隔コード実行（RCE）です。

Impervaの研究チームは、公式のNode.js 24.22.0のLinux arm64環境でコード実行を実証し、24.22.1では同じ入力が拒否されたと報告しています。ただし、実験では複数回の試行が必要だったとされています。これは特定条件での実証であり、あらゆる環境が同じように侵害されるという意味ではありません。

また、Bunの公式告知は、Bunに対する攻撃実験は行っておらず、他のソフトと影響の出方を比較できないと説明しています。弱点が存在すること、コード実行が実証されたこと、実際の被害が確認されたことは、区別して読む必要があります。本記事は、個別サービスの侵害や情報漏えいを確認したものではありません。

深刻度の表示も一律ではありません。Node.jsはHigh、Envoyの告知はCVSS v4.0で9.2、Red Hatは自社環境の条件を踏まえてImportantとしています。評価主体や環境の違いを無視して、数字だけで自分の環境の危険度を決めることはできません。

入口は二つ。受信する側も、取りに行く側も対象

調べたいのは、インターネットから自分のサーバーへ届く通信だけではありません。自分のアプリが外部サイトを読み込むときにも、相手が返した圧縮データを展開する場合があります。

外から届くデータと、外へ取りに行くデータ

例えば、URLを入力するとページの概要を作るサービスを考えてみます。利用者から送られたURLへアプリがアクセスし、その応答を自動展開するなら、外部サーバーから届く内容も確認対象です。これは仕組みを理解するための例で、特定サービスでの被害事例ではありません。

Bunの告知は、fetchがContent-Encoding: brの応答を自動展開することや、展開APIに届くデータが対象になることを説明しています。brはBrotliの指定です。Envoyも、Brotliの展開機能が設定された環境を影響対象としています。

このため、入口に防御サービスを置いているだけでは、外へ取りに行った応答まで保護できるとは限りません。どこでデータを展開するかを、通信の両方向から追う必要があります。

「Pythonを使っている」だけでは判定できない

Pythonでも、Brotliを扱う追加パッケージを使う構成があります。brotlicffiの公式配布情報は、PythonからBrotliの圧縮・展開処理を利用するためのライブラリだと説明し、修正版で内蔵するlibbrotliを更新したと案内しています。

確認すべきなのは、Pythonという言語名だけではなく、実際に入っている追加部品と、外部データがそこへ届く経路です。自分で直接書いたコードだけでなく、利用するライブラリや配布パッケージの中身も確認対象になります。

主な修正版と、番号だけでは分からないこと

以下は2026年10月25日に一次情報を照合した、主な修正版です。各系列でこの問題を修正した版を示しており、今後も使い続ける版を固定するための一覧ではありません。実際の更新では、提供元が現在推奨するサポート対象版を選びます。

製品を網羅した一覧ではありません。クラウドやホスティングを利用している場合は、契約しているサービスの告知と管理範囲も確認します。

同梱された部品と、OSの部品は別に確認する

OSの共通ライブラリを更新しても、アプリが別のコピーを内蔵していれば、そのアプリには修正が届かない場合があります。Bunの告知も、旧版で作った単体実行ファイルは、修正版を使って作り直すまで影響が残ると説明しています。

一方、OSの配布元が、元の版番号を大きく変えずに修正だけを取り込むこともあります。これがバックポートです。Red Hatは、こうした配布方針のため、版番号だけを見るスキャナーと配布元の判定が異なる場合があると案内しています。

「番号が古いから必ず未修正」「OSを更新したから全部直った」のどちらも、確認を省く理由にはなりません。配布元の修正情報と、実際に動いているコピーを対応させることが必要です。

利用者と運営者で、最初にすることは違う

一般利用者が、使っているサービスの内部部品をすべて調べることはできません。自分で更新できるソフトと、提供会社が管理する部分を分けると、次の行動が明確になります。

一般利用者は公式の更新とサービス告知を確認する

利用中のアプリについては、その提供元が案内する正式な更新を適用します。Webサービスについては、運営者の障害・メンテナンス・セキュリティ告知を確認します。脆弱性の名前を見ただけで、自分のアカウントやデータに被害が出たとは判断できません。

会社や委託先へ確認するときは、「CVE-2026-111497の影響対象か」「対象なら修正版の適用予定はいつか」「利用者に必要な操作があるか」の3点を伝えると話が通じやすくなります。これは本記事で整理した確認例です。

運営者は、展開経路から稼働環境まで追う

管理する側は、ソフトの名前を見つけた段階で終わらず、次の順で確認します。優先するのは、外部の相手が用意したBrotliデータを展開する場所です。

1. どの部品が入っているか
   ランタイム、追加パッケージ、プロキシ、コンテナ、配布済みの単体実行ファイルを整理します。
2. どの外部データを展開するか
   受信する要求と、取得する応答の両方を追い、展開を担当するプロセスを特定します。
3. 提供元の修正を反映する
   各製品の告知に沿って更新し、必要な再ビルド・再配布・再起動を行います。
4. 実際に動く環境を確認する
   手元の開発環境だけでなく、本番の各インスタンスへ修正版が反映され、通常の処理も動くことを確かめます。

この手順は、公式告知にある更新対象と条件を踏まえた実務上の整理です。構成によって担当範囲は異なります。ホスティング会社が管理するOSと、自分が配布するアプリのランタイムが別管理なら、両方の対応を確認します。

更新までの対策は「展開させない」設定まで確かめる

すぐ更新できない場合には、信頼できないBrotliデータを展開する経路を一時的に止めることが、危険を減らす方法になります。具体的な設定は、利用する製品の公式案内に従います。

ここで注意したいのが、HTTPヘッダーの設定です。「Brotliを送ってほしい」と要求しないことと、相手が送ってきたBrotliを展開しないことは同じではありません。Bunの告知は、fetchのdecompress: falseで、その取得処理の自動展開を止める方法を案内していますが、プロセス全体に効く回避策ではないとも明記しています。

入口でBrotliを拒否しても、別の外部取得や直接の展開APIが残っていれば、その経路の確認は必要です。暫定対策が効く範囲を記録し、修正版への更新を進めます。

今回の話題から覚えておきたいのは、同じ部品を使うソフトでも、データが届く経路と、修正が届く経路はそれぞれ違うということです。この二つを分けると、製品名が増えても確認する筋道を保てます。