HTTP2Shellとは？Brotli脆弱性の仕組み・影響範囲・確認と対策手順

Webサービスや業務システムを開発・運用しているエンジニアやシステム管理者にとって、2026年10月に公表された緊急のセキュリティ脆弱性「HTTP2Shell（別名：Node2Shell / 識別番号：CVE-2026-111497）」は見逃せない重大なトピックです。

この脆弱性は、当初Node.jsの深刻な問題として報じられましたが、その後の調査によってNode.jsだけでなく、Python、Bun、さらにはEnvoy ProxyやIstioといったWebインフラ製品まで、幅広いソフトウェアに影響が及ぶことが明らかになりました。

「HTTP2Shell とはそもそも何なのか？」「HTTP/2通信を使っているとすべて危険なのか？」「自分が管理しているサーバーやDockerコンテナ、クラウド環境に影響があるかどうやって調べればよいのか？」と疑問や不安を感じている方も多いのではないでしょうか。

この記事では、セキュリティ初心者の方にもわかりやすい基礎知識から、システム管理者・インフラエンジニア・開発者向けの環境別調査コマンド、修正版へのアップデート手順、そして見落としやすい「外向き通信（アウトバウンド）」の罠までを体系的に解説します。

この記事で行うこと
前提条件・対象読者
1. HTTP2Shell（CVE-2026-111497）とは何か？
2. HTTP2Shellの影響範囲と攻撃経路の盲点
3. HTTP2Shellの影響を受けるバージョンと修正版一覧
4. システム管理者・開発者向けの環境別調査手順
5. HTTP2Shellへの具体的な対策とアップデート手順
6. 対策時に見落としやすい5つの注意点
7. HTTP2Shell（CVE-2026-111497）対応チェックリスト
8. HTTP2Shellに関するよくある質問（FAQ）
9. まとめ
次に読むおすすめ記事
参考情報

この記事で行うこと

HTTP2Shell（CVE-2026-111497）の概要と、原因となったデータ圧縮形式「Brotli」の仕組みを理解する
なぜ Node2Shell から HTTP2Shell へ呼称が広がったのか、影響を受ける言語・インフラの範囲を把握する
WAFだけでは防げない「外部URL取得（アウトバウンド通信）」の攻撃経路と危険性を確認する
Node.js、Python、Bun、Linux共有ライブラリ、Dockerコンテナにおける具体的な影響確認コマンドを実行する
各環境の修正済みバージョンへの更新手順と、すぐに更新できない場合の暫定対策・チェックリストを実践する

前提条件・対象読者

最終確認日：2026年10月26日
対象環境：Node.js、Bun、Python（Brotli / brotlicffi）、Envoy Proxy、Istio、Linux（Ubuntu / Debian等）、Dockerコンテナ環境
対象読者：Webアプリケーション開発者、インフラエンジニア、システム管理者、およびWebサービスの安全性を確認したい運用担当者
本記事の情報は2026年10月26日時点の各公式アドバイザリに基づいています。OSディストリビューションやクラウドベンダーによる修正版の提供状況は随時更新されるため、実際の運用環境で対応する際は各製品の最新セキュリティ情報もあわせて確認してください。

1. HTTP2Shell（CVE-2026-111497）とは何か？

1-1. HTTP2Shellの概要と名称の由来

HTTP2Shell は、Googleが開発したデータ圧縮アルゴリズム「Brotli（ブロトリ）」のC言語実装における展開処理（デコーダー）に存在する深刻な脆弱性について、影響範囲の広さを表すために使われている通称です。

この脆弱性には CVE-2026-111497 という識別番号が割り当てられており、CVSS v4.0の基本値は 9.2（Critical：緊急）と非常に高く評価されています。

当初は、米OpenAIからの報告を受けて2026年10月21日にNode.jsが緊急のセキュリティリリースを公開したことから、Node.js固有の問題として「Node2Shell」と呼ばれていました。しかし、セキュリティ企業のAikido Securityをはじめとする研究者の調査により、根本原因がNode.js独自のコードではなく、上流のGoogle製Brotliライブラリ（c/dec/decode.c）にあることが判明しました。その結果、HTTP通信やWebエコシステム全体に広く波及する問題であることを示す「HTTP2Shell」という呼称が使われるようになりました。

ここで押さえておきたい重要なポイントは、HTTP2Shell という名前であっても「HTTP/2プロトコルそのものの仕様上の脆弱性ではない」という点です。HTTP/1.1であれHTTP/2であれ、通信やデータ処理の過程で脆弱なBrotliデコーダーを使ってデータを展開する環境すべてが対象となります。

