CVE-2026-111497（HTTP2Shell）とは
Brotliデコーダの境界外書き込みの問題
CVE-2026-111497は、Googleが開発した圧縮アルゴリズム・ライブラリであるBrotliのC言語実装に見つかった重大な脆弱性です。GHSA-9v8h-qqgm-4m35にも関連付けられており、主にBrotliデコーダの実装ファイルであるc/dec/decode.cに起因します。
問題は圧縮処理ではなく、Brotli形式のデータを元に戻す展開処理にあります。細工されたBrotli圧縮データをデコーダが処理すると、確保されたバッファの範囲外へデータを書き込む「境界外書き込み（out-of-bounds write）」、いわゆるバッファオーバーフローが発生する可能性があります。
攻撃者は悪意ある圧縮データを対象のアプリケーションやプロキシに展開させることで、プロセスの異常終了やメモリ破壊を引き起こすおそれがあります。そのため、Brotliを直接利用しているかどうかだけでなく、HTTPクライアント、言語ランタイム、ミドルウェアなどを介してBrotliデコードが行われていないかを確認することが、Brotliの脆弱性への対応では重要です。
Node2Shell・HTTP2Shellと呼ばれる背景
CVE-2026-111497は、当初「Node2Shell」と呼ばれていました。これは、Node.jsが早期に修正版を公開したことから、最初はNode.js固有の脆弱性として広く認識されたためです。Node.jsでは、受信した圧縮リクエストの処理や、fetchによる外部HTTPレスポンスの受信時などに、意図せずBrotli展開処理が実行される可能性があります。
その後の調査で、原因はNode.js独自のコードではなく、Node.jsを含む多くのソフトウェアが利用する上流のBrotliライブラリにあることが明らかになりました。Python、Bun、Envoy Proxy、Istio、HTTPクライアントライブラリ、OSパッケージなどにも影響が広がり得ることから、「HTTP2Shell」という名称が使われるようになりました。一部では「Broccoli2Shell」と呼ばれることもあります。
HTTP2Shellという名称は、BrotliがWeb通信、特にHTTPSで配信されるコンテンツの圧縮に広く利用されていることを表しています。名称だけでNode.js環境やWebサーバーだけの問題と判断せず、組織内に存在するBrotliデコーダー全体を調査対象とする必要があります。
HTTP/2自体の脆弱性ではない点
HTTP2Shellは、HTTP/2プロトコルそのものに存在する脆弱性ではありません。HTTP/2を使用しているという理由だけで、すべてのWebサイト、API、プロキシ、アプリケーションが影響を受けるわけではありません。
脆弱性の本質は、Brotliで圧縮されたデータを展開する際のデコーダ処理です。HTTPレスポンスでは、Content-Encoding: brが付与されている場合に、その内容がBrotliで圧縮されていることを示します。脆弱なBrotliデコーダーが、このようなデータを処理することがリスクの前提となります。
したがって、Brotliの脆弱性に対する対応では、HTTP/2の有効・無効だけを確認しても十分ではありません。HTTP/1.1、HTTP/2、あるいはHTTP以外のデータ処理であっても、攻撃者が制御できるBrotli圧縮データを展開する経路があれば影響を受ける可能性があります。外部から圧縮リクエストを受けるインバウンド通信に加え、外部APIやURLから圧縮レスポンスを取得するアウトバウンド通信も確認が必要です。
想定される影響：サービス停止からコード実行まで
CVE-2026-111497が悪用された場合、もっとも起こりやすい影響として、対象プロセスのクラッシュやサービス拒否（DoS）が考えられます。細工されたBrotliデータを処理したアプリケーション、プロキシ、サービスメッシュなどが異常終了すれば、サービス停止や可用性の低下につながります。
一方で、境界外書き込みは単なる停止にとどまらず、メモリ上のデータや制御情報を破壊する可能性があります。状況によっては、メモリ内容の漏えい、機密情報の読み取り、任意コード実行、リモートコード実行（RCE）へ発展するリスクがあります。GoogleのCVEレコードではCVSS v4.0の深刻度が9.2でCriticalとされており、認証なしでリモートから悪用され得る点にも注意が必要です。
特に優先度を上げて調査すべきなのは、信頼できない送信元からBrotli圧縮データを受け取るシステムです。また、外部サイトやAPIにアクセスし、応答を自動展開するバックエンドサービス、CI/CD環境、開発ツールも攻撃経路になり得ます。Brotliを明示的に使用していない場合でも、ランタイムや依存ライブラリが背後で展開している可能性があるため、CVE関連の情報とベンダーアドバイザリーを確認しながら、実際のデコード経路を基準に影響判定と対応を進めることが重要です。
影響を受けるBrotliのバージョンと修正版
影響範囲となるバージョン系列
CVE-2026-111497（HTTP2Shell）に関するBrotliの脆弱性は、C言語実装のBrotliデコーダーに存在する境界外書き込みの問題です。CVEの記録では、影響を受けるバージョンはBrotli 1.0.3から1.2.0までとされています。そのため、1.0系、1.1系、1.2系を使用している場合は、単にメジャー番号やマイナー番号だけで安全と判断せず、個別のパッチバージョンまで確認する必要があります。
特に注意したいのは、Brotliを明示的に導入していない環境です。Node.js、Python、Bun、Envoy Proxy、Istioなどのランタイムや製品には、Brotliのライブラリが内蔵または依存関係として含まれていることがあります。アプリケーションの依存パッケージ、OSパッケージ、静的リンクされたバイナリ、コンテナのベースイメージに含まれるBrotliも、HTTP2Shell対応の調査対象です。
修正版1.0.10・1.1.1・1.2.1の確認
Google Brotliの修正版として示されているのは、1.0系では1.0.10、1.1系では1.1.1、1.2系では1.2.1です。Brotliの脆弱性に対する基本的な対応は、使用中の系列に応じてこれらの修正版、またはそれ以降の安全なリリースへ更新することです。
たとえば、Brotli 1.0.3から1.0.9を使用している場合は1.0.10以上へ、1.1.0を使用している場合は1.1.1以上へ、1.2.0を使用している場合は1.2.1以上へ更新します。ただし、利用者が直接Brotliライブラリを管理していないケースも多いため、実際にはBrotliを含む製品・ランタイムの修正版へ更新する必要があります。
代表例として、Node.jsでは22.23.4、24.22.1、26.12.1がCVE-2026-111497の修正を含むバージョンです。PythonではBrotli 1.2.1、brotlicffi 1.2.1.0、Bunでは1.4.4が修正版として案内されています。Envoy ProxyやIstioを利用している場合も、それぞれのベンダーが示す修正版を確認し、Brotli本体の番号だけで判定しないことが重要です。
ベンダーバックポートを含めた判定方法
OSディストリビューションや製品ベンダーは、Brotliのバージョン番号を大きく変更せず、脆弱性修正だけを既存パッケージへ取り込む「バックポート」を行うことがあります。この場合、表示上の上流バージョンが1.0.10、1.1.1、1.2.1未満であっても、ベンダーのパッチによりCVE-2026-111497へ対応済みである可能性があります。
したがって、Brotliの脆弱性の影響判定では、単純なバージョン比較だけに依存してはいけません。利用中のOS、クラウド提供イメージ、コンテナベースイメージ、ミドルウェア、言語ランタイムについて、ベンダーのセキュリティアドバイザリー、更新履歴、変更履歴を確認してください。パッケージのリリース番号、ディストリビューション固有のリビジョン、セキュリティ修正の識別子にCVE-2026-111497が記載されているかを確認する方法が有効です。
一方で、独自ビルドしたBrotli、アプリケーションにソースコードをコピーして組み込んだ実装、静的リンクされたライブラリは、OSベンダーのバックポートでは保護されません。SBOM、依存関係一覧、ビルド定義、バイナリ解析結果などを使い、どのBrotli実装を実際に利用しているかを確認する必要があります。
OSパッケージの更新情報を確認する重要性
Linuxサーバーやコンテナでは、OSパッケージとして導入されたBrotliライブラリが使われている場合があります。このため、アプリケーションの更新だけでなく、利用中のディストリビューションが公開するセキュリティ更新情報を確認し、該当パッケージを更新することがHTTP2Shell対応では欠かせません。
確認対象はBrotli本体に限りません。libbrotliに相当する共有ライブラリ、開発用パッケージ、Brotliを依存関係として取り込むHTTPクライアント、プロキシ、言語ランタイムなども確認します。また、パッケージを更新しても、すでに起動しているプロセスは古い共有ライブラリをメモリ上に読み込んだままの場合があります。更新後はサービスの再起動、ワーカーの入れ替え、コンテナの再作成を行い、稼働中のプロセスが修正版を利用していることまで確認してください。
特にコンテナ環境では、ホストOSを更新してもコンテナ内のBrotliは更新されません。レジストリ上のベースイメージを更新したうえで、アプリケーションイメージを再ビルドし、新しいイメージを再デプロイする必要があります。Brotli 応対を「パッケージ更新の実施」で終わらせず、実行中のバイナリ、コンテナ、プロセスまで含めて検証することが、CVE関連の脆弱性対応では重要です。
影響範囲はどこまで広がるか
CVE-2026-111497（HTTP2Shell）への対応では、「Brotliを導入しているか」だけでなく、「どの経路でBrotli圧縮データを展開しているか」を確認することが重要です。問題は圧縮処理ではなくデコーダーに存在するため、外部から受信したデータや外部サービスから取得したレスポンスを展開するソフトウェアが主な調査対象となります。アプリケーションがBrotliを明示的に利用していない場合でも、言語ランタイム、HTTPクライアント、プロキシ、サービスメッシュなどが内部で展開している可能性があります。
Brotliを展開する処理が主な対象
HTTP2Shellの脆弱性は、細工されたBrotli圧縮データをデコーダーに渡した際に発生する境界外書き込みです。そのため、Brotliでコンテンツを圧縮して配信するだけの処理よりも、Content-Encoding: brが付いたHTTPリクエストやレスポンス、ファイル、独自プロトコル上の圧縮データを展開する処理が主な対象です。
調査時には、インターネットからBrotli圧縮リクエストを受け取るインバウンド通信だけを確認してはいけません。アプリケーションが外部URL、API、パッケージリポジトリなどへ接続し、攻撃者が制御し得るBrotli圧縮レスポンスを受信するアウトバウンド通信も攻撃経路になり得ます。信頼できない送信元のデータを展開する機能を優先し、Brotliの脆弱性に関する影響調査を進める必要があります。
Node.js・Bun・Pythonなどの実行環境
Node.js、Bun、Pythonなどの実行環境は、アプリケーションの依存関係や標準的なHTTP処理を通じてBrotliデコーダーを利用する可能性があります。特にNode.jsは当初「Node2Shell」とも呼ばれた経緯があり、Node.js固有の問題と誤解されがちです。しかし、原因は上流のBrotliライブラリにあるため、Node.js以外の実行環境も確認しなければなりません。
Node.jsでは、Express 5などで使用されるbody-parser 2.xがBrotli圧縮されたリクエストボディを展開する場合や、fetchがHTTPS経由でBrotli圧縮レスポンスを受信する場合があります。アプリケーションコードにBrotliの直接利用が見当たらなくても、既定のHTTP処理によって脆弱な展開経路が生じる可能性があります。Node.jsを使用している場合は、CVE-2026-111497の修正を含む22.23.4、24.22.1、26.12.1など、利用中のサポート対象系列に対応した修正版を確認します。
Bunでは1.4.4、PythonではBrotli 1.2.1およびbrotlicffi 1.2.1.0が修正版として示されています。Pythonは直接Brotliパッケージを利用しているケースに加え、HTTPクライアントや他の依存ライブラリがBrotliを取り込んでいるケースも確認対象です。仮想環境、CI/CDジョブ、バッチ処理、開発環境など、本番サーバー以外で動くランタイムも含めて棚卸しすることが、Brotliの脆弱性への適切な対応につながります。
.NET・PHP・HTTPクライアントライブラリ
.NET、PHP、Javaなどのアプリケーションでも、HTTP通信機能や外部ライブラリを通じてBrotliを展開している可能性があります。重要なのはプログラミング言語そのものではなく、実際に読み込まれるHTTPスタック、ネイティブライブラリ、バンドル済みコンポーネントが脆弱なBrotliデコーダーを含むかどうかです。
たとえば、外部APIを呼び出すバックエンド処理、Webスクレイピング、Webhookの受信、ファイル取得機能、ソフトウェア更新確認などでは、HTTPクライアントライブラリが圧縮レスポンスを自動展開することがあります。curlやlibcurlを利用するプログラムも、ビルド時の機能やリンク先ライブラリ、Brotli対応設定を確認する必要があります。OSパッケージの更新状況だけで判断せず、静的リンクされたライブラリやアプリケーションに同梱されたBrotliコピーも調査対象に含めます。
PHPや.NETの実行環境では、フレームワーク、拡張モジュール、HTTP SDK、コンテナベースイメージのいずれが展開を担うかを特定してください。特に、外部データを取得する非同期ワーカーやバックグラウンドジョブは、Webサーバーの設定確認だけでは見落としやすい箇所です。
Envoy・Istioなどのプロキシとサービスメッシュ
Envoy ProxyやIstioは、アプリケーションの前段またはサービス間通信に配置されるため、Brotliの展開機能が有効な場合は広い影響範囲を持ちます。アプリケーション本体を更新しても、サイドカー、Ingress Gateway、Egress Gateway、APIゲートウェイなどに脆弱なBrotliが残っていれば、HTTP2Shellへの対応は完了しません。
Envoy Proxyでは1.40.0、1.39.3、1.38.6、1.37.8、Istioでは1.31.2、1.30.6、1.29.9が修正版として示されています。ただし、Istio 1.29系はサポート終了済みとされるため、単に同系列の最終版へ上げるのではなく、サポート対象の1.30系以降へ移行する判断も必要です。
確認時には、クラスタ全体のコントロールプレーンだけでなく、各ワークロードに注入されたサイドカーイメージ、Gatewayのデプロイメント、独自にビルドしたEnvoyイメージを確認します。サービスメッシュでは同一クラスタ内に複数世代のプロキシが混在することがあるため、設定ファイル上のバージョンではなく、実際に稼働しているPodとコンテナイメージのバージョンを確認することが重要です。
WebサーバーやCDNの設定で確認すべき点
Webサーバー、リバースプロキシ、WAF、CDNについては、Brotli圧縮を有効にしているだけで直ちに脆弱と判断するのではなく、圧縮データを受信・展開する設定や処理経路を確認します。HTTP2ShellはHTTP/2プロトコル自体の脆弱性ではないため、HTTP/2を有効にしていることだけを理由に影響ありとは判断できません。一方で、HTTP/2やHTTPS通信でContent-Encoding: brを扱う構成では、Brotli展開がどこで実行されるかを把握する必要があります。
具体的には、クライアントからの圧縮リクエストボディを受け付けるか、CDNやWAFがオリジンへ送る前にコンテンツを展開するか、オリジンまたはバックエンドが外部から取得した圧縮レスポンスを処理するかを確認します。また、CDNやクラウドサービスを利用している場合は、事業者側がBrotliデコーダーを利用する機能の修正状況を公開情報やサポート窓口で確認してください。
Webサーバー設定だけでなく、背後のアプリケーション、プロキシ、コンテナ、HTTPクライアントまでを一連のデータ経路として確認することが大切です。Brotliの脆弱性への対応では、「どの製品がBrotliを圧縮しているか」よりも、「どのコンポーネントが攻撃者の制御下にあるBrotliデータを展開し得るか」という観点で影響範囲を整理します。
コンテナ環境で見落としやすい影響
CVE-2026-111497（HTTP2Shell）への対応では、アプリケーションのソースコードやホストOSだけを確認しても十分ではありません。コンテナ環境では、ベースイメージ、言語ランタイム、OSパッケージ、静的リンクされたバイナリ、依存パッケージなど、複数の場所にBrotliデコーダーが含まれる可能性があります。
特に問題となるのは、Brotliを明示的に利用していないアプリケーションでも、HTTPクライアント、Webフレームワーク、プロキシ、サービスメッシュなどがBrotli圧縮データを自動展開するケースです。Brotliの脆弱性に対する対応では、イメージを更新した事実だけでなく、稼働中のコンテナが修正版のBrotliを実際に利用していることまで確認する必要があります。
ベースイメージに含まれるBrotliライブラリ
Dockerfileで直接Brotliをインストールしていなくても、Ubuntu、Debian、Alpine LinuxなどのベースイメージにBrotliライブラリや関連パッケージが含まれている場合があります。たとえば、OSパッケージとして導入されたBrotliを、Node.js、Python、curl、Envoyなどのソフトウェアが利用している可能性があります。
このため、アプリケーションの依存関係だけではなく、ベースイメージのディストリビューション、タグ、パッケージ更新状況を確認することが重要です。ただし、上流のGoogle Brotliにおけるバージョン番号だけで脆弱性の有無を判断してはいけません。Linuxディストリビューションでは、独自のパッケージ番号のままセキュリティ修正をバックポートすることがあるためです。各ベンダーのセキュリティアドバイザリーやパッケージ更新情報で、CVE-2026-111497への対応状況を確認してください。
また、タグが同じイメージでも取得時期によって内容が変わる場合があります。以前に取得してローカルキャッシュや社内レジストリに保存されたベースイメージを使い続けていると、Dockerfileを変更していなくても古いBrotliライブラリを含むイメージを再利用してしまうおそれがあります。
アプリケーションにバンドルされた依存関係
コンテナ内のBrotliはOSパッケージだけとは限りません。Node.jsのランタイム、PythonのBrotliやbrotlicffi、Bun、HTTPクライアントライブラリなどが、Brotliのソースコードやネイティブライブラリをアプリケーション側へ同梱していることがあります。こうした依存関係は、OSのパッケージ更新だけでは修正されません。
たとえばNode.jsコンテナでは、Node.js本体の修正版への更新が必要です。CVE-2026-111497への修正を含むNode.js 22.23.4、24.22.1、26.12.1などへ更新していない場合、OSのBrotliパッケージを更新済みでもHTTP2Shellの影響が残る可能性があります。Pythonでは、Brotli 1.2.1、brotlicffi 1.2.1.0への更新状況を確認します。
依存関係を確認する際は、マニフェストファイルだけでなく、コンテナ内に実際にインストールされたパッケージとバイナリを対象にしてください。ロックファイル、言語パッケージマネージャーの一覧、アプリケーション配布物、ネイティブアドオン、静的リンク済みバイナリを横断して確認することが大切です。
さらに、アプリケーションが外部URLへアクセスする場合は注意が必要です。外部APIやWebサイトから受信したContent-Encoding: brのレスポンスを、HTTPクライアントやランタイムが自動展開することがあります。インバウンドのHTTPリクエストを受けないバッチ処理やバックエンドサービスであっても、アウトバウンド通信を通じて脆弱なBrotliデコーダーが攻撃対象になる可能性があります。
マルチステージビルドで残る古いコンポーネント
マルチステージビルドは、最終イメージを小さくできる有効な手法ですが、HTTP2Shell対応においては各ステージの確認が必要です。ビルドステージで古いBrotliライブラリを使ってコンパイルした場合、最終ステージへコピーした実行ファイルに脆弱なコードが静的リンクされている可能性があります。
また、ビルド成果物とともに共有ライブラリ、Pythonの仮想環境、Node.jsのnode_modules、キャッシュ済みのパッケージ、独自ビルドしたツールをコピーしているケースもあります。この場合、最終ステージのOSパッケージが最新でも、コピーされた成果物の中に古いBrotli実装が残ることがあります。
対応時には、最終ステージのベースイメージを更新するだけでなく、ビルドステージも修正版へ更新し、キャッシュに依存せずに再ビルドしてください。特に、--cache-fromを使うCI/CD、社内パッケージキャッシュ、長期間更新されていないビルダーイメージでは、古いコンポーネントが再利用されやすいため注意が必要です。
稼働中コンテナとレジストリ上のイメージを分けて確認する
レジストリに修正版イメージを登録しただけでは、Brotliの脆弱性への対応は完了しません。すでに起動しているコンテナ、古いReplicaSetやDeployment、ローリング更新から取り残されたPod、ジョブ実行用コンテナ、CI/CDワーカーなどが、脆弱なイメージを使い続けている可能性があります。
確認は少なくとも「レジストリ上に存在するイメージ」と「現在稼働しているコンテナ」の二段階で行います。前者では、タグだけでなくイメージダイジェストを基準に、修正版が格納されているかを確認します。後者では、実際に起動中のコンテナがどのイメージダイジェストから作成され、どのNode.js、Python、Bun、Envoy、Brotliライブラリを読み込んでいるかを確認します。
latestや環境名だけの可変タグでは、修正版へ切り替わったかを正確に追跡しにくくなります。イメージダイジェスト、ビルド日時、SBOM、デプロイ記録を関連付け、修正済みイメージが本番環境へ展開されていることを確認する運用が有効です。更新後にはコンテナを再作成し、旧コンテナや旧ワーカーが残っていないことも確認してください。
SBOMと脆弱性スキャンの活用
SBOM（Software Bill of Materials）は、コンテナイメージに含まれるOSパッケージ、言語パッケージ、ライブラリ、バイナリなどを一覧化するための情報です。CVE-2026-111497のように影響範囲が広い脆弱性では、SBOMを使ってBrotli関連コンポーネントを横断検索できるようにしておくと、調査を迅速化できます。
脆弱性スキャンでは、brotli、libbrotli、Node.js、PythonのBrotliおよびbrotlicffi、Bun、Envoy、Istioなどを確認対象に含めます。ただし、スキャン結果が「検出なし」だったとしても、静的リンク、ソースコードの同梱、独自ビルド、パッケージ情報が存在しないバイナリまで完全に判定できるとは限りません。
そのため、スキャン結果はベンダーアドバイザリー、ビルド定義、ロックファイル、実行中プロセスの確認と組み合わせて評価することが重要です。特に、信頼できない送信元からBrotli圧縮データを展開する経路、外部サイトから圧縮レスポンスを取得する経路、プロキシやサービスメッシュでHTTP通信を処理する経路を優先してください。
コンテナのBrotli 応対では、「修正版を含むイメージを作成した」ことと、「脆弱なコンテナが稼働していない」ことを分けて管理する必要があります。SBOMと継続的な脆弱性スキャンを活用し、イメージ、レジストリ、実行環境を一体で管理することが、HTTP2Shell関連のCVEに対する実効性のある対策になります。
自組織が影響を受けるか調べる手順
Brotliの利用箇所を資産台帳から洗い出す
CVE-2026-111497（HTTP2Shell）への対応では、最初にBrotliを使用している資産を網羅的に洗い出します。対象は、Brotliを直接導入したサーバーだけではありません。Node.js、Python、Bun、Envoy Proxy、Istio、.NET、Java、curlやlibcurlを利用するアプリケーション、Git for Windows、Electronアプリ、開発者向けツールなども確認対象です。
CMDBや資産台帳、SBOM、コンテナレジストリ、CI/CDの定義、クラウド上のワークロード一覧を突き合わせ、OS、実行環境、プロキシ、サービスメッシュ、バッチ処理、開発端末を含めて棚卸しします。特に、Brotliライブラリを製品内部に同梱しているケースや静的リンクしているケースでは、OSパッケージの一覧だけでは検出できないため注意が必要です。
OS・言語ランタイム・依存パッケージの版を確認する
資産を洗い出した後は、実際に導入・稼働しているBrotli関連コンポーネントのバージョンを確認します。Google BrotliのC言語実装では、CVEの記録上、1.0.3から1.2.0までが影響範囲とされており、修正版として1.0.10、1.1.1、1.2.1が示されています。ただし、Linuxディストリビューションではセキュリティ修正がバックポートされ、見かけ上のバージョン番号だけでは判定できない場合があります。必ず各ベンダーのセキュリティアドバイザリーも確認します。
あわせて、Node.js、Pythonパッケージ、Bun、Envoy、Istioなど、Brotliを内蔵または依存する製品の修正版を確認します。例えばNode.jsでは、22.23.4、24.22.1、26.12.1が修正版として示されています。PythonではBrotli 1.2.1、brotlicffi 1.2.1.0が確認対象です。パッケージ管理ツール上の情報に加え、実行中のプロセスがどのバイナリや共有ライブラリを読み込んでいるかまで確認することが、Brotliの脆弱性への確実な対応につながります。
Content-Encoding: brの受信・展開経路を確認する
HTTP2Shellの本質は、Brotliで圧縮されたデータを展開するデコーダーの脆弱性です。そのため、HTTP/2を使用しているかだけでなく、Content-Encoding: brのデータを受信し、どこで展開しているかを確認します。Webサーバー、リバースプロキシ、APIゲートウェイ、WAF、サービスメッシュ、アプリケーションフレームワーク、HTTPクライアントまで、通信経路を一連で追跡することが重要です。
確認時には、外部からBrotli圧縮されたHTTPリクエストを受け取るインバウンド通信と、アプリケーションが外部APIや外部サイトへアクセスしてBrotli圧縮レスポンスを受け取るアウトバウンド通信の両方を対象にします。Node.jsでは、Express 5などで使われるbody-parser 2.xやfetchの既定動作によって、開発者が明示的にBrotliを指定していなくても展開処理が行われる可能性があります。
外部から細工された圧縮データが届く経路を特定する
脆弱性の影響を優先順位付けするには、攻撃者が制御できる圧縮データが到達し得る経路を特定します。インターネット公開API、ファイルアップロード機能、Webhook受信機能、メールやメッセージキューの取り込み処理、プロキシ経由の通信などは、優先的に調査すべき対象です。認証済み利用者しか操作できない機能であっても、利用者が任意の圧縮データを送信できるならリスクを評価する必要があります。
また、SSRF対策が不十分なサービス、URLを指定して外部コンテンツを取得する機能、クローラー、連携API、ソフトウェア更新確認、CI/CDの依存関係取得処理なども重要です。これらは外部サイトから返されるレスポンスを自動展開する可能性があり、外部公開していない内部システムでもCVE関連の影響を受けることがあります。信頼できない送信元のデータが、脆弱なBrotliデコーダーに渡るかを基準に評価します。
開発・検証・本番環境を横断して棚卸しする
本番環境だけを更新しても、開発環境、検証環境、CI/CD環境、踏み台サーバー、開発者PCに脆弱なコンポーネントが残っていれば、HTTP2Shellへの応対としては不十分です。特にコンテナ環境では、本番で稼働中のコンテナ、レジストリに保管されたイメージ、ビルドキャッシュ、ベースイメージ、マルチステージビルドの成果物を分けて確認します。
環境ごとに、Brotliのバージョン、Brotliを含むランタイムや製品のバージョン、Brotli展開の有無、外部データの受信経路、修正の適用状況を記録すると、漏れを防げます。委託先やSaaS、マネージドサービスを利用している場合は、CVE-2026-111497の影響調査、修正版への更新状況、実行中プロセス・コンテナの入れ替え完了状況を確認します。調査結果を一元管理し、影響あり・影響なし・継続調査・例外対応に分類することで、その後の更新作業と脆弱性対応を進めやすくなります。
更新と緩和策の進め方
ベンダー提供の修正版へ更新する
CVE-2026-111497（HTTP2Shell）への基本的な対応は、Brotliデコーダーを修正版へ更新することです。Google Brotliを直接利用している場合は、影響を受ける系列に応じて1.0.10、1.1.1、または1.2.1以降を選定します。ただし、Brotliを内蔵する製品では、単にライブラリ単体を更新しても実際には置き換わらないことがあります。OS、言語ランタイム、ミドルウェア、プロキシなど、利用製品のベンダーが提供する修正版リリースへ更新してください。
例えば、Node.jsでは22.23.4、24.22.1、26.12.1、Bunでは1.4.4、PythonのBrotliでは1.2.1、brotlicffiでは1.2.1.0が修正版として案内されています。Envoy ProxyやIstioも、それぞれのサポート対象系列で修正版を選ぶ必要があります。サポート終了済みのNode.js 20系、23系、25系など、修正が提供されない系列を使っている場合は、パッチ適用ではなくサポート中の系列へ移行する計画が必要です。
OSパッケージでは、上流のBrotliバージョン番号とディストリビューションのパッケージ版が一致しない場合があります。ディストリビューションがセキュリティ修正をバックポートしている可能性もあるため、番号だけで脆弱と断定せず、ベンダーのセキュリティアドバイザリー、更新履歴、CVE関連情報を確認して判定します。
コンテナイメージを再ビルドして再デプロイする
コンテナ環境では、ホストやCI環境でパッケージを更新するだけではHTTP2Shell対応は完了しません。脆弱なBrotliライブラリ、Node.js、Pythonパッケージ、Envoyなどを含むベースイメージやアプリケーションイメージを修正版に更新し、キャッシュに依存せず再ビルドする必要があります。
特にマルチステージビルドでは、ビルドステージで生成された静的バイナリやネイティブモジュールに古いBrotliコードが取り込まれることがあります。実行ステージのOSパッケージだけを更新しても、成果物に静的リンクされた脆弱なコピーが残るケースがあるためです。Dockerfile、ビルドスクリプト、依存関係ロックファイルを見直し、ビルド元から修正版が使われる状態にしてください。
再ビルド後は、新しいイメージにタグを付けてレジストリへ格納し、Deployment、DaemonSet、Job、CI/CDワーカーなどを再デプロイします。古いタグを上書きする運用では、ノードやオーケストレーター側のイメージキャッシュにより旧イメージが継続利用されるおそれがあります。イメージダイジェストを確認し、期待した修正版イメージが実際に起動していることまで確認することが重要です。
更新までBrotli展開を無効化・制限する
修正版をすぐに適用できない場合は、暫定的な緩和策としてBrotliの展開処理を無効化または制限します。CVE-2026-111497の問題は圧縮ではなく展開処理にあるため、信頼できない送信元から受け取るContent-Encoding: brのHTTPリクエストやレスポンスを展開しないようにすることが有効です。
対策の例としては、HTTPクライアントでBrotli圧縮レスポンスの受信を停止する、プロキシやサービスメッシュでBrotli展開を無効にする、受信可能なContent-Encodingをgzipやidentityに限定する、といった方法があります。また、外部URLを取得するバックエンド処理、Webhook受信処理、APIゲートウェイ、ファイル取り込み機能など、攻撃者が圧縮データを到達させやすい経路を優先して制限します。
ただし、Brotliの無効化は機能互換性や通信量、応答性能に影響する可能性があります。さらに、ランタイムやHTTPライブラリが既定で展開を行う場合、アプリケーション設定だけでは制御できないこともあります。暫定策は恒久対応の代替ではないため、影響範囲、適用箇所、解除条件を明確にしたうえで、速やかに修正版へ移行してください。
再起動と稼働バージョンの確認を行う
パッケージやコンテナイメージを更新しただけでは、すでにメモリ上で動作しているプロセスは置き換わりません。Brotliの脆弱性への対応では、サービス再起動、ワーカーの入れ替え、Podの再作成、ロードバランサー配下の段階的なロールアウトまで実施し、旧プロセスを確実に停止する必要があります。
確認時は、インストール済みのバージョンだけでなく、稼働中プロセスが読み込んでいるランタイムやライブラリのバージョンを確認します。Node.jsであれば実行中コンテナ内のnode --version、Pythonであれば対象仮想環境内のBrotli関連パッケージ、OSではライブラリのパッケージ情報やプロセスのマッピング状況を確認します。Kubernetesなどでは、Podの作成時刻、コンテナイメージのダイジェスト、ReplicaSetやDeploymentの世代もあわせて確認すると、古いワーカーの残存を検知しやすくなります。
更新後には、外部からの圧縮データを扱う代表的な処理について、正常にサービス提供できることも確認します。Brotli展開の無効化を併用した場合は、利用者向け機能や外部API連携に意図しない影響が出ていないかを確認し、必要に応じて代替の圧縮方式や通信設定を調整します。
例外対応とリスク受容を記録する
互換性、製品サポート、停止可能な時間帯などの制約から、直ちに更新できないシステムもあります。この場合は「未対応」のままにせず、CVE-2026-111497に対する例外対応として記録し、責任者の承認、対応期限、暫定的な緩和策、残存リスクを明確にします。
記録には、対象資産、Brotliの利用形態、稼働バージョン、外部から細工された圧縮データが到達する可能性、Brotli展開を止められない理由、ネットワーク制限やWAFなどの代替統制、恒久対策の予定日を含めます。HTTP2Shellは外部から受信する通信だけでなく、アプリケーションが外部サイトやAPIから取得するレスポンスの展開処理も攻撃経路になり得るため、インバウンド・アウトバウンドの両方を評価します。
例外は定期的に見直し、ベンダーから修正版が提供された時点で更新計画を前倒しします。脆弱性対応の完了条件は「更新パッケージを入手したこと」ではなく、「修正版を使用するプロセスまたはコンテナへ切り替わり、脆弱なBrotliデコーダーが稼働環境から排除されたこと」として管理することが重要です。
対応後の監視と再発防止
不正な圧縮データによる異常を監視する
CVE-2026-111497（HTTP2Shell）への対応後も、Brotliの脆弱性を悪用する試行や、その影響が疑われる異常を継続的に監視することが重要です。特に、外部から受信したContent-Encoding: brのリクエストを展開するサービス、および外部APIやWebサイトからBrotli圧縮レスポンスを取得するHTTPクライアントは重点的な監視対象となります。
監視では、プロセスの異常終了、再起動回数の増加、セグメンテーション違反、メモリ使用量の急増、CPU使用率の異常、HTTP通信の失敗率上昇などを確認します。プロキシ、WAF、ロードバランサー、アプリケーションのアクセスログを突き合わせ、特定の送信元、URL、User-Agent、圧縮データを契機とする障害がないかを調査します。
また、Brotli展開に失敗したイベントや、不正な圧縮形式として拒否された通信を記録できる場合は、ログを保存して検知ルールに活用します。ただし、展開に失敗したことだけで攻撃と断定はできません。通常の通信障害と区別するため、異常終了、メモリ破壊の兆候、同一送信元からの反復試行など、複数の兆候を組み合わせて判断する運用が必要です。
依存関係とコンテナイメージの継続的な更新
HTTP2Shell 対応は、一度のパッチ適用で終わりではありません。BrotliはOSパッケージ、言語ランタイム、HTTPクライアント、プロキシ、サービスメッシュ、アプリケーションの依存関係など、複数の経路で導入されます。そのため、Brotli本体だけでなく、Brotliを内包する製品のセキュリティ更新を継続的に取り込む必要があります。
たとえば、Node.js、PythonのBrotli・brotlicffi、Bun、Envoy Proxy、Istioなどは、それぞれのベンダーが提供する修正版へ更新します。OSディストリビューションでは、上流のBrotliバージョンが古く見えても、セキュリティ修正がバックポートされている場合があります。単純なバージョン比較だけで判定せず、ディストリビューションのセキュリティアドバイザリーや更新履歴を確認することが大切です。
コンテナ環境では、ベースイメージを更新してアプリケーションを再ビルドし、新しいイメージへ置き換えます。Dockerfileを修正しても、稼働中のコンテナ、古いDeployment、Job、CI/CDワーカーが残っていれば脆弱なBrotliデコーダーが使われ続けるおそれがあります。イメージタグを固定運用している場合も、タグの更新有無ではなく、イメージダイジェストと実行中コンテナの実体を確認します。
定期的なベースイメージ更新、依存関係の自動更新候補の確認、脆弱性スキャンをCI/CDパイプラインへ組み込むことで、今後発見される関連脆弱性にも対応しやすくなります。
SBOMを使った脆弱性影響調査の迅速化
SBOM（Software Bill of Materials：ソフトウェア部品表）を整備すると、Brotli 関連のCVEが公表された際に、どのアプリケーション、コンテナイメージ、サーバー、開発ツールが影響を受ける可能性があるかを迅速に把握できます。CVE-2026-111497のように、直接導入したライブラリだけでなく、ランタイムや製品に組み込まれたコンポーネントが影響する脆弱性では、特に有効です。
SBOMには、アプリケーションの依存パッケージだけでなく、ベースイメージ、OSパッケージ、言語ランタイム、静的リンクされたライブラリ、ビルド時に取り込まれたサードパーティーコードを可能な範囲で記録します。CycloneDXやSPDXなどの形式で出力し、コンテナイメージやリリース成果物と対応付けて保管すると、脆弱性情報との照合を自動化しやすくなります。
ただし、SBOMに記載がないことだけを根拠に「影響なし」と判断するのは危険です。Brotliのソースコードを製品内部にコピーしている場合、静的リンクされている場合、独自ビルドのバイナリに含まれる場合などは、パッケージ名から検出できないことがあります。SBOMによる一次調査に加え、ファイルスキャン、バイナリ解析、実行中プロセスの確認を組み合わせることが、脆弱性対応の精度を高めます。
Brotliを使う機能と設定の定期的な見直し
Brotliを利用する機能は、性能向上のために導入される一方、意図しない展開経路を生むことがあります。定期的に、どのサービスがBrotli圧縮データを受信・展開しているか、どのHTTPクライアントがbrを受け入れているかを確認します。インバウンド通信だけでなく、外部URLや外部APIへアクセスするアウトバウンド通信も対象に含める必要があります。
Node.jsでは、アプリケーションが明示的にBrotliを指定していなくても、body-parserやfetchなどの既定動作を通じて展開が行われることがあります。同様に、プロキシ、サービスメッシュ、HTTPライブラリ、SDKの設定によっては、運用者が把握していない場所でBrotliデコーダーが動作します。設定変更、ライブラリ更新、基盤移行のタイミングで、圧縮形式の受け入れ条件を再確認することが重要です。
不要なBrotli展開は無効化し、必要な場合も受け入れる通信元、コンテンツ種別、要求サイズ、展開後サイズなどを制限します。もっとも、Brotliデコードの無効化はCVE-2026-111497への恒久的な対策ではありません。修正版への更新、コンテナやプロセスの入れ替え、実行中バージョンの確認を完了したうえで、最小権限と不要機能の削減という観点から設定を維持・見直すことが再発防止につながります。
省スペースPC GEEKOMをお探しの方はこちら
※こちらから購入すると支払時に3,500円引き
※支払時に3,500円の値引きがない場合はクーポンコードを入力してください。
クーポンコード
TAKESHI
TAKESHI
購入はこちらをクリック↓↓↓
GEEKOM PC購入時の注意点
電源コードがアース付きの3ピンとなってます。3ピン→2ピンの変換をお持ち出ない方は購入を Officeもついていません。必要な方はこちらより購入を
Office（Word Execl等）が必要な方はこちら
Word Execl Outlook
Word Execl Outlook PowerPoint
-
-
高性能ミニPC Amazonでの評判がすごく良いGEEKOM OS搭載ですぐに使用可能
台湾の新興PCメーカーGEEKOMギコム高性能の小型PCを専門的に製造、販売 当ブログ購読者限定3,500円OFFのクーポンコード公開 省スペースデスクトップで高性能 CPUもINTELとAMD両方ともラインナップ やめとけというかたもいるが評判はすこぶる良い
続きを見る
#Brotliの脆弱性 #コンテナ #要確認 #CVE-2026-111497 #影響範囲 #整理
