HTTP2Shell（CVE-2026-111497）とは - Brotli の展開処理の範囲外書き込みと、Node.js・Python・サーバー構成別の対応

2026年10月21日、Google の圧縮ライブラリ Brotli の修正版（1.2.1 / 1.1.1 / 1.0.10）と、Brotli を同梱する Node.js の修正版（26.12.1 / 24.22.1 / 22.23.4）が公開されました。修正されたのは、Brotli の C 実装の展開（デコード）処理で、細工した圧縮データによってメモリの範囲外に書き込みができてしまう脆弱性 CVE-2026-111497 です。

Brotli は、Web の Content-Encoding: br で広く使われている圧縮形式です。Node.js、Bun、Python のパッケージ、Envoy、.NET、curl など多くのソフトウェアが同じ C 実装を使っているため、影響が HTTP の周辺に広く及ぶことから「HTTP2Shell」とも呼ばれています。この記事では、仕組みと危険度を一次情報で整理し、どこから攻撃データが入り込むのか、構成ごとに何をすればよいかをまとめます。

まず結論 - やること

1. Node.js を 26.12.1 / 24.22.1 / 22.23.4 以降に更新する。20.x 以前などサポートが終わった版には修正が出ません。
2. OS の Brotli（libbrotli1 / brotli パッケージ）を更新する。Ubuntu や Debian の Node.js、Python、curl、PHP などは、OS の Brotli を使っています。
3. Python は Brotli 1.2.1 / brotlicffi 1.2.1.0 以降へ。Bun は 1.4.4、.NET は 8.0.33 / 9.0.22 / 10.0.14 へ。Envoy と Istio も各修正版へ。
4. 更新後に、Brotli を読み込んでいるプロセスをすべて再起動する。ライブラリを入れ替えても、動いているプロセスは古いものを使い続けます。Docker のイメージは作り直します。
5. すぐに更新できないなら、Content-Encoding: br のリクエストを入口で拒否する。ただし、外部から受け取るレスポンスの展開は防げないので、更新が本来の対策です。

HTTP2Shell とは

HTTP2Shell は CVE-2026-111497 の通称です。CVE レコード、Node.js の公式ブログ、Brotli のリリースノートはどれもこの名前を使っていません。

• 最初は、Node.js の公表に合わせて Node2Shell と呼ばれていました。10月21日に PHP 本体の脆弱性が PHP2Shell と呼ばれた直後で、それにならった呼び名です。
• その後、原因が Node.js ではなく Brotli の C 実装にあり、Python や Bun、Envoy なども影響を受けることがわかって、HTTP2Shell とも呼ばれるようになりました。JPCERT/CC は「BrotliはHTTP通信で利用されるデータ圧縮ライブラリであったことから複数の製品で影響を受けるため『HTTP2Shell』とも呼称されています」と説明しています（JPCERT/CC）。
• 名前に「HTTP2」と入っていますが、HTTP/2 プロトコルの脆弱性ではありません。HTTP/1.1 でも HTTP/2 でも、Brotli で圧縮されたデータを展開する処理があれば関係します。
• ほかに Broccoli2Shell という呼び名もあります。どの名前も、誰が最初に付けたのかは一次情報で確認できていません。

CVE レコードの報告者のクレジットは、OpenAI の Codex Security の研究者です。CVE 番号は Google が採番しています。

タイムライン

修正のコード自体は2月から公開されていて、10月に脆弱性として公表された、という順番です。2月以降の開発版を取り込んでいた製品は、知らないうちに直っていたことになります。

脆弱性の仕組み

場所は Brotli の C 実装のデコーダ（c/dec/decode.c）で、圧縮データの「ブロックの切り替え」を読む処理です。

• Brotli の圧縮データは、いくつかのブロックに分かれていて、途中で「次のブロックの種類に切り替える」という指示が入ります。
• 細工したデータで、ありえない切り替えを指示すると、デコーダはそれを「データが壊れている」ではなく「入力がまだ足りないので続きを待つ」と扱っていました。
• その結果、ストリームで少しずつ展開する処理が、8バイトの内部バッファの後ろへ入力を書き足し続け、隣にあるデコーダの状態を壊します。

Node.js の公式ブログは、影響を「プロセスのクラッシュ、プロセスのメモリの漏えい、リモートコード実行（RCE）につながりうる」としています（Node.js）。修正では、この状態を「形式のエラー」（BROTLI_DECODER_ERROR_FORMAT_BLOCK_SWITCH）として返し、展開をそこで止めるようになりました。