項目	内容
脆弱性の通称	`HTTP2Shell`、`Node2Shell`
CVE番号	`CVE-2026-111497`
深刻度（CVSS）	CVSS v4.0 スコア `9.2`（Critical）
根本原因	Google BrotliのC言語デコーダー実装（`c/dec/decode.c`、バージョン `1.0.3` 〜 `1.2.0`）におけるメモリ処理の不具合
主な問題	境界外書き込み（Out-of-bounds write / バッファオーバーフロー）
想定される影響	プロセスの異常終了（DoS）、メモリ情報の漏えい、リモートコード実行（RCE）など
攻撃成立の条件	脆弱なBrotli実装を組み込んだ環境で、攻撃者が細工した圧縮データを展開（デコード）させること
基本的な対策	脆弱性を修正したランタイム、ライブラリ、プロキシ製品へのアップデート

1-2. そもそもBrotliとは？どのような仕組みで問題が起きるのか

Brotli（ブロトリ）は、Googleが開発し標準化（RFC 7932）されたデータ圧縮形式です。従来の gzip よりも高い圧縮率を実現できるため、WebページのHTML・CSS・JavaScriptファイルの配信や、API通信のデータ量を削減する目的で世界中のWebサーバーや通信ライブラリで標準的に使われています。

通常のHTTP通信では、次のような流れでBrotliによる圧縮と展開が行われます。

クライアント（ブラウザやプログラム）が、Brotliに対応していることをリクエストヘッダーでサーバーに伝える。
サーバーがBrotliでデータを圧縮し、レスポンスヘッダーを添えてクライアントに送信する。
クライアント側のソフトウェアがデコーダーを使って圧縮データを展開（解凍）し、元のデータを取り出す。

クライアントが送信するリクエストヘッダーの例は次のとおりです。

Accept-Encoding: gzip, deflate, br

サーバーからBrotli圧縮されたデータが返される（またはクライアントが圧縮データを送信する）場合は、次のようなヘッダーが使われます。

Content-Encoding: br

今回の CVE-2026-111497 は、この圧縮データを元に戻す「展開処理（デコード処理）」に潜んでいた不具合です。

具体的には、Brotliのデコーダー（c/dec/decode.c）が不正に細工された圧縮ストリームを処理する際、本来であればエラーとして即座に処理を中断すべき「無効なブロック切替」を、「入力データがまだ足りない状態（継続待ち）」として誤認してしまうロジック上の欠陥がありました。その結果、内部バッファの終端を超えてデータを追記し続けてしまい、想定されたメモリ領域の外側へデータを書き込む「境界外書き込み（バッファオーバーフロー）」が発生します。

1-3. HTTP2Shellはなぜ危険なのか？

HTTP2Shell の危険性は、単に「圧縮されたWebページやAPIレスポンスが正しく読み込めなくなる」だけでは済まない点にあります。

脆弱なデコーダーが攻撃者の細工したBrotliデータを処理してメモリ破損が発生すると、次のような深刻な被害につながるおそれがあります。

サービス停止（DoS）：プロセスが異常終了（クラッシュ）し、WebサーバーやAPI、バックグラウンド処理が停止する
メモリ情報の漏えい：プロセスが保持しているメモリ領域のデータが意図せず読み取られる可能性がある
リモートコード実行（RCE）：特定の条件がそろった場合、攻撃者が用意した任意のプログラムコードを実行される可能性がある

特に警戒すべきなのが、認証なしでリモートからコードを実行されるリモートコード実行（RCE：Remote Code Execution）です。RCEが成立すると、侵害されたアプリケーションプロセスの実行権限でサーバー内の機密情報や環境変数（APIキーや認証情報）を窃取されたり、システム設定を改変されたり、社内ネットワークへの侵入の踏み台にされたりする危険があります。

ただし、脆弱なライブラリがシステム内に存在することと、すべての環境で即座にRCEが成立することはイコールではありません。実際のリスクの大きさを判断するには、「脆弱なバージョンの有無」だけでなく、「そのライブラリが外部からの信頼できないデータを展開する経路（データ処理経路）を持っているか」をあわせて確認する必要があります。

2. HTTP2Shellの影響範囲と攻撃経路の盲点

2-1. Node.jsだけの問題ではない（言語・インフラへの波及）

HTTP2Shell がセキュリティ業界で大きな注目を集めている理由は、影響範囲が特定のプログラミング言語や単一のツールに限定されない点にあります。

GoogleのC言語製Brotliデコーダーは、高速で実績があるため、さまざまな言語の実行環境（ランタイム）やパッケージ、プロキシソフトウェアの内部にそのまま組み込まれる（バンドルまたはリンクされる）形で利用されています。そのため、上流のBrotli実装に問題が見つかると、それを利用する複数のソフトウェアへ連鎖的に影響が波及します。

主な確認対象となるソフトウェアと環境は次のとおりです。

ソフトウェア・環境	確認すべきポイント
Node.js	実行環境（ランタイム本体）に組み込まれたBrotliのバージョン
Bun	Bun本体に組み込まれたBrotli実装のバージョン
Pythonパッケージ	`Brotli`、`brotlicffi` などのC拡張パッケージの導入有無とバージョン
PythonのHTTPクライアント	`requests`、`urllib3`、`httpx`、`aiohttp` 等が上記パッケージを介して行うレスポンスの自動展開
プロキシ・サービスメッシュ	Envoy Proxy、IstioなどのバージョンとBrotli展開（Decompression）設定の有無
ネイティブアプリ・OS	Linux等のOS共有ライブラリ（`libbrotlidec` 等）やアプリに静的リンクされたBrotli
コンテナ・クラウド環境	Dockerベースイメージ、マルチステージビルドの成果物、サーバーレス関数内の依存関係

2-2. WebサーバーやWAFだけでなく「通信の向き」に注意する

システム構成を調査する際、「入口にWAF（Web Application Firewall）やロードバランサーを入れているから大丈夫」「リバースプロキシのNginxだけ確認すればよい」と考えてしまうのは危険です。確認すべきなのは「どのコンポーネントが実際にBrotliデータを展開しているか」と「通信の向き（インバウンドかアウトバウンドか）」の2点です。

一般的なWebシステムの構成例で考えてみましょう。

[インターネット上のクライアント / 攻撃者]
     |
     | (1) インバウンド通信（受信リクエスト）
     v
[ロードバランサー / WAF]
     |
     v
[Webサーバー / リバースプロキシ / Envoy等]
     |
     v
[アプリケーション（Node.js / Python / Bun）]
     |
     | (2) アウトバウンド通信（外部API・URL取得）
     v
[インターネット上の外部サーバー / 攻撃者が用意したURL]

この構成には、大きく分けて2つの攻撃経路が存在します。

1つ目は、外部からリクエストを受け付ける「インバウンド通信（受信経路）」です。たとえば、Express 5や body-parser などのフレームワーク機能、あるいはEnvoy Proxyなどで、クライアントから送られてきた Content-Encoding: br 付きのリクエストボディを自動展開しているケースです。この経路は、入口のWAFやプロキシで Content-Encoding: br を拒否するルールを設定することである程度緩和できます。

2つ目は、見落とされやすい最大の盲点である「アウトバウンド通信（外向き取得経路）」です。Node.js標準の fetch()（内部の undici）や、Pythonの requests、httpx、aiohttp などのHTTPクライアントは、外部サーバーへリクエストを送る際にデフォルトで Accept-Encoding: br を送信し、返ってきたBrotli圧縮レスポンスを自動的に展開する仕組みを持っています。

もしアプリケーションが「外部のURLにアクセスしてデータを取得する」処理を行っている場合、攻撃者が細工したBrotliレスポンスを返す悪意あるサーバーへアクセスさせることで、入口のWAFを完全に素通りしてアプリケーション内部のデコーダーを直接攻撃できてしまいます。

2-3. 優先して調査すべきシステムの特徴

上記の攻撃経路を踏まえると、次のような機能を持つシステムは特に優先度を高めて調査する必要があります。

外部URLへアクセスしてデータを取得するサービス（アウトバウンド経路）

ユーザーが入力したURLのWebページを取得する機能（OGPカード生成、リンクプレビュー機能など）
クローラー、スクレイピングツール、RSSフィード取得バッチ
外部サイトから画像やドキュメントファイルをダウンロードする処理
ユーザーが登録した任意のURLへ通知を送るWebhook送信機能（レスポンスを読み取る場合）
AIエージェントやRAG（検索拡張生成）システムで外部Webサイトを検索・取得するツール

外部から圧縮されたHTTPリクエストを受け付けるサービス（インバウンド経路）

外部公開されているWeb APIやGraphQLエンドポイント
クライアントからのデータアップロードやログ収集を受け付けるサーバー
Content-Encoding: br の展開機能を有効にしているリバースプロキシやサービスメッシュ（Envoy / Istio）

コンテナ・クラウド・CI/CD環境

DockerイメージやKubernetesクラスター上のPod
CI/CDパイプライン（GitHub Actions等）で外部パッケージやURLを取得するランナー環境
AWS LambdaやGoogle Cloud Runなどのサーバーレス実行環境

コンテナを利用している場合、ホストOSのパッケージを更新しただけでは、コンテナイメージの内部に同梱された古いNode.jsやPythonパッケージ、共有ライブラリはそのまま残ってしまいます。必ずコンテナ内部の環境まで踏み込んで確認することが重要です。

2-4. 一般のWebサイト利用者（個人ユーザー）にも影響するのか？

普段インターネットでWebサイトを閲覧している一般の利用者（個人ユーザー）が、HTTP2Shell に対して自分でサーバーの設定変更やコマンド操作を行う必要はありません。主に対応が求められるのは、Webサービスやシステムを開発・運用している企業や管理者です。

ただし、自分が利用しているWebサービス側が攻撃を受けて侵害された場合、サービスの停止や登録情報の漏えいといった間接的な被害を受ける可能性はゼロではありません。

個人ユーザーとして心がけておきたい基本対策は次のとおりです。