影響を受けるのは「展開する側」だけです。Brotli で圧縮する処理（エンコーダ）は関係ありません。Web サーバーがレスポンスを Brotli で圧縮して返しているだけなら、この脆弱性の入口にはなりません。

危険度

評価する組織によって、スコアが分かれています。

Google の CVSS v4.0 のベクターは AV:N/AC:L/AT:P/PR:N/UI:N/VC:H/VI:H/VA:H/SC:N/SI:N/SA:N です。ネットワーク越しに、認証なしで攻撃できます。前提条件（AT:P）は、相手が Brotli のデータを展開する処理を持っていることです。

Red Hat は、正確に細工したデータが必要なことと、ASLR などの保護機能で確実なコード実行が難しくなることから、攻撃の難しさを高い（AC:H）として 8.1 にしています（RHSB-2026-015）。

悪用の状況は次のとおりです。

• Imperva は、公式の Node.js 24.22.0 の Linux arm64 のイメージで、コードの実行に成功したと公表しました（Imperva）。経路は、fetch() で受け取ったレスポンスと、Express 5 が展開するリクエストの本文の2つです。毎回は成功せず、何度か試す必要があったとしています。攻撃コードは公開していません。
• クラッシュを起こす PoC は公開されています。x86_64 でのネットワーク越しの RCE を主張するものもありますが、この記事では検証していません。
• CISA の評価（SSVC）では、悪用は「なし」です。攻撃が成功して侵害された事例は、この記事を書いた時点では一次情報で確認できていません。

RCE までは条件が厳しい一方、プロセスを落とすだけなら細工したデータを1つ送れば足ります。認証なしで Web サーバーを止められる可能性があるので、少なくとも DoS としては深刻に扱うべきです。

攻撃データが入り込む経路

この脆弱性で大事なのは、「どこで Brotli のデータを展開しているか」です。経路は大きく3つあります。

1. サーバーがリクエストの本文を展開する

クライアントが Content-Encoding: br を付けて圧縮した本文を送り、サーバー側のフレームワークがそれを自動で展開する経路です。攻撃者は、外から1回リクエストを送るだけで攻撃できます。いちばん危険な経路です。

• Express 5（body-parser 2.x）は、br の本文を zlib.createBrotliDecompress() で展開します。express.json() や express.raw() などを使っていれば対象です。
• Express 4（body-parser 1.x）は br を展開しません。ただし gzip と deflate は展開します。
• Node.js の node:http だけで作ったサーバーは、受け取るだけでは展開しません（Imperva）。
• ASP.NET Core は、リクエストの展開を有効にしていなければ展開しません（後述）。

2. クライアントやプロキシがレスポンスを展開する

サーバーやアプリが外部の URL にアクセスして、返ってきた br のレスポンスを展開する経路です。攻撃者は、自分が用意したサーバーへアクセスさせるか、通信を改ざんする必要があります。

• Node.js の fetch() は、br のレスポンスを自動で展開します。
• Next.js の画像の最適化（/_next/image）は、外部の画像を取りにいくときに br を展開します。Vercel は「Next.js は画像の最適化で Brotli のレスポンスをブロックしない」としています（Vercel）。
• Python の urllib3 / requests、aiohttp は、Brotli のパッケージが入っていれば br を展開します。
• Bun の fetch() も既定で展開します。
• curl は --compressed（libcurl では CURLOPT_ACCEPT_ENCODING）を指定したときに展開します。
• Accept-Encoding から br を外すだけでは守れません。curl のドキュメントにもあるとおり、サーバーは頼んでいない形式で返してくることがあります。

3. アプリが自分で展開する

zlib.brotliDecompress()、Python の brotli.decompress()、.NET の BrotliStream などに、外から受け取ったデータを渡している場合です。アップロードされたファイルや、キューから届くメッセージを展開する処理がこれに当たります。

影響を受けるバージョンと修正版

Brotli 本体（C 実装）の影響範囲は、CVE レコードで次のとおりです。

Brotli を同梱している製品は、製品ごとに修正版が出ています。

構成ごとの対応方法

Node.js（公式のバイナリ、nvm、Volta など）

公式のバイナリは Brotli を同梱しています。修正版の Node.js に入れ替えて、アプリを再起動します。

node -v   # v22.23.4 / v24.22.1 / v26.12.1 以降なら修正済み

• 20.x 以前は修正が出ません（20.x は2026年4月末でサポート終了）。22.x か 24.x に上げます。
• pm2 や systemd で動かしている場合は、プロセスを再起動するまで古い Node.js のままです。
• NodeSource などのパッケージで入れた Node.js も、Brotli を同梱しているので、Node.js 自体の更新が必要です。

Node.js（Ubuntu / Debian の OS パッケージ）

Ubuntu 22.04 以降と Debian の nodejs パッケージは、OS の Brotli（libbrotli）を使っています。この場合は Node.js ではなく、OS の Brotli を更新します。

sudo apt update && sudo apt install --only-upgrade libbrotli1

更新後に、Node.js のアプリを再起動します。Ubuntu 20.04 の nodejs は Brotli を同梱していて、10月27日時点で修正が出ていません（Ubuntu）。公式のバイナリの Node.js 22 以上に切り替えるのが確実です。

Express / Next.js

• Express 5 を使っているなら、リクエストの本文が攻撃の入口になります。Node.js の更新を最優先にしてください。すぐに更新できない場合の対処は、後述の緩和策を参照してください。
• Next.js をセルフホストしているなら、Node.js を更新します。画像の最適化が外部の画像を取りにいく構成（images.remotePatterns で外部のホストを許可している）は、レスポンスの展開の経路に当たります。
• Vercel の場合、22.x と 24.x は Vercel が修正版への入れ替えを進めていて、利用者がバージョンを変える必要はありません。Node.js 20.x を使っているプロジェクトは、22.x か 24.x に変えて再デプロイします。Vercel は、未修正の Node.js では外へのリクエストの Brotli の展開を止める保護も入れていて、既存のプロジェクトは再デプロイで有効になります（Vercel）。

Docker（公式の node / python イメージ）

公式の node:22 / node:24 / node:26 などは、10月22日に修正版で更新されました。ベースイメージを取り直して作り直します。

docker build --pull --no-cache -t myapp .
docker run --rm --entrypoint node myapp -v   # 作ったイメージの Node.js が修正版か確認

node:24.22.0 のように版を固定している場合は、FROM の版を書き換えます。python のイメージなど Debian ベースのイメージは、中の libbrotli1 も確認してください。ベースイメージの更新が追いついていない場合は、Dockerfile に次の行を足して作り直します。