パソコンやスマートフォンのOS、Webブラウザ（Chrome、Edge、Safari等）の自動更新を有効にし、常に最新の状態に保つ
利用しているWebサービスからセキュリティに関する案内や通知が届いた場合は、公式の案内に従って対応する
根拠のないSNSの噂やフィッシングメールに惑わされず、HTTP2Shell という話題だけを理由に焦って不審なリンクからパスワード変更などを行わない

3. HTTP2Shellの影響を受けるバージョンと修正版一覧

3-1. 主要ソフトウェア別の影響範囲と修正済みバージョン

公開されている各公式アドバイザリでは、Google Brotliのバージョン 1.0.3 から 1.2.0 までが影響対象として挙げられています。

Brotliを組み込んでいる各ソフトウェアでは、すでに脆弱性を修正したアップデート版がリリースされています。主な対象ソフトウェアと修正済みバージョンは次のとおりです。

対象ソフトウェア	影響を受ける主な範囲	修正済みバージョン
Google Brotli（上流C実装）	`1.0.3` 〜 `1.2.0`	`1.0.10`、`1.1.1`、`1.2.1`
Node.js	22系・24系・26系の修正前バージョン（およびEOLの20系以前）	`22.23.4`、`24.22.1`、`26.12.1` 以降
Bun	`1.4.4` 未満	`1.4.4` 以降
Python `Brotli` パッケージ	`1.2.0` 以前	`1.2.1` 以降
Python `brotlicffi` パッケージ	`1.2.0.0` 以前	`1.2.1.0` 以降
Envoy Proxy	Brotli展開を有効にした各系列の修正前バージョン	`1.40.0`、`1.39.3`、`1.38.6`、`1.37.8` 以降
Istio	`1.31.0`〜`1.31.1`、`1.30.0`〜`1.30.5`、`1.29.0`〜`1.29.8`	`1.31.2`、`1.30.6`、`1.29.9` 以降

※Node.jsにおいて、すでにサポート終了（EOL）となっているNode.js 20系や18系以前のリリース系列には、公式のオープンソース版セキュリティパッチは提供されません。古い系列を利用している場合は、サポート対象のLTS系列（22系または24系など）へのアップグレードが必要です。

※UbuntuやDebian、Red HatなどのLinuxディストリビューションが提供するOS標準パッケージでは、元のバージョン番号を維持したままセキュリティ修正だけを適用する「バックポート」が行われる場合があります。OSパッケージについては単純なバージョン番号の大小だけで判断せず、各ディストリビューションの公式セキュリティアドバイザリ（USNやDSAなど）と照合してください。

3-2. Node.jsとBunのバージョン確認方法

手元のサーバーや開発環境でNode.jsを利用している場合は、ターミナル（またはPowerShell・コマンドプロンプト）を開き、まずNode.js本体のバージョンを確認します。

node --version

次に、Node.jsの実行環境内部に組み込まれているBrotliのバージョンを直接出力して確認します。

node -p "process.versions.brotli"

実行すると、たとえば次のように表示されます。

v24.22.0
1.2.0

この出力例では、Node.jsが修正前の v24.22.0 であり、内蔵されているBrotliも影響範囲に含まれる 1.2.0 であることが一目でわかります。Node.jsを修正版の v24.22.1 以降へ更新すると、内蔵Brotliのバージョンも 1.2.1 へ更新されます。

Bunを利用している場合は、以下のコマンドでバージョンを確認し、1.4.4 以降になっているかをチェックします。

bun --version

3-3. Pythonパッケージのバージョン確認方法

Python環境では、標準ライブラリ単体にはBrotliが含まれていませんが、外部パッケージとして Brotli または brotlicffi がインストールされていると影響を受けます。

ターミナルで以下のコマンドを実行し、パッケージの導入有無とバージョンを確認します。

python -m pip show Brotli brotlicffi

インストール済みパッケージの一覧から大文字・小文字を区別せずに検索する場合は、次のコマンドが便利です。

LinuxやmacOSのターミナルで実行する場合：

python -m pip list | grep -i brotli

WindowsのPowerShellやコマンドプロンプトで実行する場合：

python -m pip list | findstr /i brotli

ここで注意したいのは、グローバル環境でパッケージが表示されなくても、プロジェクトごとの仮想環境（venv、Poetry、uv、Condaなど）の中にインストールされているケースが多い点です。必ずアプリケーションが実際に稼働している仮想環境を有効化（アクティベート）した状態で確認してください。

4. システム管理者・開発者向けの環境別調査手順

ここからは、管理しているシステム全体で対応漏れを防ぐための具体的な調査手順を5つのステップで解説します。

調査のゴールは、単にバージョン番号を調べることではなく、次の4点を明らかにすることです。

脆弱なBrotli実装がシステム内のどこに存在するか
その実装をどのアプリケーションやプロキシが利用しているか
外部からのリクエストや外部URLからのレスポンスを展開する経路があるか
再ビルドや再起動が必要なサーバー、コンテナ、サービスはどれか