RUN apt-get update && apt-get install -y --only-upgrade libbrotli1 && rm -rf /var/lib/apt/lists/*

イメージを作り直しただけでは、動いているコンテナは古いままです。新しいイメージからコンテナを作り直します（Docker Compose なら docker compose up -d。イメージを変えずに restart しても入れ替わりません）。最後に、動いているコンテナの中で確認します。

docker compose exec <サービス名> node -v

Bun

1.4.4 に更新します（bun upgrade）。bun build --compile で作った実行ファイルは、Bun 本体を同梱しているので、1.4.4 で作り直す必要があります（Bun のアドバイザリ）。

Python

Brotli（C 拡張）と brotlicffi は、どちらも C 実装を使っています。

pip install -U "Brotli>=1.2.1"
pip install -U "brotlicffi>=1.2.1.0"   # brotlicffi を使っている場合

• requests / urllib3 / aiohttp は、これらのパッケージが入っているだけで br のレスポンスを自動で展開します。自分で Brotli を使っているつもりがなくても、依存関係で入っていることがあります。
• OS の python3-brotli を使っている場合は、OS のパッケージを更新します（Ubuntu は USN-8956-1 で修正）。
• 更新後に、Gunicorn や Celery などのワーカーを再起動します。

nginx / Apache httpd

nginx と Apache の Brotli モジュールは、圧縮しかしません。nginx の ngx_brotli と Apache の mod_brotli は、レスポンスを Brotli で圧縮するためのもので、デコーダを使っていません。Web サーバー自体が攻撃の入口になることはありません。

ただし、同じサーバーで動いているアプリケーション（Node.js、Python、PHP など）は別です。OS の Brotli を更新したうえで、アプリのプロセスも再起動してください。nginx や Apache を手前に置いているなら、後述の緩和策で br のリクエストを止める場所として使えます。

curl / PHP / WordPress

• curl は OS の Brotli を使います。OS のパッケージを更新すれば直ります。curl -V の出力に brotli と出ていれば、Brotli 対応でビルドされています。
• PHP 本体は Brotli を含みません。ただし、cURL 拡張は libcurl を通して OS の Brotli を使うことがあります。Windows 版の PHP は Brotli を同梱しているため、php.net が10月26日にビルドを更新しました（php.net）。PECL の brotli 拡張は 0.21.1 で修正されています。
• WordPress の影響を明言した一次情報はありません。ただ、WordPress が外部と通信するときに使う Requests ライブラリは、cURL の自動展開を有効にしています（CURLOPT_ENCODING に空文字を設定）。サーバーの libcurl が Brotli 対応なら、wp_remote_get() などで受け取った br のレスポンスは OS の Brotli で展開されます。OS の Brotli を更新して、PHP-FPM や Apache を再起動しておくのが安全です。

Envoy / Istio

Envoy は、Brotli の展開のフィルタ（decompressor）を設定している場合だけ影響を受けます。該当する場合は修正版に上げます。Istio は、EnvoyFilter などで Brotli の展開を有効にしている場合に更新が必要です（Istio）。

.NET

.NET の Brotli（System.IO.Compression）も同じ C 実装です。発行の形式によって、やることが違います。

• ランタイムを別に入れて動かすアプリ（framework-dependent）: サーバーのランタイムを 8.0.33 / 9.0.22 / 10.0.14 に更新して、アプリを再起動します。
• ランタイムを同梱したアプリ（self-contained）と NativeAOT のアプリ: サーバーのランタイムを更新しても直りません。修正版の SDK で発行し直して、配置し直します。

Microsoft によると、ASP.NET Core のリクエストの展開と、HttpClient のレスポンスの自動展開は、既定では無効です。これらを有効にしているか、BrotliStream などを直接使っている場合に影響を受けます（.NET のアドバイザリ）。.NET Framework は影響を受けません。

ブラウザ

Chrome と Firefox は、春の時点で修正のコミットより新しい Brotli を取り込んでいます（Chrome は 148 以降。どちらもこの CVE の修正としての取り込みではなく、取り込んだ版から判断したもの）。ふだんどおり最新版に更新していれば、特別な作業はいりません。ただし、Red Hat は RHEL の Firefox と Thunderbird を影響ありとしているので、Linux のディストリビューションのパッケージで入れている場合は、各ディストリビューションの更新を待って適用してください。

OS のパッケージ

Ubuntu と Debian は、上流のバージョン番号（1.1.0 など）は変わらず、末尾の改訂番号だけが変わります。1.1.0 と表示されていても、改訂番号が上の表と同じかそれ以降なら修正済みです。

RHEL / AlmaLinux / Rocky Linux は、10月26日時点で通常の修正パッケージが出ていません。Red Hat は調査中（Ongoing）としていて、RHEL 7〜10 の brotli を影響ありとしています。修正が出るまでは、次の緩和策を入れておきます。

すぐに更新できないときの緩和策

Google と Node.js は、緩和策を出していません。以下は Red Hat などが案内している、攻撃データの入口を減らす方法です。どれも更新の代わりにはなりません。

リクエストの本文の br を入口で拒否する

ふつうのブラウザは、リクエストの本文を Brotli で圧縮して送りません。そのため Content-Encoding: br のリクエストを拒否しても、多くのサイトでは困りません（API のクライアントが圧縮して送っている場合は、事前に確認してください）。Red Hat も、信頼できない相手からの br を受け付けない・自動で展開しないことを勧めています。

nginx（server ブロック）:

if ($http_content_encoding ~* "(^|,)\s*br\s*(,|$)") {
    return 415;
}

Apache httpd 2.4（バーチャルホストの設定）:

<If "req('Content-Encoding') =~ /(^|,)\s*br\s*(,|$)/i">
    Require all denied
</If>

設定を変えたら、構文を確認してから再読み込みします。

sudo nginx -t && sudo systemctl reload nginx
sudo apachectl configtest && sudo systemctl reload apache2   # RHEL 系は httpd

Express では、本文のパーサーより前で拒否できます。

app.use((req, res, next) => {
  const encodings = (req.headers['content-encoding'] || '').toLowerCase().split(',')
  if (encodings.some((e) => e.trim() === 'br')) return res.status(415).end()
  next()
})
app.use(express.json())

Cloudflare は、Content-Encoding: br のリクエストと /_next/image へのリクエストに当たるルールを、マネージドルールセットに追加しました。ただし既定の動作はログだけ（Log）で、ブロックはしません（Cloudflare）。止めたい場合は、ルールの動作をブロックに変える必要があります。

レスポンスの展開を止める

外部から受け取るレスポンスの経路は、入口のフィルタでは防げません。展開そのものを止めます。

• Bun: fetch(url, { decompress: false })
• .NET: 既存の設定から br と DecompressionMethods.Brotli を外す（Microsoft は、展開を使っていないアプリに新たに設定を書き足さないよう注意しています）
• Python: 一時的に Brotli と brotlicffi をアンインストールする。requests などは br を使わなくなる
• Node.js: zlib.brotliDecompress() などに信頼できないデータを渡さない。fetch() の自動展開は止められないので、Node.js の更新を急ぐ
• Next.js: 外部の画像を取りにいく画像の最適化を、Node.js を更新するまで使わない（images.unoptimized: true など）

影響を受けるか・更新できたかを確かめる

1. ランタイムやパッケージの版を確かめる。

node -v                                  # Node.js
npm ls express body-parser               # Express 5 / body-parser 2.x を使っているか
bun --version                            # Bun
pip show Brotli brotlicffi               # Python
dpkg-query -W libbrotli1 python3-brotli  # Ubuntu / Debian（改訂番号を上の表と比べる）
rpm -qa | grep -i brotli                 # RHEL 系 / Amazon Linux
apk info -v | grep -i brotli             # Alpine
curl -V | grep -i brotli                 # curl が Brotli 対応か

2. 古いライブラリを使ったままのプロセスがないか確かめる（Linux）。OS の Brotli を更新したあと、更新前のライブラリを読み込んだまま動いているプロセスは、(deleted) の付いた古いファイルを使い続けています。

sudo grep -l 'libbrotlidec.*(deleted)' /proc/[0-9]*/maps