手順1：Node.jsプロジェクトと依存関係を調査する

まず、対象のサーバーや開発環境でNode.jsのバージョンと内蔵Brotliを確認します。

node --version
node -p "process.versions.brotli"
npm --version

続いて、プロジェクトのディレクトリへ移動し、npm の依存関係ツリーにBrotli関連のネイティブアドオンやパッケージが別途含まれていないかを検索します。

npm ls | grep -i brotli

※Node.jsではBrotliデコーダーがNode.js本体（zlib モジュールや内蔵の undici / fetch）に最初から組み込まれています。そのため、npm ls で何も表示されなくても、Node.js本体のバージョンが古ければ脆弱性の対象となります。本体と追加パッケージの両面から確認してください。

手順2：Pythonプロジェクトとロックファイルを調査する

Pythonプロジェクトでは、ソースコード内で直接 import brotli と書いていなくても、requests、urllib3、httpx、aiohttp などのHTTPクライアントライブラリがオプション依存関係（urllib3[brotli] や httpx[brotli] など）としてBrotliを導入しているケースがあります。

プロジェクトルートで、依存関係管理ファイルやロックファイルの中に brotli や brotlicffi の記述がないかを一括検索します。

対象となる主な管理ファイルは次のとおりです。

requirements.txt
pyproject.toml
poetry.lock
uv.lock
Pipfile.lock

LinuxやmacOS、WSL環境でプロジェクト内の関連記述を検索するコマンド例です。

grep -RniE 'brotli|brotlicffi' requirements.txt pyproject.toml poetry.lock uv.lock Pipfile.lock 2>/dev/null

もしロックファイル内に brotli（バージョン 1.2.0 以下）や brotlicffi（バージョン 1.2.0.0 以下）が見つかった場合は、そのPython環境が外部とのHTTP通信でBrotliデータを展開する処理を含んでいないか確認し、パッケージの更新対象リストに加えます。

手順3：Linuxの共有ライブラリとOSパッケージを調査する

Linuxサーバー上では、WebサーバーのモジュールやネイティブアプリケーションがOSの共有ライブラリ（libbrotlidec1 など）を動的リンクして利用している場合があります。

DebianやUbuntu系の環境では、以下のコマンドでインストール済みのBrotli関連パッケージを確認できます。

dpkg -l | grep -i brotli

または apt コマンドでも確認可能です。

apt list --installed 2>/dev/null | grep -i brotli

実行中のプロセスがどの libbrotli 共有ライブラリファイルをメモリ上に読み込んでいるかを調べる場合は、lsof コマンドが役立ちます。

sudo lsof 2>/dev/null | grep -i libbrotli

これにより、共有ライブラリを更新したあとに「どのサービス（NginxやApache、各種デーモンなど）を再起動しなければならないか」を正確に特定できます。なお、Ubuntu環境での安全なパッケージ更新手順については、Ubuntuのアップデートコマンド一覧｜安全にパッケージ更新する手順でも詳しく解説しています。

手順4：Dockerコンテナと稼働イメージを調査する

DockerやKubernetesを利用している環境では、ホストOS側を調査しただけでは不十分です。実際に稼働しているコンテナの内部に入ってバージョンを確認します。

まず、稼働中のコンテナ一覧とイメージ一覧を表示します。

docker ps
docker images

Node.jsが動いているコンテナに対して、外から直接バージョン確認コマンドを実行する例は次のとおりです（<コンテナ名> は docker ps で確認した実際の名前やIDに置き換えてください）。

docker exec <コンテナ名> node --version
docker exec <コンテナ名> node -p "process.versions.brotli"

Pythonコンテナの場合は、次のように確認できます。

docker exec <コンテナ名> python -m pip list | grep -i brotli

また、TrivyやGrype、Aikido SecurityなどのコンテナスキャンツールやSBOM（ソフトウェア部品表）生成ツールを導入している場合は、脆弱性データベースを最新化したうえでイメージスキャンを実行すると、複数イメージの洗い出しを効率化できます。

手順5：調査結果を台帳に整理して優先順位を付ける

洗い出した情報は、以下のような項目で一覧表（スプレッドシートやMarkdownテーブル）に整理しておくと、チーム内での共有や対応漏れ防止に役立ちます。

管理項目	記録する内容の例
システム・サービス名	ユーザー向けWeb API、OGP取得ワーカー、管理画面など
実行環境・インフラ	Node.js、Python、Bun、Envoy、Dockerコンテナなど
現在のバージョン	`Node.js v24.22.0`（Brotli `1.2.0`）など
データ処理経路	外部URLへの `fetch()` あり、受信APIで圧縮ボディ処理あり等
外部からの到達性	インターネット公開、社内ネットワーク限定、バッチ処理など
優先度と対策状況	最優先（未対応）、更新テスト中、修正版デプロイ完了など
残作業・確認事項	コンテナ再ビルド、Podのローリングアップデート、プロセス再起動など

とくに「インターネットから直接アクセスできるシステム」や「外部の任意のURLからデータを取得するシステム」で脆弱なバージョンが見つかった場合は、最優先で対策を進めます。

5. HTTP2Shellへの具体的な対策とアップデート手順

手順1：Node.jsおよびBunの更新手順

Node.jsの基本的な対策は、利用しているリリース系列に対応した修正済みバージョンへアップデートすることです。

Node.js 22系（LTS）：v22.23.4 以降へ更新
Node.js 24系（LTS）：v24.22.1 以降へ更新
Node.js 26系（Current）：v26.12.1 以降へ更新

※2026年10月のNode.jsセキュリティリリースには、CVE-2026-111497 以外にも dns.resolve の検証回避（CVE-2026-105482）やTLSホスト名検証の問題など複数の重要な修正が含まれているため、速やかな適用が推奨されます。

本番環境を更新する際は、次の手順で進めます。

現在のNode.jsバージョンとアプリケーションの互換性を確認する。
ステージング環境（テスト環境）で修正版Node.jsへ更新し、API通信やバッチ処理の動作確認を行う。
本番環境のNode.jsを更新し、稼働中のアプリケーションプロセス（pm2、systemd サービスなど）を必ず再起動する。
更新後に以下のコマンドを実行し、バージョンが切り替わっていることを確認する。

node --version
node -p "process.versions.brotli"

出力されたBrotliのバージョンが 1.2.1（または該当系列の修正済みバージョン）になっていれば完了です。

また、Bunを利用している場合は、以下のコマンドで 1.4.4 以降へアップグレードし、バージョンを確認します。

bun upgrade
bun --version

Bunの基本的な仕組みやバージョン管理については、【初心者向け】Bun 1.2+入門！Node.jsとの違いと爆速機能を解説もあわせて参考にしてください。

手順2：Pythonパッケージの更新手順

Python環境で Brotli または brotlicffi がインストールされている場合は、それぞれの修正版（Brotli 1.2.1 以降、brotlicffi 1.2.1.0 以降）へ更新します。

pip で管理している仮想環境で、Brotli を更新する場合：

python -m pip install --upgrade "Brotli>=1.2.1"

brotlicffi を使用している場合：

python -m pip install --upgrade "brotlicffi>=1.2.1.0"

Poetryや uv を使用しているプロジェクトでは、手元の環境でパッケージだけを更新するのではなく、pyproject.toml やロックファイル（poetry.lock / uv.lock）、requirements.txt も必ず更新してリポジトリへコミットしてください。ロックファイルを更新しないと、次回デプロイ時やCI/CDビルド時に再び古いバージョンがインストールされてしまいます。

更新後は、以下のコマンドでバージョンが 1.2.1（または 1.2.1.0）以降になったことを確認し、Webアプリケーションサーバー（gunicorn、uvicorn 等）を再起動します。

python -m pip show Brotli brotlicffi

手順3：Dockerイメージの再ビルドと再デプロイ手順

Docker環境では、稼働中のコンテナの中に入って直接パッケージを更新しても、コンテナが再起動したりオートスケーリングしたりした瞬間に元の古いイメージへ戻ってしまいます。必ず以下の手順でイメージ自体を作り直してください。

Dockerfile のベースイメージ指定（例：FROM node:24-bookworm-slim など）や、パッケージ固定バージョンを確認する。
最新のベースイメージを取得するため、--pull（および必要に応じて --no-cache）オプションを付けてイメージを再ビルドする。

docker build --pull --no-cache -t my-app:patched .

ビルドした新しいイメージを使って一時コンテナを起動し、内部のバージョンが修正版になっているかテストする。

docker run --rm my-app:patched node --version
docker run --rm my-app:patched node -p "process.versions.brotli"

ステージング環境での動作確認後、本番環境のコンテナレジストリへプッシュし、すべてのPodやコンテナタスクを新しいイメージで再デプロイ（ローリングアップデート）する。

手順4：すぐにアップデートできない場合の暫定対策（ワークアラウンド）

大規模な業務システムやレガシー環境など、互換性検証の都合でどうしても即座に実行環境をアップデートできない場合は、恒久対策（アップデート）の準備と並行して、「脆弱なBrotliデコーダーにデータを渡さない」ための暫定対策を検討します。

主な暫定対策のアプローチは次のとおりです。

アウトバウンド通信でのBrotli無効化：アプリケーション内のHTTPクライアント（fetch、axios、requests、httpx 等）が外部サーバーへリクエストを送る際、明示的に Accept-Encoding: gzip, deflate を指定して br を除外し、Brotli圧縮レスポンスを受け取らないようにする
インバウンド通信での Content-Encoding: br 拒否：フロント段のWAF、ロードバランサー、リバースプロキシ（Nginx等）において、外部から送られてくるリクエストヘッダーに Content-Encoding: br が含まれている場合はステータスコード 415 Unsupported Media Type 等でブロックする
外部URL取得機能のアクセス先制限：URLプレビュー機能やWebhookなどでアクセス可能なドメイン・IPアドレスをホワイトリスト等で制限する