表示されたパス（/proc/<PID>/maps）の PID のプロセスを再起動します。Ubuntu や Debian なら needrestart でも確認できます。

3. Brotli を同梱しているものを探す。OS のパッケージを更新しても、Node.js の公式バイナリ、Bun、bun build --compile の実行ファイル、Python の wheel、self-contained や NativeAOT の .NET アプリ、Electron のアプリなどは、自前の Brotli を持っています。コンテナのイメージは、SBOM や脆弱性スキャナ（Trivy など）で CVE-2026-111497 を検索すると見つけやすくなります。

まとめ

• HTTP2Shell（Node2Shell）は、Brotli の C 実装の展開処理で、細工したデータがメモリの範囲外に書き込まれる脆弱性 CVE-2026-111497 の通称。HTTP/2 の脆弱性ではない
• CVSS v4.0 は 9.2（Google）、Red Hat などは 8.1。Node.js での RCE が実証されている。悪用の報告は10月27日時点でない
• 危険なのは展開する側。Express 5 のリクエストの本文、fetch() や Next.js の画像の最適化、Python の requests などのレスポンスが入口になる。nginx と Apache の Brotli モジュールは圧縮だけで関係しない
• 対応は Node.js 26.12.1 / 24.22.1 / 22.23.4、Brotli 1.2.1 / 1.1.1 / 1.0.10、OS の libbrotli の更新と、プロセスの再起動。process.versions.brotli では判断できない
• すぐに更新できないなら、Content-Encoding: br のリクエストを入口で拒否する。レスポンスの経路はそれでは防げない

同じ週に公表された PHP 本体の脆弱性は、「PHP2Shell（CVE-2026-109618 / CVE-2026-109619）とは」にまとめています。Brotli などの圧縮の仕組みそのものは「データ圧縮の仕組み 入門」で解説しています。

参考資料

• CVE-2026-111497（CVE レコード） / NVD
• google/brotli v1.2.1 のリリース
• 修正のコミット「Detect and report invalid stream earlier.」（google/brotli）
• Wednesday, October 21, 2026 Security Releases（Node.js）
• Node2Shell: From Brotli Data to Remote Code Execution（Imperva）
• BrotliのC言語実装における境界外書き込みの脆弱性（CVE-2026-111497）に関する注意喚起（JPCERT/CC）
• RHSB-2026-015（Red Hat）
• USN-8956-1（Ubuntu）
• Debian セキュリティトラッカー CVE-2026-111497
• Amazon Linux Security Center CVE-2026-111497
• GHSA-663w-cv8g-jj2p（Bun）
• Microsoft Security Advisory CVE-2026-111497（.NET）
• ISTIO-SECURITY-2026-007（Istio）
• Node.js security advisory（Vercel）
• WAF changelog（Cloudflare）
• Updated PHP Windows builds for Brotli security fix（php.net）