ただし、悪意ある外部サーバーはクライアント側が Accept-Encoding: gzip と要求していても、強制的に Content-Encoding: br のレスポンスを送りつけてくる可能性があります。HTTPクライアントの実装によっては、要求していないエンコーディングであってもレスポンスヘッダーに従って自動的にBrotliデコーダーを呼び出してしまうケースがあるため、ヘッダーの変更だけで100%安全になると過信せず、可能な限り早期にランタイムやライブラリの更新を実施してください。

6. 対策時に見落としやすい5つの注意点

6-1. ソースコード検索だけで「使っていない」と判断しない

プロジェクトのソースコード全体を brotli というキーワードで検索してヒットしなかったとしても、安心はできません。

前述のとおり、Node.jsやBunではランタイム自体にBrotliが内蔵されており、標準の fetch() を使うだけで裏側で自動的にBrotliデコーダーが動きます。Pythonでも、HTTPクライアントライブラリの間接的な依存関係としてロックファイルにだけ記録されているケースが多々あります。必ず実行環境のバージョンとロックファイル、OSライブラリの3階層で確認してください。

6-2. WAFの導入だけで対策完了とみなさない

クラウドWAF（AWS WAF、Cloudflare等）は、外部から送られてくる悪意あるリクエスト（インバウンド通信）を水際で防ぐ上では有効な防御層になります。

しかし、サーバー内のプログラムが自ら外部のWebサイトやAPIへデータを取りに行く「アウトバウンド通信」のレスポンスは、WAFの検査対象外となるケースがほとんどです。WAFを導入している環境であっても、バックエンドのNode.jsやPythonパッケージの更新を省略しないでください。

6-3. アップデート後の「プロセス再起動漏れ」と「古いイメージの残留」

サーバー上で apt upgrade や pip install --upgrade、Node.jsのバージョン切り替え（nvm や fnm 等）を実行しただけでは、すでにメモリ上で稼働し続けているWebサーバーやワーカープロセスには古いコードと古いライブラリが読み込まれたままになっています。

アップデート作業のあとは、必ず以下の点を確認してください。

対象のアプリケーションプロセスやWebサーバー、ワーカーをすべて再起動したか
ロードバランサー配下の複数台のサーバーすべてに更新が反映されているか
KubernetesやECS等で、すべてのPod・タスクが新しいコンテナイメージに入れ替わっているか
オートスケーリング設定（起動テンプレート等）が古いAMIや古いコンテナタグを参照したままになっていないか

6-4. サーバーレス環境やCI/CDパイプラインの確認漏れ

常時稼働しているEC2やVPS、Kubernetesクラスターだけでなく、以下のような環境も見落としやすいポイントです。

AWS Lambda、Google Cloud Functions、Cloud Runなどのサーバーレス環境（デプロイ済みのレイヤーやコンテナイメージに古いNode.js / Pythonパッケージが含まれていないか）
GitHub ActionsやGitLab CIなどのビルド環境・カスタムアクション
開発者のローカルPC上で動くMCPサーバーやAIエージェントのツール実行環境

6-5. パッチ適用前の侵害有無の点検

インターネットに向けて公開されており、かつ外部からのデータ展開を行っていたシステムでは、アップデートを適用するだけでなく、すでに不審なアクセスやプロセスの異常が発生していなかったかログを点検することも大切です。

アプリケーションやプロキシが原因不明のクラッシュ（セグメンテーション違反や異常終了）を繰り返していなかったか
不審な子プロセスの起動や、見覚えのない外部IPアドレスへの通信が発生していないか
サーバー内の設定ファイル改ざんや、環境変数・認証情報への不正アクセスの痕跡がないか

もし侵害が疑われる兆候が見つかった場合は、ログやディスク状態を保全した上でセキュリティ担当者や専門機関と連携し、原因の除去だけでなくAPIキーやシークレット、認証情報のローテーション（再発行）を実施してください。組織における脆弱性管理やインシデント対応の全体像については、IPA情報セキュリティ10大脅威2026をわかりやすく解説｜組織と個人の対策でも解説しています。

7. HTTP2Shell（CVE-2026-111497）対応チェックリスト

システム管理者や開発チームで対応状況を最終確認するためのチェックリストです。

調査フェーズ

[ ] 稼働中のNode.js、Bun、Python、Envoy、Istioなどの実行環境をすべて洗い出した
[ ] node -p "process.versions.brotli" や pip show でBrotliのバージョンを確認した
[ ] ロックファイル（package-lock.json、poetry.lock、uv.lock 等）とOS共有ライブラリを確認した
[ ] Dockerコンテナイメージやサーバーレス関数の内部環境も調査した
[ ] 外部URLを取得する処理（アウトバウンド）や圧縮リクエストを受け付ける経路（インバウンド）を特定した

対策・アップデートフェーズ

[ ] 各ソフトウェアの公式セキュリティアドバイザリで修正済みバージョンを確認した
[ ] すぐ更新できないシステムに対して、Brotli無効化やWAFルールなどの暫定対策を適用した
[ ] ステージング環境で修正版へのアップデートと動作テストを実施した
[ ] 本番環境のアップデート、コンテナイメージの再ビルド・再デプロイを完了した
[ ] すべてのインスタンス、ワーカープロセス、Podを再起動・更新した

更新後の確認フェーズ

[ ] 本番で稼働中のプロセスが実際に修正版バージョンで動作していることをコマンドで再確認した
[ ] オートスケーリング時や次回CI/CDデプロイ時に古いバージョンへ戻らないことを確認した
[ ] アプリケーションの正常動作とエラーログの有無を確認した

8. HTTP2Shellに関するよくある質問（FAQ）

Q1. HTTP2ShellはHTTP/2プロトコルの脆弱性なのですか？HTTP/2を無効にすれば防げますか？

いいえ、HTTP2Shell はHTTP/2プロトコル自体の脆弱性ではなく、データ圧縮形式「Brotli」のデコーダー（展開処理）に存在する脆弱性です。HTTP/2を無効化してHTTP/1.1だけで通信するように設定を変更しても、アプリケーションやプロキシがBrotli圧縮データを展開している限り脆弱性の影響を受けます。HTTP/2の無効化ではなく、Brotliを利用するソフトウェアの更新を行ってください。

Q2. Node.jsを使っていなければ安全ですか？

必ずしも安全とは限りません。当初は Node2Shell と呼ばれていたためNode.jsだけの問題と思われがちですが、根本原因はGoogle製のC言語Brotliライブラリにあります。Pythonの Brotli や brotlicffi パッケージ、Bun、Envoy Proxy、Istio、OSの共有ライブラリなどを利用している環境も影響対象となるため、使用言語を問わず確認が必要です。

Q3. NginxやApacheでWebサイトの配信用にBrotli圧縮を有効にしていますが危険ですか？

脆弱性が存在するのは、Brotliデータを「圧縮する処理（エンコーダー）」ではなく、圧縮されたデータを「展開する処理（デコーダー）」です。また、影響を判断する際は、Webサーバーが利用しているBrotliモジュールやOSの共有ライブラリ（libbrotlidec）のバージョン、そしてクライアントから送られてくる圧縮リクエストを展開する設定になっているかを確認する必要があります。OSやWebサーバーのパッケージにセキュリティ更新が提供されている場合は、速やかに適用してプロセスを再起動してください。

Q4. Pythonの標準ライブラリだけでコードを書いていますが影響はありますか？

Pythonの標準ライブラリ単体にはBrotliデコーダーは含まれていません。ただし、requests、urllib3、httpx、aiohttp などの代表的なHTTPクライアントライブラリを利用している環境で、同じ仮想環境内に Brotli または brotlicffi パッケージがインストールされていると、HTTPレスポンス受信時に自動的にBrotliデコーダーが呼び出されます。python -m pip list | grep -i brotli を実行してパッケージの有無を確認してください。

Q5. Node.js 20系や18系を使っている場合はどうすればよいですか？

Node.js 20系や18系以前のバージョンは、すでに公式サポート終了（End-of-Life）となっており、Node.jsプロジェクトから公式のセキュリティ修正パッチは提供されません。暫定対策として通信経路の制限を行いつつ、現在サポートされているLTSバージョン（Node.js 22系または24系など）へのアップグレードを計画・実施してください。

9. まとめ

本記事では、2026年10月に公表されたBrotliデコーダーの深刻な脆弱性「HTTP2Shell（Node2Shell / CVE-2026-111497）」について、仕組みから影響範囲、環境別の調査コマンド、具体的な対策手順までを解説しました。

最後に重要なポイントを振り返ります。

HTTP2Shell（CVE-2026-111497）はHTTP/2プロトコル自体の問題ではなく、Google製Brotliデコーダー（1.0.3 〜 1.2.0）における境界外書き込み（バッファオーバーフロー）の脆弱性である
悪意あるBrotli圧縮データを展開させられると、プロセスのクラッシュ（DoS）やメモリ情報漏えい、最悪の場合はリモートコード実行（RCE）につながる危険がある
Node.jsだけでなく、Bun、Python（Brotli / brotlicffi）、Envoy Proxy、Istio、OSの共有ライブラリなど幅広い環境に波及している
外部からのリクエスト（インバウンド）だけでなく、サーバーが fetch() や requests 等で外部URLのデータを取得して自動展開する経路（アウトバウンド）はWAFを素通りするため特に注意が必要である
対策の基本は修正版（Node.js 22.23.4 / 24.22.1 / 26.12.1、Bun 1.4.4、Python Brotli 1.2.1 等）へのアップデートであり、更新後は必ずプロセスの再起動やDockerイメージの再ビルド・再デプロイまで完了させる