【CVE-2026-111497】Brotliの脆弱性（Broccoli2Shell）
概要
Googleが開発するデータ圧縮ライブラリ「Brotli」において、細工された圧縮ストリームを展開（デコード）する際に境界外書き込みが発生する脆弱性が公表された。未認証の遠隔の攻撃者から悪意あるBrotli圧縮ストリームを処理させられることで、隣接するデコーダー状態メモリの破壊、機密メモリ内容の漏洩、サービス拒否（DoS）、または任意のコード実行（RCE）に至る可能性がある1。
項目
内容
CVE ID
CVE-2026-111497
対象ソフトウェア
Google Brotli（C言語デコーダー実装 c/dec/decode.c）
CVSSスコア
・9.2 Critical (CVSS:4.0/AV:N/AC:L/AT:P/PR:N/UI:N/VC:H/VI:H/VA:H/SC:N/SI:N/SA:N — Google CNA / GitHub)
・9.8 Critical (CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H — NVD)
・8.1 High / Important (CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:H/I:H/A:H — Microsoft / Red Hat / AWS)
脆弱性種別
CWE-252: 戻り値の未チェック（Unchecked Return Value）、CWE-787: 境界外書き込み（Out-of-bounds Write）
発見・報告者
Khai Tran 氏、Sylvie Mayer 氏（OpenAI Codex Security）
悪用・KEV登録状況
Imperva社がNode.js 24.22.0（Linux arm64公式イメージ）環境でのRCE実証を報告。2026年10月27日付で米国CISA KEVに追加（対策期限: 2026年11月10日）
本脆弱性は、発見から波及範囲の判明に至る経緯の中で以下の3つの通称で呼ばれている。
Node2Shell: 2026年10月21日のNode.jsセキュリティリリース公表後、Imperva Red TeamがNode.js組み込みBrotliデコーダーにおける解析およびRCE実証に命名した呼称である4。
HTTP2Shell: 当初はNode.jsに関連して「Node2Shell」と呼称されていたが、根本原因がHTTP通信（Content-Encoding: br）等で広く利用されるBrotliのC言語実装にあり、複数製品が影響を受けることから「HTTP2Shell」とも呼称されている（HTTP/2プロトコル自体の脆弱性ではない）5。
Broccoli / Broccoli2Shell: セキュリティ研究者のJuliano Rizzo氏が「Node2Shellという名称は影響範囲を狭く見せてしまう」として「Broccoli」と呼ぶことを提唱したことに端を発し、追跡サイト「broccoli2shell.com」等で用いられている呼称である6。
影響を受けるバージョンと修正バージョン
1. Brotli の影響範囲と修正状況
Brotliの公式C実装において、バージョン 1.0.3 から 1.2.0 までのデコーダーが影響を受ける。各系統の修正バージョンは以下の通りである1。
系統 / ブランチ
影響を受けるバージョン
修正版
補足
1.0 系
>= 1.0.3, < 1.0.10
1.0.10
コミット 50a9b70a（0ed4268a のバックポート）
1.1 系
>= 1.1.0, < 1.1.1
1.1.1
コミット da980636（0ed4268a のバックポート）
1.2 系
>= 1.2.0, < 1.2.1
1.2.1
コミット b418fa81 / 0ed4268a
2. 主要ランタイム・言語パッケージ・アプライアンスの対応状況
BrotliのC言語デコーダーをバンドルまたはバインディングとして組み込んでいる各ランタイム・パッケージおよびネットワーク製品の対応状況は以下の通りである。
ランタイム / 製品
影響を受けるバージョン
修正版
補足
Node.js (v24 LTS)
24.x（< 24.22.1）
v24.22.1 / v24.22.2 3
v24.22.1 で修正（v24.22.2 はリグレッション修正版）
Node.js (v22 LTS)
22.x（< 22.23.4）
v22.23.4
組み込みBrotliの更新（2026年10月セキュリティリリース）
Node.js (v26 Current)
26.x（< 26.12.1）
v26.12.1
組み込みBrotliの更新（EOL系統の <= 20.x, 23.x, 25.x も影響対象）
Bun
>= 1.0.21, < 1.4.4
1.4.4 8
バンドルするBrotliを 1.2.0 から 1.2.1 へ更新（GHSA-663w-cv8g-jj2p）
Python (brotli / PyPI)
>= 1.0.3, < 1.2.1
1.2.1 7
PyPI上の公式C拡張パッケージ（GHSA-9v8h-qqgm-4m35）
Python (brotlicffi / PyPI)
>= 1.0.3, < 1.2.1.0
1.2.1.0
Brotli C実装のCFFIバインディング（GHSA-9v8h-qqgm-4m35）
.NET 8 / 9 / 10
8.0.0〜8.0.32
9.0.0〜9.0.21
10.0.0〜10.0.13
Runtime 8.0.33
Runtime 9.0.22
Runtime 10.0.14 9
SDKは 8.0.133/8.0.427、9.0.123/9.0.320、10.0.114/10.0.403 で修正
Palo Alto Networks PAN-OS
PAN-OS 12.2 / 12.1 / 11.2 の未修正版
12.2.4-h1
12.1.7-h11 等 6
データプレーンでTLS復号とBrotli検査を有効化している場合のみ影響（デフォルト無効）
3. 主要Linuxディストリビューションの対応状況
OSの共有ライブラリ（libbrotli）およびディストリビューション提供パッケージにおける対応状況は以下の通りである。ディストリビューションによってはNode.jsや.NETパッケージがOS標準の共有ライブラリ（libbrotli）を動的リンクしているため、影響有無がパッケージ単位で異なる点に注意が必要である。
ディストリビューション
対象パッケージ
修正版
補足
Amazon Linux 2023
brotli, libbrotli, python3-brotli
nodejs24, dotnet8.0
1.1.0-1.amzn2023.0.2
アドバイザリ: ALAS2023-2026-3334（brotli）、ALAS2023-2026-3330（nodejs24）、ALAS2023-2026-3367（dotnet8.0）。nodejs22・dotnet9.0・dotnet10.0 は影響なし
Ubuntu
brotli, libbrotli1, python3-brotli
dotnet8, dotnet10, dotnet11
24.04 LTS: 1.1.0-2ubuntu0.1
22.04 LTS: 1.0.9-2ubuntu0.1
アドバイザリ: USN-8956-1（Brotli）、USN-8958-1（.NET 8.0.33 / 10.0.14）
Debian
brotli, libbrotli1
Trixie (13): 1.1.0-2+deb13u1
Bookworm (12): 1.0.9-2+deb12u1
DSA-6582-1 / DLA-4855-1。Debianの nodejs と python-brotlicffi はシステムの brotli を利用
RHEL (Red Hat)
brotli, nodejs:24, dotnet8.0, firefox, thunderbird
提供済（各RHSA）
RHSB-2026-015（Important）。RHEL 8/9の nodejs:22、RHEL 10の nodejs22/nodejs24、および dotnet9.0/10.0/11.0 はシステムの brotli を利用
4. AWS マネージドサービスの対応状況
AWSの 2026-155-AWS で公表されている主要マネージドサービスの対応状況は以下の通りである10。
対象サービス / リソース
修正版
補足
AWS Lambda（Node.js 22/24/26、.NET 8/9/10）
更新済
マネージドランタイム・ベースイメージ更新済。コンテナイメージ利用時は最新ベースイメージでの再ビルドが必要（Python/Ruby/provided.al2023 はBrotli非同梱）
AWS Elastic Beanstalk (Node.js)
6.11.12
Node.js 24.22.1 および 22.23.4 を含むプラットフォームバージョン 6.11.12 を提供済
AWS App Runner / Amplify / CodeBuild / Synthetics
更新済
App Runnerは2026年10月26日に全リージョン更新済（未デプロイのサービスは1回再デプロイが必要）
影響を受ける条件
本脆弱性は、ライブラリがシステム上に存在するだけでは発火せず、「信頼できないBrotli圧縮ストリームを、対象アプリケーションやプロキシがデコード（展開）する」 処理が行われた際に成立する6。
1. 前提となるシステム・ネットワーク構成
攻撃が成立する代表的な経路は以下の4パターンである。
パターン1：クライアントからの圧縮HTTPリクエストボディを展開するサーバー / API
クライアントから送信された Content-Encoding: br ヘッダー付きのリクエストボディを、ミドルウェア（Node.jsのExpress 5.0.0〜5.3.0やbody-parser 2.0.0〜2.3.0における raw() / json() 等）やバックエンドアプリケーションが自動または明示的にBrotli展開している構成（なお、素の node:http サーバー自体は単体ではリクエストボディを自動展開しない）。
パターン2：外部サーバーからの圧縮HTTPレスポンスを展開するHTTPクライアント / クローラー
接続先サーバーから返却された Content-Encoding: br レスポンスを自動展開する構成（Node.jsやBunの組み込み fetch()、Brotliパッケージがインストールされた環境でのPython urllib3 / requests / aiohttp / httpx[brotli] 等）。
多くのHTTPクライアントはリクエスト時に Accept-Encoding: br を送信したかどうかにかかわらず、レスポンスヘッダーに Content-Encoding: br が含まれていれば自動的にBrotliデコーダーを呼び出す。そのため、任意のURLを取得するWebhook、リンクプレビュー、クローラー、または非暗号化通信経路上の中間者攻撃において、悪意あるサーバーから一方的に Content-Encoding: br のレスポンスを返されるだけでトリガーされ得る。
パターン3：ファイアウォール等のデータプレーンにおけるトラフィック検査
Palo Alto NetworksのPAN-OS（PA-Series / VM-Series）において、データプレーン上でTLS/SSL復号（Decryption）とBrotliインスペクションの両方が有効化されている場合、通過するBrotliトラフィックをファイアウォール自身が展開するため影響を受ける。
パターン4：デコーダーAPIの直接呼び出し・ファイル処理
アーカイブ、キャッシュ、メッセージキュー等の外部データを、node:zlib（brotliDecompress*、createBrotliDecompress）、Web標準の DecompressionStream、Pythonの brotli.decompress()、.NETの BrotliStream / BrotliDecoder 等で直接展開している場合。
!
影響を受けないケース:
圧縮（エンコード）のみ・静的 .br ファイル配信のみの構成: 脆弱性はデコーダー（c/dec/decode.c）に存在するため、信頼できるデータをサーバー側でBrotli圧縮して送信するのみの構成や、事前圧縮された静的な .br ファイルをそのまま配信するだけの構成ではデコード処理が行われず、影響を受けない。
.NET のデフォルト挙動: Microsoftのアドバイザリによれば、ASP.NET Coreおよび HttpClient はデフォルトではBrotli圧縮データを自動展開しない。自動展開でBrotliを有効化するよう明示的に設定変更している場合、または System.IO.Compression（BrotliStream / BrotliDecoder）で信頼できないデータを直接展開している場合のみ影響を受ける9。
2. スタンドアロン実行ファイル・コンテナイメージに関する注意点
自己完結型バイナリ（Self-Contained / 単一実行ファイル）:
.NETのSelf-ContainedデプロイやNativeAOTでビルドされたアプリケーション、およびBunの bun build --compile で生成された実行ファイルは、ビルド時点のランタイム（および脆弱なBrotliデコーダー）をバイナリ内部に埋め込んでいるため、ランタイム更新後にアプリケーションの再ビルドと再デプロイが必要である。
動的リンクとバンドルの違い:
Red Hat Enterprise LinuxやDebian、Amazon Linux 2023では、パッケージによってBrotliを内部バンドルしているもの（例：AL2023およびRHEL 8/9の nodejs24、dotnet8.0）と、OSの共有ライブラリ libbrotli を動的リンクしているもの（例：Debianの nodejs、RHEL 8/9およびAL2023の nodejs22、dotnet9.0、dotnet10.0）が混在している。したがって、OSパッケージとランタイムの双方を確認・更新し、実行中のプロセスを再起動する必要がある。
3. 自環境の確認方法
1. Node.js のバージョンおよびバンドルされている Brotli バージョンの確認
node --version
node -p "process.versions.brotli"
2. Bun のバージョン確認（1.4.4 以上であるか）
bun --version
3. .NET ランタイムのバージョン確認（8.0.33 / 9.0.22 / 10.0.14 以上であるか）
dotnet --list-runtimes
4. Python パッケージの確認（Brotli 1.2.1 以上、brotlicffi 1.2.1.0 以上であるか）
python3 -m pip show brotli brotlicffi
5. Linux OSパッケージおよびロード済み共有ライブラリの確認
dpkg -l | grep -i brotli # Debian / Ubuntu
rpm -qa | grep -i brotli # RHEL / Amazon Linux
sudo grep -l brotlidec /proc/[0-9]*/maps 2>/dev/null
脆弱性の技術的な仕組み
前提：Brotliのブロック切り替えと高速パス（Fast Path）/ 安全パス（Safe Path）
Brotliの圧縮ストリームは複数のブロックに分割されており、デコーダーはストリームを読み進めながらリテラル（tree_type = 0）、挿入・コピーコマンド（tree_type = 1）、距離コード（tree_type = 2）のブロックタイプを切り替える。
ブロックタイプを切り替える際、デコーダーは c/dec/decode.c 内の DecodeBlockTypeAndLength() を呼び出して次のブロックタイプ番号とブロック長をビットストリームから読み取る。このときBrotliデコーダーは、入力バッファに十分なデータがある場合に境界チェックを省略して高速に処理する Fast Path（safe = 0） と、入力不足を検査しながら処理する Safe Path（safe = 1） の2つの経路を持っている。
原因：戻り値の未チェック（CWE-252）と境界外書き込み（CWE-787）
脆弱性の根本原因は、c/dec/decode.c 内の DecodeBlockTypeAndLength() が返す真偽値 BROTLI_BOOL の仕様と、呼び出し元における戻り値の未チェックにある1。
戻り値 BROTLI_FALSE における2種類の意味の混在:
修正前の DecodeBlockTypeAndLength() は戻り値として単なる真偽値（BROTLI_BOOL）を返していた。この関数は、Safe Pathで入力ビットが一時的に不足している場合（!SafeReadSymbol や !SafeReadBlockLength）に BROTLI_FALSE を返すだけでなく、ストリームのブロックタイプ最大数 max_block_type が 1 以下であるにもかかわらずブロック切り替えが要求されたというストリーム構文エラー（フォーマット不正） の場合（if (max_block_type <= 1) return BROTLI_FALSE;）にも同じ BROTLI_FALSE を返していた。
Fast Path（safe = 0）での戻り値の無視:
修正前のコードでは、Fast Path用のラッパー関数 DecodeLiteralBlockSwitch()、DecodeCommandBlockSwitch()、DecodeDistanceBlockSwitch() の戻り値型が static void と定義されており、内部で呼び出す Decode*BlockSwitchInternal(0, s) の戻り値を完全に無視していた。さらに呼び出し元のマクロ BROTLI_SAFE(METHOD) も、safe == 0 の分岐では戻り値を検証せずにそのまま処理を継続する実装となっていた。
不正な内部状態でのデコード継続と境界外書き込み:
細工された圧縮ストリームによって本来起こり得ないブロック切り替えが要求された際、脆弱なデコーダーは構文エラーで停止せず、「追加入力が必要である」状態と誤認する、あるいはFast Path上でエラーを無視して不整合な内部状態のまま処理を継続してしまう。その結果、内部バッファの終端を越えて攻撃者のバイト列が書き込まれ、隣接するデコーダー状態メモリ（BrotliDecoderState）の破壊や機密メモリの漏洩、さらには任意のコード実行（RCE）へとつながる。
攻撃フロー
修正パッチ
Googleの公式リポジトリにおける修正コミット 0ed4268a（および各ブランチへの反映コミット 50a9b70a、da980636、b418fa81）では、以下の変更が行われている2。
c/include/brotli/decode.h に、ブロック切り替えのフォーマット異常を表す新しいエラーコード BROTLI_DECODER_ERROR_FORMAT_BLOCK_SWITCH = -17 を追加。
DecodeBlockTypeAndLength() および各 Decode*BlockSwitch*() 関数の戻り値型を BROTLI_BOOL / void から BrotliDecoderErrorCode に変更し、max_block_type <= 1 のフォーマット異常時は BROTLI_DECODER_ERROR_FORMAT_BLOCK_SWITCH、入力不足時は BROTLI_DECODER_NEEDS_MORE_INPUT、成功時は BROTLI_DECODER_SUCCESS を明示的に返すように修正。
Safe PathとFast Pathの両方でステータスコードを検証し、BROTLI_DECODER_SUCCESS 以外の場合は即座に saveStateAndReturn へジャンプして処理を中断するマクロ BROTLI_SAFE_WITH_STATUS(METHOD) を導入。
c/dec/decode.c
// google/brotli commit 0ed4268a より抜粋
-static BROTLI_INLINE BROTLI_BOOL DecodeBlockTypeAndLength(
+static BROTLI_INLINE BrotliDecoderErrorCode DecodeBlockTypeAndLength(
int safe, BrotliDecoderState* s, int tree_type) {
brotli_reg_t max_block_type = s->num_block_types[tree_type];
const HuffmanCode* type_tree = &s->block_type_trees[
@@ -1187,7 +1187,7 @@
brotli_reg_t* ringbuffer = &s->block_type_rb[tree_type * 2];
brotli_reg_t block_type;
if (max_block_type <= 1) {
- return BROTLI_FALSE;
- return BROTLI_DECODER_ERROR_FORMAT_BLOCK_SWITCH;
}
/* Read 0..15 + 3..39 bits. */
@@ -1197,11 +1197,13 @@
} else {
BrotliBitReaderState memento;
BrotliBitReaderSaveState(br, &memento);
- if (!SafeReadSymbol(type_tree, br, &block_type)) return BROTLI_FALSE;
- if (!SafeReadSymbol(type_tree, br, &block_type)) {
- return BROTLI_DECODER_NEEDS_MORE_INPUT;
- }
if (!SafeReadBlockLength(s, &s->block_length[tree_type], len_tree, br)) {
s->substate_read_block_length = BROTLI_STATE_READ_BLOCK_LENGTH_NONE;
BrotliBitReaderRestoreState(br, &memento);
- return BROTLI_FALSE;
- return BROTLI_DECODER_NEEDS_MORE_INPUT;
}
}
...
ringbuffer[0] = ringbuffer[1];
ringbuffer[1] = block_type;
- return BROTLI_TRUE;
- return BROTLI_DECODER_SUCCESS;
}
-static BROTLI_INLINE BROTLI_BOOL DecodeLiteralBlockSwitchInternal(
+static BROTLI_INLINE BrotliDecoderErrorCode DecodeLiteralBlockSwitchInternal(
int safe, BrotliDecoderState* s) {
- if (!DecodeBlockTypeAndLength(safe, s, 0)) {
- return BROTLI_FALSE;
- BrotliDecoderErrorCode result = DecodeBlockTypeAndLength(safe, s, 0);
- if (result != BROTLI_DECODER_SUCCESS) {
- return result;
}
PrepareLiteralDecoding(s);
- return BROTLI_TRUE;
- return BROTLI_DECODER_SUCCESS;
}
-static void BROTLI_NOINLINE DecodeLiteralBlockSwitch(BrotliDecoderState* s) {
- DecodeLiteralBlockSwitchInternal(0, s);
+static BROTLI_NOINLINE BrotliDecoderErrorCode
+DecodeLiteralBlockSwitch(BrotliDecoderState* s) {
- return DecodeLiteralBlockSwitchInternal(0, s);
}
呼び出し元のマクロも以下のように BROTLI_SAFE_WITH_STATUS へ置き換えられ、safe フラグの有無にかかわらずエラー発生時にデコードが即座に停止するようになった。
c/dec/decode.c
+/* NB: METHOD should return BROTLI_DECODER_SUCCESS, BROTLI_DECODER_ERROR_*, or
- BROTLI_DECODER_NEEDS_MORE_INPUT; the later two break the processing. */
+#define BROTLI_SAFE_WITH_STATUS(METHOD) \
- { \
- BrotliDecoderErrorCode status; \
- if (safe) { \
- status = Safe##METHOD; \
- } else { \
- status = METHOD; \
- } \
- if (status != BROTLI_DECODER_SUCCESS) { \
- result = status; \
- goto saveStateAndReturn; \
- } \
- }
対策と緩和策
1. 恒久対策：修正バージョンへのアップデートと再ビルド
利用しているOSパッケージ、言語ランタイム、および依存ライブラリを修正バージョンへ更新し、稼働中のプロセスを再起動する。また、単一実行ファイル化（Bunの bun build --compile、.NETのSelf-Contained / NativeAOT）やDockerコンテナイメージを利用している場合は、更新後のランタイム・ベースイメージを用いて再ビルドおよび再デプロイを実施する必要がある。
各環境におけるアップデートコマンド例# 1. Amazon Linux 2023 の場合（ALAS2023-2026-3334 / 3330 / 3367）
sudo dnf update brotli nodejs24 dotnet8.0 -y
2. Ubuntu / Debian の場合（USN-8956-1 / USN-8958-1 / DSA-6582-1）
sudo apt update && sudo apt install --only-upgrade brotli libbrotli1 python3-brotli -y
3. Node.js の更新（nvm を利用している場合）
nvm install 24.22.1 # または 22.23.4 / 26.12.1
4. Python パッケージ（PyPI）の更新（1.2.1 / 1.2.1.0 以上）
pip install -U "Brotli>=1.2.1" "brotlicffi>=1.2.1.0"
5. Bun の更新（1.4.4 以上）
bun upgrade
2. 一時的な緩和策（アップデートが直ちに実施できない場合）
各ベンダーのアドバイザリおよび技術資料では、即座にパッチを適用できない環境向けに以下の緩和策が案内されている。
WAFやリバースプロキシにおける受信 Content-Encoding: br リクエストの遮断:
AWSのセキュリティブレティン 2026-155-AWS 等では、クライアントから送信される Content-Encoding: br ヘッダー付きHTTPリクエストをWAFやプロキシで拒否する緩和策が提示されている。AWSが公開しているAWS WAFカスタムルールの設定例（Countモードで検証後に "Count": {} を "Block": {} に変更する手順）は以下の通りである。なお、AWS WAFは受信リクエストのみを検査するため、アプリケーションが外部サーバーから取得するレスポンスには効かない点に留意が必要である10。
{
"Name": "Node2Shell_BROTLI",
"Priority": 2,
"Statement": {
"RegexMatchStatement": {
"RegexString": "^\s*br\s*$",
"FieldToMatch": { "SingleHeader": { "Name": "content-encoding" } },
"TextTransformations": [ { "Priority": 0, "Type": "LOWERCASE" } ]
}
},
"Action": { "Count": {} },
"RuleLabels": [ { "Name": "Node2Shell_Brotli" } ],
"VisibilityConfig": {
"SampledRequestsEnabled": true,
"CloudWatchMetricsEnabled": true,
"MetricName": "Node2Shell_BROTLI"
}
}
HTTPクライアントおよびPython環境におけるBrotliデコードの抑止:
注意点（Accept-Encoding ヘッダー変更の限界）: リクエストヘッダーの Accept-Encoding から br を除外したとしても、悪意あるサーバーはそれを無視して Content-Encoding: br のレスポンスを送りつけることができるため、クライアント側で自動解凍自体が有効なままでは対策として不十分である。
Bun: セキュリティアドバイザリ（GHSA-663w-cv8g-jj2p）では、fetch 呼び出し時に decompress: false を渡すことで、Accept-Encoding: br の送信を抑止するとともにレスポンス自体の自動デコードを無効化する回避策が案内されている8。
Python: 直ちにアップグレードできない場合の緩和策として、Brotli および brotlicffi パッケージ（ならびに httpx[brotli] 等のextra指定）自体をアンインストールし、urllib3、requests、aiohttp 等でBrotliデコーダーが呼び出されない状態（gzip / deflate へのフォールバック）にする方法が挙げられている6。
PAN-OS: ホットフィックス適用までの回避策としてCLIから set system setting brotli-encoding disable を実行（またはWeb UIの Device > Setup > Content-ID から Allow Brotli Encoding のチェックを解除）してBrotliインスペクションを無効化する手順が案内されている。
参考資料・出典一覧
CVE.org - CVE-2026-111497
Google Brotli GitHub Repository - Commit 0ed4268a
Node.js - Wednesday, October 21, 2026 Security Releases
Imperva Blog - Node2Shell: From Brotli Data to Remote Code Execution (CVE-2026-111497)
JPCERT/CC - BrotliのC言語実装における境界外書き込みの脆弱性（CVE-2026-111497）に関する注意喚起 (JPCERT-AT-2026-0034)
Broccoli2Shell: Brotli decoder RCE (CVE-2026-111497) in Node.js, Python and more
GitHub Advisory Database - GHSA-9v8h-qqgm-4m35 (PyPI brotli / brotlicffi)
Bun Security Advisory - GHSA-663w-cv8g-jj2p
Microsoft .NET Security Advisory - CVE-2026-111497: Out of bounds write in Brotli leads to RCE
AWS Security Bulletin - 2026-155-AWS: CVE-2026-111497: Native Brotli Decoder Remote Code Execution and Memory Disclosure
CVE-2026-111497: CVE-2026-111497: Out-of-Bounds Heap Write and Remote Code Execution in Google Brotli Decoder (Node2Shell)
CVE-2026-111497: Out-of-Bounds Heap Write and Remote Code Execution in Google Brotli Decoder (Node2Shell)
> Vulnerability ID: CVE-2026-111497
> CVSS Score: 9.8
> Published: 2026-10-22
CVE-2026-111497, tracked in threat intelligence under the aliases Node2Shell, Broccoli2Shell, and HTTP2Shell, is a critical out-of-bounds heap write and denial-of-service vulnerability in the reference Google Brotli decompression library (c/dec/decode.c). The flaw originates from an unchecked return value and error-code conflation in DecodeBlockTypeAndLength() when processing malformed streams with single-block-type declarations (max_block_type <= 1). On the fast decoding path, the ignored error return causes the 32-bit unsigned block_length counter to underflow from 0 to UINT32_MAX (0xFFFFFFFF), corrupting internal decoder tables and enabling arbitrary heap memory overwrites via memmove16(). On the streaming path, the error return is misinterpreted as an incomplete bit-stream, trapping the worker process in an infinite 100% CPU loop. Because Google Brotli is embedded across major runtimes and infrastructure components—including Node.js, Envoy Proxy, Microsoft .NET, Istio, and Python—the vulnerability exposes a broad attack surface via standard HTTP Content-Encoding: br request and response bodies.
TL;DR
An unchecked return value in Google Brotli's DecodeBlockTypeAndLength() function leads to an integer underflow of block_length to 0xFFFFFFFF during fast-path decompression, enabling unauthenticated remote code execution via out-of-bounds heap writes or an infinite CPU loop during streaming decompression.
---
⚠️ Exploit Status: ACTIVE
Technical Details
- Vulnerability Class: CWE-252 (Unchecked Return Value) -> CWE-190 (Integer Underflow) -> CWE-787 (Out-of-Bounds Heap Write)
- Affected Component: Google Brotli Decoder (c/dec/decode.c: DecodeBlockTypeAndLength & ProcessCommandsInternal)
- Attack Vector: Network (Unauthenticated HTTP requests or responses with 'Content-Encoding: br')
- CVSS v3.1 / v4.0: 9.8 CRITICAL (v3.1) / 9.2 CRITICAL (v4.0)
- EPSS Score: 87.99% (99.76th Percentile)
- Security Impact: Remote Code Execution (fast path OOB heap write) or 100% CPU Infinite Loop DoS (safe streaming path)
- Exploit & KEV Status: Actively Exploited in the Wild; Listed in CISA KEV (Added 2026-10-27)
Affected Systems
- Google Brotli (libbrotli)
- Node.js Runtime (Express, Koa, NestJS, Next.js, undici, axios, node-fetch, got, superagent)
- Microsoft .NET Runtime & SDK
- Envoy Proxy
- Istio Service Mesh
- Bun Runtime
- Python brotli / brotlicffi
- Go andybalholm/brotli
- Apache Arrow, ClickHouse, DuckDB
- Tianocore EDK2, p7zip / 7-zip-zstd
- Debian 12, Ubuntu, Alpine Linux
- Brotli: >= 1.0.3, < 1.0.10 (Fixed in: 1.0.10)
- Brotli: >= 1.1.0, < 1.1.1 (Fixed in: 1.1.1)
- Brotli: >= 1.2.0, < 1.2.1 (Fixed in: 1.2.1)
- Node.js 22.x: < 22.23.4 (Fixed in: 22.23.4)
- Node.js 24.x: >= 23.0.0, < 24.22.1 (Fixed in: 24.22.1)
- Node.js 26.x: >= 25.0.0, < 26.12.1 (Fixed in: 26.12.1)
- .NET: < 8.0.33, < 9.0.22, < 10.0.14 (Fixed in: 8.0.33 / 9.0.22 / 10.0.14)
- Envoy Proxy: < 1.37.8, 1.38.0 - 1.38.5, 1.39.0 - 1.39.2 (Fixed in: 1.37.8 / 1.38.6 / 1.39.3)
- Istio: < 1.29.9, 1.30.0 - 1.30.5, 1.31.0 - 1.31.1 (Fixed in: 1.29.9 / 1.30.6 / 1.31.2)
- Bun: < 1.4.4 (Fixed in: 1.4.4)
- Next.js: < 16.4.3 (Fixed in: 16.4.3)
Code Analysis
Commit: 0ed4268
Detect and report invalid stream earlier.
diff --git a/c/dec/decode.c b/c/dec/decode.c
index e87e7f5ea..19c7e0283 100644
--- a/c/dec/decode.c
+++ b/c/dec/decode.c
@@ -1176,7 +1176,7 @@ static BrotliDecoderErrorCode DecodeContextMap(brotli_reg_t context_map_size,
/* Decodes a command or literal and updates block type ring-buffer.
Reads 3..54 bits. */
-static BROTLI_INLINE BROTLI_BOOL DecodeBlockTypeAndLength(
+static BROTLI_INLINE BrotliDecoderErrorCode DecodeBlockTypeAndLength(
int safe, BrotliDecoderState* s, int tree_type) {
brotli_reg_t max_block_type = s->num_block_types[tree_type];
const HuffmanCode* type_tree = &s->block_type_trees[
@@ -1187,7 +1187,7 @@ static BROTLI_INLINE BROTLI_BOOL DecodeBlockTypeAndLength(
brotli_reg_t* ringbuffer = &s->block_type_rb[tree_type * 2];
brotli_reg_t block_type;
if (max_block_type <= 1) {
- return BROTLI_FALSE;
+ return BROTLI_DECODER_ERROR_FORMAT_BLOCK_SWITCH;
}
Exploit Details
- GitHub: Proof-of-concept bitstream generator and RCE exploit harness for CVE-2026-111497 by Dimas Maulana.
- GitHub: Node2Shell proof-of-concept repository demonstrating CVE-2026-111497 exploitation against Node.js.
- GitHub: Technical analysis and crash reproduction repository by Qi Deng.
- GitHub: Assetnote vulnerability scanner for identifying endpoints vulnerable to Node2Shell (CVE-2026-111497).
Mitigation Strategies
- Upgrade Google Brotli and all downstream runtimes (Node.js, .NET, Envoy, Istio, Bun, Python) that statically link or bundle the C decoder.
- Block or strip incoming HTTP requests containing the 'Content-Encoding: br' header at the WAF, API gateway, or reverse proxy layer.
- Configure outbound HTTP clients (undici, axios, node-fetch, got) to omit 'br' from 'Accept-Encoding' headers when querying untrusted external servers.
- Audit container images and host filesystems for secondary or statically compiled Node.js, Envoy, and .NET binaries.
Remediation Steps:
1. Identify all vulnerable Node.js instances by running: node -p "require('zlib').constants.BROTLI_DECODER_ERROR_FORMAT_BLOCK_SWITCH || 'VULNERABLE'"
2. Upgrade Node.js runtimes to versions 22.23.4, 24.22.1, or 26.12.1 (migrate off EOL Node.js 20.x).
3. Upgrade Google Brotli system libraries (libbrotli1) to versions 1.0.10, 1.1.1, or 1.2.1 and restart dependent services.
4. Upgrade Microsoft .NET runtimes to 8.0.33, 9.0.22, or 10.0.14.
5. Upgrade Envoy Proxy (< 1.37.8, 1.38.0-1.38.5, 1.39.0-1.39.2) and Istio (< 1.29.9, 1.30.0-1.30.5, 1.31.0-1.31.1) to patched releases.
6. Deploy WAF rules to drop HTTP POST/PUT/PATCH requests with 'Content-Encoding: br' until all upstream workers are patched.
References
- National Vulnerability Database (NVD) Record: CVE-2026-111497
- CVE.org Authoritative Record: CVE-2026-111497
- CISA Known Exploited Vulnerabilities (KEV) Catalog
- Google Brotli Upstream Fix Commit (0ed4268a4401abcb4472096340477cf4af7d1a2b)
- Node.js Security Advisory (October 2026)
- GitHub Advisory Database (GHSA-9v8h-qqgm-4m35)
- Envoy Proxy Security Advisory (GHSA-3wvj-j6qm-62mr)
- Microsoft .NET Announcement Issue #494
- ELLIO Threat Research Analysis: Node2Shell RCE on Stock Node.js Builds
- Aikido Security Analysis: Node2Shell Node.js Brotli RCE
- Dimas Maulana (dimasma0305) CVE-2026-111497 PoC Repository
- Qi Deng (ikow) brotli2crash Analysis Repository
- Openwall oss-security Mailing List Disclosure
- RFC 7932: Brotli Compressed Data Format Specification
---
Read the full report for CVE-2026-111497 on our website for more details including interactive diagrams and full exploit analysis.
Node2ShellはNode.jsだけの話ではない。Brotliの欠陥でPythonも対象、CVE-2026-111497の該当判定
「Node2Shell? うちは Node.js を使っていないから関係ないな」。10月下旬にこのニュースを見て、そう判断しかけた方もいると思います。ところが、Node.js を使っていなくても確認が必要な場合があります。Node2Shell(HTTP2Shell とも呼ばれる、CVE-2026-111497)の正体は、Node.js ではなく Google の圧縮ライブラリ Brotli の欠陥でした。Python の Brotli パッケージ(入っていると requests などが自動で使う)、Bun、Envoy、Git for Windows にも同じ欠陥がありました。10月27日には、米国の CISA(サイバーセキュリティ・社会基盤安全保障庁)が、実際に悪用が確認された脆弱性の一覧に追加しています。
この記事は、Node.js・Python・Bun でアプリを作っている人や、Windows で Git for Windows を使っている人向けです。読み終えると、次の3つが分かります。
なぜ「Node.js の脆弱性」として広まったのか(原因)
自分の環境が該当するか、どこまで上げればよいか(言語・ツール別の判定)
呼び名・深刻度・RCE の範囲など、記事ごとに食い違う情報のどれを信じればよいか
情報は2026年10月29日時点のものです。技術的な解析は Imperva と OpenSourceMalware の記事が詳しく、Python・curl・Git for Windows の動作検証は技術ブログの lilting が詳しいです。どれも末尾のリンクから読めます。
!
先に答え(2026年10月29日時点)
出回った言い方
一次情報での答え
Node.js の脆弱性
欠陥があるのは Google の Brotli。Node.js は同梱していた Brotli を直した側
Node.js を使っていなければ無関係
Python(Brotli パッケージがあると requests 等が使う)・Bun・Envoy・Git for Windows も対象
Node2Shell と HTTP2Shell は別の脆弱性
どちらも CVE-2026-111497 の1件
深刻度は High? Critical?
どちらも正しい。評価した組織が違う
素の Node.js ならどこでも RCE される
実証は Node.js 24.22.0(arm64 と x86-64)で報告された。24.22.0 用の攻撃データは 22.23.3・26.12.0 では通らず、ビルドごとに調整が要る
実際の攻撃はまだ?
CISA が10月27日に、悪用が確認された脆弱性の一覧(KEV)に追加した。攻撃通信を観測したという報告もある
自分は該当する? 使っている言語ではなく、「信頼できない相手から来た Brotli データを展開するか」と「同梱している Brotli が直った版か」で決まります。判定だけ知りたい方は「自分は関係ある? 言語・ツール別の判定」へ進んでください。
Brotli とは何で、何が壊れていたのか
Brotli は Google が作った圧縮形式で、Web では HTTP の Content-Encoding: br として使われます。欠陥があったのは、圧縮データを元に戻す部分(デコーダ)の C 言語実装です。壊れた圧縮データを渡すと、デコーダが内部バッファの外へ書き込んでしまいます(境界外書き込み)。本来触ってはいけないメモリを書き換えるため、条件がそろうと遠隔からのコード実行(RCE)につながります。
影響を受ける版: 1.0 系は 1.0.3〜1.0.9、1.1 系は 1.1.0、1.2 系は 1.2.0
修正版: 1.0.10 / 1.1.1 / 1.2.1(日本時間の10月22日 04:27 公開)
CVE の採番: Google
発見: OpenAI Codex Security
なぜ「Node.js の脆弱性」として広まったのか
広く知られるきっかけが、10月21日の Node.js 定例セキュリティリリースだったからです。流れを表にまとめます(日付は日本時間)。
日付
出来事
2月27日
Brotli のリポジトリに修正コミット。メッセージは「Detect and report invalid stream earlier.」(壊れたストリームを早めに検出して報告する)の1行で、脆弱性とは書かれていない。修正版の公開まで約237日
10月21日
Node.js が定例セキュリティリリースで10件を修正。その1件がこの欠陥
10月22日
Brotli の修正版を公開。Imperva が「Node2Shell」の題で RCE の実証記事を公開
10月23日
OpenSourceMalware が Python への波及を公表
10月24日
Envoy がアドバイザリを公開。Git for Windows に Issue #6514 が立つ
Imperva はセキュリティ企業です。実証の対象が Node.js で、記事の題にも Node.js が入りました。そのため、「Node.js の脆弱性」として広まりました。
ところが、Node.js が直した中身は Brotli のコードです。Node.js は Brotli を自分のリポジトリに同梱していて、今回は Brotli の修正コミットを cherry-pick で取り込みました。cherry-pick は、別のリポジトリの修正部分だけを持ってくる操作です。
つまり Node.js は、同梱していた Brotli を直した側であって、欠陥の持ち主ではありません。
Python への波及を最初にまとめた OpenSourceMalware(OSM)も、この点を「この脆弱性は、そもそも Node.js のものではない」と書いています。
OSM の原文(英語)
The vulnerability isn't really in Node.js at all
Node.js 以外に対象になるもの(Python・Bun・Envoy・Git for Windows)
原因が Brotli のデコーダにあるので、同じデコーダを積んでいるものは確認が必要です。10月29日までに、次のものが分かっています。
Python: Brotli / brotlicffi パッケージ。どちらかが入っていると、urllib3 / requests、httpx(brotli extra)、aiohttp、Scrapy が br の応答を自動で展開します
Bun: 1.4.4 で同梱の Brotli を更新しました
Envoy / Istio: Brotli の展開(decompressor)を設定した構成が対象です
curl: リンクしている Brotli のライブラリ次第です
Git for Windows: 2.56.0.windows.3 までは、同梱の brotli が 1.2.0 のままでした。10月26日に公開された 2.56.0.windows.4 で 1.2.1 に更新されています
このほかにも、対象として次のものが見つかっています。
.NET: 修正版は 8.0.33 / 9.0.22 / 10.0.14 です(.NET Framework は対象外)。BrotliStream などで自分で展開する処理が対象です。HttpClient の応答の自動展開と ASP.NET Core のリクエスト展開は、既定では無効です
Go の andybalholm/brotli: Brotli を Go に移植したライブラリです。v1.2.7 に同じ修正が移植されました
Linux の git の HTTPS 通信: git が使う libcurl が Brotli 付きでビルドされていれば対象です。oss-security への投稿によれば、多くのディストリの libcurl は Brotli 付きです
Git for Windows のメンテナは、10月24日の Issue で次のように書いています。
昨日の時点では、これは「ただの」node2shell だと言われていた。だから Git for Windows は無関係に見えた。
メンテナの原文(英語、Git for Windows Issue #6514)
Yesterday, the word on the street was still that this was "only" node2shell, and therefore Git for Windows looked unaffected.
メンテナ自身も、名前を見て「自分は関係ない」と判断しかけていたわけです。「Node2Shell」という名前は、最初に話題になった場所を示しているだけで、影響範囲を示してはいません。
該当するかは「言語」ではなく2つの条件で決まる
対象の部品が入っていても、すぐに攻撃されるとは限りません。どの環境から先に上げるかは、次の2つの条件で決まります。
条件1: 信頼できない相手から来た Brotli データを展開するか。 典型的な経路は2つあります。
外部サーバーの応答を、Node.js の fetch() や Python の requests などで受け取る。応答の中身は相手のサーバーが決めます。攻撃者が用意したサーバーなら、壊れたデータを返せます
受け取ったリクエスト本文を、ミドルウェアが展開する。Imperva は、Express 5 / body-parser 2 の raw()・json() がリクエスト本文を展開する経路で実証しています
一方、素の Node.js の HTTP サーバーは、リクエストを受け取っただけでは本文を展開しません(Imperva の記事による)。
条件2: 同梱している Brotli が直った版か。 これは言語やツール本体の版で決まります。Brotli を自分で入れていなくても、ランタイムやツールの中に入っていることがあります。
特に先に上げるべきなのは、外部の URL を取ってくる機能を持つアプリです。Webhook、URL のプレビュー表示、クローラ、「この URL の内容を取ってきて」と頼める機能などがこれに当たります。
下の図の「Brotli デコーダを積んだもの」は、前の節で挙げた Node.js・Python の Brotli / brotlicffi・Bun・Envoy・Git for Windows などです。
自分は関係ある? 言語・ツール別の判定
!
判定の前に、落とし穴が2つあります。
版番号: Node.js は修正を cherry-pick で取り込みました。そのため、修正版でも process.versions.brotli の表示は修正前と変わりません(lilting の検証では、22.23.4 でも 1.1.0 のまま)。Node.js では、Brotli の版ではなく node -v で Node.js 本体の版を見ます。ただし、ディストリが提供する nodejs はシステムの libbrotli を使うことがあります(Ubuntu・Debian の告知)。その場合は、ディストリの告知で判断します
スキャナ: Node.js はランタイムそのものなので、npm audit には出ません。Python では、10月23日に OSM が「Brotli・brotlicffi の PyPI パッケージは、どの脆弱性データベースにも載っていない」と書きました。翌24日には、pip-audit が検出するようになっています(lilting の検証)。スキャナが何も言わないことを、安全の根拠にしないでください
対象
何を見るか
OK の基準・対処
優先して上げるべき使い方
Node.js
node -v
22・24・26 系は、それぞれ 22.23.4 / 24.22.1 / 26.12.1 以上。それ以外の系列(20 以下など)は修正されないので、サポート中の系列へ移る
fetch() で外部 URL を取る。Express 5 / body-parser 2 で br の本文を受ける
Python
Brotli / brotlicffi が入っているか
Brotli 1.2.1 / brotlicffi 1.2.1.0 以上。Linux ディストリビューション(以下ディストリ)が提供するパッケージは、ディストリの更新で上げる
requests・httpx・aiohttp 等で外部 URL を取る
Bun
bun --version
1.4.4 以上。コンパイル済みの実行ファイルは作り直しが必要(Aikido の記述)
外部 URL を取る
Envoy
Brotli decompressor を設定しているか
1.40.0 / 1.39.3 / 1.38.6 / 1.37.8 / 1.36.12 以上
設定している構成すべて
Istio
Brotli の展開を有効にしているか(EnvoyFilter など)
1.31.2 / 1.30.6 / 1.29.9 以上(Istio の告知 ISTIO-SECURITY-2026-007)
有効にしている構成すべて
Git for Windows
git version
2.56.0.windows.4 以上(10月26日公開。同梱の brotli は 1.2.1)
信頼できない HTTPS サーバーへの clone / fetch
curl
どの Brotli にリンクしているかは、ビルドした配布元次第
配布元(OS・ディストリ・同梱しているツール)の更新情報を確認して上げる。Windows 標準の curl は Brotli 非対応(lilting の検証)
--compressed などで、信頼できない URL の応答を展開させる
Linux の libbrotli
ディストリのセキュリティ情報
ディストリの更新を当てる。版番号を変えずに修正だけ移植する(バックポート)ことがあるので、版番号ではなくディストリの告知で判断する
libbrotli を使うアプリが外部データを展開する
Bun 1.4.4 のリリースノート(公式ブログ)は、Security の節で Brotli に触れていますが、CVE 番号は書かれていません。CVE 番号で探すと見落としやすいので注意してください。
主なディストリの対応状況は、10月29日時点で次のとおりです。
Ubuntu: brotli は jammy(22.04)・noble(24.04)などで修正済みです(USN-8956-1 / USN-8956-2)。jammy 以降の nodejs はシステムの brotli を使うため「影響なし」とされています。focal(20.04)は、brotli が「評価中(Needs evaluation)」、Brotli を同梱する nodejs が「vulnerable」のままです
Debian: brotli は bookworm(DLA-4855-1)と trixie(DSA-6582-1)で修正済みです。ディストリ版の nodejs と trixie の python-brotlicffi は、トラッカー上はまだ「vulnerable」の表示です。ただし、トラッカーの注記では、どちらもシステムの brotli を使うとされています
同じディストリの中でも、パッケージごとに状況が違います。使っているパッケージごとに告知を確かめてください。
Node.js・Python・Git for Windows については、表に書ききれない確かめ方を補足します。
Node.js: node -v で本体の版を見る
node -v
Docker イメージの中の Node.js を見る例(<image> は自分のイメージ名に置き換える)
docker run --rm <image> node -v
出力を表の基準と比べます。手元の Node.js だけでなく、Docker イメージや、Node.js を同梱して配っているバイナリの中の版も見てください(Imperva の推奨)。
Python: Brotli / brotlicffi が入っているかを見る
確かめたい venv を有効にしてから実行する
python -m pip show Brotli brotlicffi
出力の Version: の行を、表の基準と比べます。
どちらも見つからなければ、requests などは br の応答を展開しません(OSM の解説と lilting の検証)。ただし、Brotli を別の形で同梱したライブラリや外部ツールを使っている場合は、そちらも確かめてください。また、venv ごとに入っているパッケージは違います。アプリごと・コンテナごとに見てください。
Git for Windows: git version で版を見る
git version
git version 2.56.0.windows.4 以上と表示されれば、修正版です。10月26日に公開され、Issue #6514 もクローズされました。
同梱の brotli の版は、Git for Windows のインストール先にある etc/package-versions.txt で確かめられます。Git Bash からは次のように見られます。
grep brotli /etc/package-versions.txt
64ビット版の修正版なら mingw-w64-ucrt-x86_64-brotli 1.2.1-1 と出る
上げられるまでの間は、信頼できない HTTPS サーバーへの clone / fetch を避けるのが安全です(lilting の見解)。
呼び名・深刻度・RCE の範囲・悪用、食い違いの答え合わせ
ここまでで判定はできます。この節では、調べると記事ごとに食い違って見える4つの点を、一次情報で確かめます。
Node2Shell と HTTP2Shell は同じ1件
Node2Shell は Imperva の記事タイトルが元です。HTTP2Shell は、セキュリティ企業 Aikido の記事の見出し「Node2Shell evolves to HTTP2Shell」(Node2Shell が HTTP2Shell に進化した)に出てくる呼び方です。見出しは、HTTP を使うライブラリやアプリにも影響が広がったことを伝えるものです。ただし、Aikido は呼び名を変えた理由を本文で説明していません。検索すると Broccoli2Shell という呼び方も出てきます。どれも指しているのは CVE-2026-111497 の1件です。
もう1つ紛らわしいのが、2024年の別の脆弱性です。「Node.js Brotli 脆弱性」で検索すると、検索エンジンの AI 要約が CVE-2024-22025 を返すことがあります。これは2024年に見つかった、fetch() が Brotli データを展開するときにサービス停止(DoS)を起こす問題で、今回とは別件です。
High と Critical 9.2 は、評価した組織が違う
深刻度の点数は CVSS という共通の尺度で付けます。CVE を採番した Google は、CVSS 4.0 で 9.2(Critical)と評価しました。GitHub のアドバイザリと NVD(米国の脆弱性データベース)もこの値を載せています。
一方、Node.js は自分のリリース表でこの件を High と書きました。評価したのは Node.js 自身で、対象も Node.js という1つの製品です。評価した組織も、評価の対象にした製品も違うので、どちらも間違いではありません。
RCE の実証は広がったが、成否はビルドで違う
「素の Node.js で RCE できる」という言い方も出回っています。最初に Imperva が実証に使ったのは、公式の Node.js 24.22.0 Linux arm64 イメージです(経路は fetch() と Express 5 / body-parser 2)。成功までには何回か試す必要がありました。
その後、セキュリティ企業の ELLIO が、Node.js 24.22.0 の x86-64 でも RCE に成功したと報告しました。成功した構成は4つで、node:http のサーバーから node:zlib を呼んで本文を展開するもの、公式の slim イメージ、Express 5.3.0(express.json())、Koa 3(@koa/bodyparser)です。node:http の例は、フレームワークを挟まず、アプリのコードが自分で本文を展開する構成です。ELLIO も、素の Node.js の HTTP サーバーはリクエストを受け取っただけでは Brotli の本文を展開しないと書いています(条件1 と同じ)。「node:http を使っているだけで RCE される」という意味ではありません。
一方、24.22.0 用に調整した攻撃データは、22.23.3 と 26.12.0 では1万回試しても成功しませんでした。ELLIO は、これらの版には別の調整が要るとしています。攻撃を成功させるには、ビルドごとに作り込む必要があるということです。「どの環境でもすぐ RCE される」わけではありません。
Python については、RCE を試した報告はまだありません。OSM は、壊れたデータを渡すとデコーダが誤った結果を返すところまでを確かめています。
ただし、24.22.0 用の攻撃データが通らなかったからといって、ほかの版が安全だという証明にはなりません。判定で該当した環境は、実証の有無にかかわらず上げてください。
実際の攻撃は、すでに確認されている
10月25日の時点では、悪用の報告は見当たりませんでした。その後、状況が変わっています。CISA は10月27日に、この CVE を KEV(Known Exploited Vulnerabilities、実際に悪用が確認された脆弱性の一覧)に追加しました。米国の政府機関には、11月10日までの対応が求められています。
ELLIO も10月26日の追記で、自社のセンサーで実際の攻撃通信を観測したと報告しています。狙いは Node.js 24.22.0 の x86-64 で、ELLIO の検証では、観測した攻撃データそのものは成功しませんでした。攻撃を再現するコード(PoC)も公開されて出回っています。
ただし、CISA は KEV に追加した根拠となった具体的な事例を公表していません。どの製品のどの使い方が狙われたのかは、まだ分かりません。
まだ分かっていないこと
10月29日時点で、次の点はまだ決着していません。
Ubuntu の focal(20.04)は、修正版が出ていません。Debian のディストリ版 nodejs と trixie の python-brotlicffi は、トラッカー上「vulnerable」の表示が残っています
Python で RCE が可能かどうかを検証した報告は、見当たりません
CISA が KEV に追加した根拠の事例は公表されておらず、どこが狙われたのかは分かっていません
ブラウザや、Node.js を内蔵するアプリ(Electron など)については、この記事では扱いません。影響の有無を示す一次情報が見当たらないためです。
おわりに
Node2Shell の原因は Node.js ではなく Brotli の欠陥で、Node.js は直した側でした。呼び名が違っても指しているのは1件で、深刻度の違いは評価した組織の違いです。RCE の成否はビルドによって違いますが、実際の攻撃はすでに確認されています。
「Node.js は使っていないから関係ない」と思った方も、Python の venv と git version を一度確かめてみてください。判断の材料は「Node2Shell」という名前ではなく、手元にあるパッケージとツールの版です。
参考リンク
Node.js: Security Releases: October 21, 2026
GitHub Advisory: GHSA-9v8h-qqgm-4m35(PyPI Brotli / brotlicffi)
NVD: CVE-2026-111497
google/brotli: Releases
Git for Windows Issue #6514: Bundled brotli is still 1.2.0 in 2.56.0.windows.3
Imperva: Node2Shell: From Brotli Data to Remote Code Execution
OpenSourceMalware: Node2Shell affects Python
Envoy: GHSA-3wvj-j6qm-62mr
Istio: ISTIO-SECURITY-2026-007
Bun: Bun v1.4.4
Aikido: Node2Shell evolves to HTTP2Shell
lilting: Brotli CVE-2026-111497 beyond Node.js, tested with Python, curl, and Git for Windows
CISA: Known Exploited Vulnerabilities Catalog(CVE-2026-111497)
ELLIO: Node2Shell(CVE-2026-111497)の検証記事
Git for Windows: v2.56.0.windows.4
Ubuntu: CVE-2026-111497
Debian Security Tracker: CVE-2026-111497
.NET: dotnet/announcements #494
oss-security: Brotli CVE-2026-111497 and git-remote-https
andybalholm/brotli: v1.2.7 の更新履歴
Microsoft Releases Emergency .NET Patches for Critical Node2Shell Vulnerability
Microsoft has released emergency security updates for .NET to address Node2Shell (CVE-2026-111497), a memory corruption vulnerability in Google's Brotli decompression library.
The flaw allows an unauthenticated attacker to send specially crafted Brotli-compressed data that can trigger an out-of-bounds memory write, potentially leading to information disclosure, denial of service, privilege escalation, or arbitrary code execution.
The vulnerability affects .NET applications that process attacker-controlled Brotli data. ASP.NET Core and HttpClient are not vulnerable by default, as Brotli decompression must be explicitly enabled. Applications directly using Brotli decompression APIs may also be exposed.
Microsoft issued out-of-band updates on October 25, 2026, covering the following versions:
.NET 8 → 8.0.33
.NET 9 → 9.0.22
.NET 10 → 10.0.14
.NET 11 → RC3
Self-contained applications, NativeAOT deployments, and affected container images must be rebuilt and redeployed using patched components. Updating the shared runtime alone is insufficient for applications that bundle their own vulnerable runtime.
Microsoft rates the vulnerability High (CVSS 8.1), while Google assigns the underlying Brotli flaw a Critical CVSS 4.0 score of 9.2.
CISA has also added the vulnerability to its Known Exploited Vulnerabilities catalog following reports of exploitation in the wild.
Source: announcements#496
2 points
CVE-2026-111497: a Brotli decoder bug forced an out-of-band .NET release (10.0.14) on Oct 25
Microsoft released .NET 10.0.14 on 25 October as an out-of-band security update, and the stated reason is CVE-2026-111497, an out-of-bounds write (CWE-787) in the Brotli decoder bundled with .NET. CVSS 8.1, publicly disclosed, exploitation marked more likely.
Affected and fixed:
- .NET 8 before 8.0.33 → 8.0.33
- .NET 9 before 9.0.22 → 9.0.22
- .NET 10 before 10.0.14 → 10.0.14 (SDK 10.0.114 or 10.0.403)
- .NET Framework is not affected
The same release completes the October 13 fixes for CVE-2026-70197 (SocketAsyncEventArgs) and CVE-2026-102870 (Blazor WebAssembly debugger), which had shipped incomplete, and adds CVE-2026-114148 for Linux source-build tarballs.
Exposure needs a call path that decompresses attacker-controlled Brotli: request decompression with br enabled, HttpClient AutomaticDecompression including Brotli, or BrotliStream/BrotliDecoder on untrusted input. None of that is on by default, and response compression alone does not hit it. Until you update, dropping Brotli from those paths is a workable stopgap.
Framework-dependent apps need the host runtime updated and restarted. Self-contained apps need a rebuild and republish, and the Blazor WebAssembly Server/DevServer packages have to be bumped separately because the shared runtime update does not cover them.
Advisory: announcements#494
Release notes: github.com/dotnet/core/blob/main/release-notes/10…
51 points · 11 comments
Pretty stoked to have noticed this a full two days before they announced it publicly, but also disappointed it took them that long...
announcements#494
1 like
Patched the Blazor WASM debugger RCE (CVE-2026-102870) on Oct 13? Microsoft's Oct 25 OOB release corrected the fixed package versions.
A runtime update alone won't cover it: bump WebAssembly.Server and DevServer to 10.0.14, then restart the debugger.
announcements#492
1 like · 92 views
Her kernel açığının arkasında art niyetli planlar vardır. Mehmet Keçeci
PHP kernel açığından sonra şimdi de .NET açığı:
"Her kernel açığının arkasında art niyetli planlar vardır. Mehmet Keçeci"
Çünkü çekirdek (kernel) seviyesindeki zafiyetler, bir sistemdeki tüm mantıksal sınırları, antivirüs yazılımlarını ve kullanıcı yalıtımlarını tamamen bypass etmek için tasarlanan "nihai silahlar" gibidir. APT (Gelişmiş Sürekli Tehdit) aktörleri ve devlet destekli hacker grupları, hedef sistemde kalıcılık sağlamak için her zaman bu tarz yetki yükseltme açıklarını ceplerinde hazır tutarlar.
PHP ve Çekirdek (Kernel) Açıklarının Anatomisi
PHP tabanlı bir zafiyet (örneğin kritik bir RCE - Uzaktan Kod Çalıştırma açığı) web sunucusuna dışarıdan sızmayı sağlar. Ancak saldırgan içeri girdiğinde genellikle kısıtlı yetkilere sahip www-data veya nobody kullanıcısıdır.
İşte bu noktada Kernel açığı devreye girer:
• Amaç: Saldırgan işletim sisteminin kalbine (ring 0) inmek zorundadır. Kernel zafiyetleri donanım, bellek yönetimi veya sürücülerdeki hataları sömürerek saldırganı bir anda "En Yetkili Modu"na (Root/SYSTEM) yükseltir.
• Arka Plan: Kernel açıkları çok nadir bulunur, tespiti zordur ve arkasında siber casusluk, sisteme kalıcı arka kapılar (rootkit) yerleştirme gibi çok ciddi, organize art niyetli planlar barındırır.
Sızılan sistemde iz bırakmadan her şeyi silme yetkisini bu açıklar verir.
.NET Açığının (CVE-2026-114148) Bu Denklemdeki Yeri
.NET açığı doğrudan bir Linux Kernel açığı değildir, ancak doğurduğu sonuç siber güvenlik stratejisi açısından tam olarak bir Kernel açığı gibi tehlikelidir.
• Mantıksal Kernel Etkisi: Bu açık, Linux Kernel'ın zayıflığından değil, .NET dosyalarının Linux üzerindeki hatalı izinlerinden (CWE-276) kaynaklanır.
Ancak saldırgana sağladığı avantaj birebir aynıdır: Düşük yetkili bir siber saldırgan, bu açığı kullanarak Linux'ta Root (yani en yetkili) seviyesine tırmanır.
• Art Niyetli Planlar Açısından: Bu .NET açığı, Linux sunucularına doğrudan "dışarıdan" sızma imkanı vermez.
Tıpkı bir Kernel açığı gibi, "Post-Exploitation" (Sızma Sonrası) aşaması için saklanan bir silahtır.
Saldırgan PHP veya başka bir yolla web sunucunuza sızdıktan sonra, sistemin tamamen kontrolünü ele geçirmek için bu .NET açığını kullanacaktır.
İki Tür Açığın Doğrudan Karşılaştırması
Kriter Tipik PHP / Web Açıkları .NET / Kernel Yetki Yükseltme Açıkları
İlk Giriş Noktası Çok Yüksek. Dışarıdan tarayıcı ile tetiklenebilir. Düşük. Saldırganın zaten içeride bir ayağı olmalıdır.
Sistem Üzerindeki Etkisi Sınırlı. Genelde sadece ilgili uygulamanın verilerine erişir. Tam Kontrol. Tüm işletim sistemini ele geçirir, logları siler.
"Her kernel açığının arkasında art niyetli planlar vardır. Mehmet Keçeci" Uyuşma Derecesi Genelde otomatize botlar ve fidye yazılımları tarafından ilk kapıyı aralamak için kullanılır. Tam Uyuşur. Hedefe yönelik, organize ve sistemde kalıcı olmayı amaçlayan art niyetli planların anahtarıdır.
Özet Değerlendirme
"Her kernel açığının arkasında art niyetli planlar vardır. Mehmet Keçeci" çerçevesinde baktığımızda; CVE-2026-114148 (.NET) açığı, en az bir Kernel açığı kadar ciddiye alınmalıdır.
Çünkü siber saldırganlar kurumsal bir ağa sızarken tek bir açıkla yetinmezler; zincirleme bir reaksiyon (Exploit Chain) kurarlar.
PHP açığı ile kapıdan girerler, bu tarz bir .NET veya Kernel açığı ile de evin tapusunu (Root yetkisini) üzerlerine alırlar.
Dolayısıyla, "içeride zaten korumalıyız" yanılgısına düşmeden, bu izin hatasının Linux sunucularda hızla kapatılması kritik önem taşır.
windowsforum.com
announcements#495
1 point
What I'm doing until then:
✂️ Remove Brotli from AutomaticDecompression and keep GZip. It's a one-line change.
🛡️ Block Content-Encoding: br at the proxy or WAF.
👀 Watch dotnet/announcements
The cost is slightly bigger payloads, which I'll take.
28 views
ASP .NET Coreも更新しましょうネ
announcements#472
32 views
Mentions
【CVE-2026-111497】Brotliの脆弱性（Broccoli2Shell） 概要 Googleが開発するデータ圧縮ライブラリ「Brotli」において、細工された圧縮ストリームを展開（デコード）する際に境界外書き込みが発生する脆弱性が公表された。未認証の遠隔の攻撃者から悪意あるBrotli圧縮ストリームを処理させられることで、隣接するデコーダー状態メモリの破壊、機密メモリ内容の漏洩、サービス拒否（DoS）、または任意のコード実行（RCE）に至る可能性がある1。 項目 内容 CVE ID CVE-2026-111497 対象ソフトウェア Google Brotli（C言語デコーダー実装 c/dec/decode.c） CVSSスコア ・9.2 Critical (CVSS:4.0/AV:N/AC:L/AT:P/PR:N/UI:N/VC:H/VI:H/VA:H/SC:N/SI:N/SA:N — Google CNA / GitHub) ・9.8 Critical (CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H — NVD) ・8.1 High / Important (CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:H/I:H/A:H — Microsoft / Red Hat / AWS) 脆弱性種別 CWE-252: 戻り値の未チェック（Unchecked Return Value）、CWE-787: 境界外書き込み（Out-of-bounds Write） 発見・報告者 Khai Tran 氏、Sylvie Mayer 氏（OpenAI Codex Security） 悪用・KEV登録状況 Imperva社がNode.js 24.22.0（Linux arm64公式イメージ）環境でのRCE実証を報告。2026年10月27日付で米国CISA KEVに追加（対策期限: 2026年11月10日） 本脆弱性は、発見から波及範囲の判明に至る経緯の中で以下の3つの通称で呼ばれている。 Node2Shell: 2026年10月21日のNode.jsセキュリティリリース公表後、Imperva Red TeamがNode.js組み込みBrotliデコーダーにおける解析およびRCE実証に命名した呼称である4。 HTTP2Shell: 当初はNode.jsに関連して「Node2Shell」と呼称されていたが、根本原因がHTTP通信（Content-Encoding: br）等で広く利用されるBrotliのC言語実装にあり、複数製品が影響を受けることから「HTTP2Shell」とも呼称されている（HTTP/2プロトコル自体の脆弱性ではない）5。 Broccoli / Broccoli2Shell: セキュリティ研究者のJuliano Rizzo氏が「Node2Shellという名称は影響範囲を狭く見せてしまう」として「Broccoli」と呼ぶことを提唱したことに端を発し、追跡サイト「broccoli2shell.com」等で用いられている呼称である6。 影響を受けるバージョンと修正バージョン 1. Brotli の影響範囲と修正状況 Brotliの公式C実装において、バージョン 1.0.3 から 1.2.0 までのデコーダーが影響を受ける。各系統の修正バージョンは以下の通りである1。 系統 / ブランチ 影響を受けるバージョン 修正版 補足 1.0 系 >= 1.0.3, < 1.0.10 1.0.10 コミット 50a9b70a（0ed4268a のバックポート） 1.1 系 >= 1.1.0, < 1.1.1 1.1.1 コミット da980636（0ed4268a のバックポート） 1.2 系 >= 1.2.0, < 1.2.1 1.2.1 コミット b418fa81 / 0ed4268a 2. 主要ランタイム・言語パッケージ・アプライアンスの対応状況 BrotliのC言語デコーダーをバンドルまたはバインディングとして組み込んでいる各ランタイム・パッケージおよびネットワーク製品の対応状況は以下の通りである。 ランタイム / 製品 影響を受けるバージョン 修正版 補足 Node.js (v24 LTS) 24.x（< 24.22.1） v24.22.1 / v24.22.2 3 v24.22.1 で修正（v24.22.2 はリグレッション修正版） Node.js (v22 LTS) 22.x（< 22.23.4） v22.23.4 組み込みBrotliの更新（2026年10月セキュリティリリース） Node.js (v26 Current) 26.x（< 26.12.1） v26.12.1 組み込みBrotliの更新（EOL系統の <= 20.x, 23.x, 25.x も影響対象） Bun >= 1.0.21, < 1.4.4 1.4.4 8 バンドルするBrotliを 1.2.0 から 1.2.1 へ更新（GHSA-663w-cv8g-jj2p） Python (brotli / PyPI) >= 1.0.3, < 1.2.1 1.2.1 7 PyPI上の公式C拡張パッケージ（GHSA-9v8h-qqgm-4m35） Python (brotlicffi / PyPI) >= 1.0.3, < 1.2.1.0 1.2.1.0 Brotli C実装のCFFIバインディング（GHSA-9v8h-qqgm-4m35） .NET 8 / 9 / 10 8.0.0〜8.0.32 9.0.0〜9.0.21 10.0.0〜10.0.13 Runtime 8.0.33 Runtime 9.0.22 Runtime 10.0.14 9 SDKは 8.0.133/8.0.427、9.0.123/9.0.320、10.0.114/10.0.403 で修正 Palo Alto Networks PAN-OS PAN-OS 12.2 / 12.1 / 11.2 の未修正版 12.2.4-h1 12.1.7-h11 等 6 データプレーンでTLS復号とBrotli検査を有効化している場合のみ影響（デフォルト無効） 3. 主要Linuxディストリビューションの対応状況 OSの共有ライブラリ（libbrotli）およびディストリビューション提供パッケージにおける対応状況は以下の通りである。ディストリビューションによってはNode.jsや.NETパッケージがOS標準の共有ライブラリ（libbrotli）を動的リンクしているため、影響有無がパッケージ単位で異なる点に注意が必要である。 ディストリビューション 対象パッケージ 修正版 補足 Amazon Linux 2023 brotli, libbrotli, python3-brotli nodejs24, dotnet8.0 1.1.0-1.amzn2023.0.2 アドバイザリ: ALAS2023-2026-3334（brotli）、ALAS2023-2026-3330（nodejs24）、ALAS2023-2026-3367（dotnet8.0）。nodejs22・dotnet9.0・dotnet10.0 は影響なし Ubuntu brotli, libbrotli1, python3-brotli dotnet8, dotnet10, dotnet11 24.04 LTS: 1.1.0-2ubuntu0.1 22.04 LTS: 1.0.9-2ubuntu0.1 アドバイザリ: USN-8956-1（Brotli）、USN-8958-1（.NET 8.0.33 / 10.0.14） Debian brotli, libbrotli1 Trixie (13): 1.1.0-2+deb13u1 Bookworm (12): 1.0.9-2+deb12u1 DSA-6582-1 / DLA-4855-1。Debianの nodejs と python-brotlicffi はシステムの brotli を利用 RHEL (Red Hat) brotli, nodejs:24, dotnet8.0, firefox, thunderbird 提供済（各RHSA） RHSB-2026-015（Important）。RHEL 8/9の nodejs:22、RHEL 10の nodejs22/nodejs24、および dotnet9.0/10.0/11.0 はシステムの brotli を利用 4. AWS マネージドサービスの対応状況 AWSの 2026-155-AWS で公表されている主要マネージドサービスの対応状況は以下の通りである10。 対象サービス / リソース 修正版 補足 AWS Lambda（Node.js 22/24/26、.NET 8/9/10） 更新済 マネージドランタイム・ベースイメージ更新済。コンテナイメージ利用時は最新ベースイメージでの再ビルドが必要（Python/Ruby/provided.al2023 はBrotli非同梱） AWS Elastic Beanstalk (Node.js) 6.11.12 Node.js 24.22.1 および 22.23.4 を含むプラットフォームバージョン 6.11.12 を提供済 AWS App Runner / Amplify / CodeBuild / Synthetics 更新済 App Runnerは2026年10月26日に全リージョン更新済（未デプロイのサービスは1回再デプロイが必要） 影響を受ける条件 本脆弱性は、ライブラリがシステム上に存在するだけでは発火せず、「信頼できないBrotli圧縮ストリームを、対象アプリケーションやプロキシがデコード（展開）する」 処理が行われた際に成立する6。 1. 前提となるシステム・ネットワーク構成 攻撃が成立する代表的な経路は以下の4パターンである。 パターン1：クライアントからの圧縮HTTPリクエストボディを展開するサーバー / API クライアントから送信された Content-Encoding: br ヘッダー付きのリクエストボディを、ミドルウェア（Node.jsのExpress 5.0.0〜5.3.0やbody-parser 2.0.0〜2.3.0における raw() / json() 等）やバックエンドアプリケーションが自動または明示的にBrotli展開している構成（なお、素の node:http サーバー自体は単体ではリクエストボディを自動展開しない）。 パターン2：外部サーバーからの圧縮HTTPレスポンスを展開するHTTPクライアント / クローラー 接続先サーバーから返却された Content-Encoding: br レスポンスを自動展開する構成（Node.jsやBunの組み込み fetch()、Brotliパッケージがインストールされた環境でのPython urllib3 / requests / aiohttp / httpx[brotli] 等）。 多くのHTTPクライアントはリクエスト時に Accept-Encoding: br を送信したかどうかにかかわらず、レスポンスヘッダーに Content-Encoding: br が含まれていれば自動的にBrotliデコーダーを呼び出す。そのため、任意のURLを取得するWebhook、リンクプレビュー、クローラー、または非暗号化通信経路上の中間者攻撃において、悪意あるサーバーから一方的に Content-Encoding: br のレスポンスを返されるだけでトリガーされ得る。 パターン3：ファイアウォール等のデータプレーンにおけるトラフィック検査 Palo Alto NetworksのPAN-OS（PA-Series / VM-Series）において、データプレーン上でTLS/SSL復号（Decryption）とBrotliインスペクションの両方が有効化されている場合、通過するBrotliトラフィックをファイアウォール自身が展開するため影響を受ける。 パターン4：デコーダーAPIの直接呼び出し・ファイル処理 アーカイブ、キャッシュ、メッセージキュー等の外部データを、node:zlib（brotliDecompress*、createBrotliDecompress）、Web標準の DecompressionStream、Pythonの brotli.decompress()、.NETの BrotliStream / BrotliDecoder 等で直接展開している場合。 ! 影響を受けないケース: 圧縮（エンコード）のみ・静的 .br ファイル配信のみの構成: 脆弱性はデコーダー（c/dec/decode.c）に存在するため、信頼できるデータをサーバー側でBrotli圧縮して送信するのみの構成や、事前圧縮された静的な .br ファイルをそのまま配信するだけの構成ではデコード処理が行われず、影響を受けない。 .NET のデフォルト挙動: Microsoftのアドバイザリによれば、ASP.NET Coreおよび HttpClient はデフォルトではBrotli圧縮データを自動展開しない。自動展開でBrotliを有効化するよう明示的に設定変更している場合、または System.IO.Compression（BrotliStream / BrotliDecoder）で信頼できないデータを直接展開している場合のみ影響を受ける9。 2. スタンドアロン実行ファイル・コンテナイメージに関する注意点 自己完結型バイナリ（Self-Contained / 単一実行ファイル）: .NETのSelf-ContainedデプロイやNativeAOTでビルドされたアプリケーション、およびBunの bun build --compile で生成された実行ファイルは、ビルド時点のランタイム（および脆弱なBrotliデコーダー）をバイナリ内部に埋め込んでいるため、ランタイム更新後にアプリケーションの再ビルドと再デプロイが必要である。 動的リンクとバンドルの違い: Red Hat Enterprise LinuxやDebian、Amazon Linux 2023では、パッケージによってBrotliを内部バンドルしているもの（例：AL2023およびRHEL 8/9の nodejs24、dotnet8.0）と、OSの共有ライブラリ libbrotli を動的リンクしているもの（例：Debianの nodejs、RHEL 8/9およびAL2023の nodejs22、dotnet9.0、dotnet10.0）が混在している。したがって、OSパッケージとランタイムの双方を確認・更新し、実行中のプロセスを再起動する必要がある。 3. 自環境の確認方法 1. Node.js のバージョンおよびバンドルされている Brotli バージョンの確認 node --version node -p "process.versions.brotli" 2. Bun のバージョン確認（1.4.4 以上であるか） bun --version 3. .NET ランタイムのバージョン確認（8.0.33 / 9.0.22 / 10.0.14 以上であるか） dotnet --list-runtimes 4. Python パッケージの確認（Brotli 1.2.1 以上、brotlicffi 1.2.1.0 以上であるか） python3 -m pip show brotli brotlicffi 5. Linux OSパッケージおよびロード済み共有ライブラリの確認 dpkg -l | grep -i brotli # Debian / Ubuntu rpm -qa | grep -i brotli # RHEL / Amazon Linux sudo grep -l brotlidec /proc/[0-9]*/maps 2>/dev/null 脆弱性の技術的な仕組み 前提：Brotliのブロック切り替えと高速パス（Fast Path）/ 安全パス（Safe Path） Brotliの圧縮ストリームは複数のブロックに分割されており、デコーダーはストリームを読み進めながらリテラル（tree_type = 0）、挿入・コピーコマンド（tree_type = 1）、距離コード（tree_type = 2）のブロックタイプを切り替える。 ブロックタイプを切り替える際、デコーダーは c/dec/decode.c 内の DecodeBlockTypeAndLength() を呼び出して次のブロックタイプ番号とブロック長をビットストリームから読み取る。このときBrotliデコーダーは、入力バッファに十分なデータがある場合に境界チェックを省略して高速に処理する Fast Path（safe = 0） と、入力不足を検査しながら処理する Safe Path（safe = 1） の2つの経路を持っている。 原因：戻り値の未チェック（CWE-252）と境界外書き込み（CWE-787） 脆弱性の根本原因は、c/dec/decode.c 内の DecodeBlockTypeAndLength() が返す真偽値 BROTLI_BOOL の仕様と、呼び出し元における戻り値の未チェックにある1。 戻り値 BROTLI_FALSE における2種類の意味の混在: 修正前の DecodeBlockTypeAndLength() は戻り値として単なる真偽値（BROTLI_BOOL）を返していた。この関数は、Safe Pathで入力ビットが一時的に不足している場合（!SafeReadSymbol や !SafeReadBlockLength）に BROTLI_FALSE を返すだけでなく、ストリームのブロックタイプ最大数 max_block_type が 1 以下であるにもかかわらずブロック切り替えが要求されたというストリーム構文エラー（フォーマット不正） の場合（if (max_block_type <= 1) return BROTLI_FALSE;）にも同じ BROTLI_FALSE を返していた。 Fast Path（safe = 0）での戻り値の無視: 修正前のコードでは、Fast Path用のラッパー関数 DecodeLiteralBlockSwitch()、DecodeCommandBlockSwitch()、DecodeDistanceBlockSwitch() の戻り値型が static void と定義されており、内部で呼び出す Decode*BlockSwitchInternal(0, s) の戻り値を完全に無視していた。さらに呼び出し元のマクロ BROTLI_SAFE(METHOD) も、safe == 0 の分岐では戻り値を検証せずにそのまま処理を継続する実装となっていた。 不正な内部状態でのデコード継続と境界外書き込み: 細工された圧縮ストリームによって本来起こり得ないブロック切り替えが要求された際、脆弱なデコーダーは構文エラーで停止せず、「追加入力が必要である」状態と誤認する、あるいはFast Path上でエラーを無視して不整合な内部状態のまま処理を継続してしまう。その結果、内部バッファの終端を越えて攻撃者のバイト列が書き込まれ、隣接するデコーダー状態メモリ（BrotliDecoderState）の破壊や機密メモリの漏洩、さらには任意のコード実行（RCE）へとつながる。 攻撃フロー 修正パッチ Googleの公式リポジトリにおける修正コミット 0ed4268a（および各ブランチへの反映コミット 50a9b70a、da980636、b418fa81）では、以下の変更が行われている2。 c/include/brotli/decode.h に、ブロック切り替えのフォーマット異常を表す新しいエラーコード BROTLI_DECODER_ERROR_FORMAT_BLOCK_SWITCH = -17 を追加。 DecodeBlockTypeAndLength() および各 Decode*BlockSwitch*() 関数の戻り値型を BROTLI_BOOL / void から BrotliDecoderErrorCode に変更し、max_block_type <= 1 のフォーマット異常時は BROTLI_DECODER_ERROR_FORMAT_BLOCK_SWITCH、入力不足時は BROTLI_DECODER_NEEDS_MORE_INPUT、成功時は BROTLI_DECODER_SUCCESS を明示的に返すように修正。 Safe PathとFast Pathの両方でステータスコードを検証し、BROTLI_DECODER_SUCCESS 以外の場合は即座に saveStateAndReturn へジャンプして処理を中断するマクロ BROTLI_SAFE_WITH_STATUS(METHOD) を導入。 c/dec/decode.c // google/brotli commit 0ed4268a より抜粋 -static BROTLI_INLINE BROTLI_BOOL DecodeBlockTypeAndLength( +static BROTLI_INLINE BrotliDecoderErrorCode DecodeBlockTypeAndLength( int safe, BrotliDecoderState* s, int tree_type) { brotli_reg_t max_block_type = s->num_block_types[tree_type]; const HuffmanCode* type_tree = &s->block_type_trees[ @@ -1187,7 +1187,7 @@ brotli_reg_t* ringbuffer = &s->block_type_rb[tree_type * 2]; brotli_reg_t block_type; if (max_block_type <= 1) { - return BROTLI_FALSE; - return BROTLI_DECODER_ERROR_FORMAT_BLOCK_SWITCH; } /* Read 0..15 + 3..39 bits. */ @@ -1197,11 +1197,13 @@ } else { BrotliBitReaderState memento; BrotliBitReaderSaveState(br, &memento); - if (!SafeReadSymbol(type_tree, br, &block_type)) return BROTLI_FALSE; - if (!SafeReadSymbol(type_tree, br, &block_type)) { - return BROTLI_DECODER_NEEDS_MORE_INPUT; - } if (!SafeReadBlockLength(s, &s->block_length[tree_type], len_tree, br)) { s->substate_read_block_length = BROTLI_STATE_READ_BLOCK_LENGTH_NONE; BrotliBitReaderRestoreState(br, &memento); - return BROTLI_FALSE; - return BROTLI_DECODER_NEEDS_MORE_INPUT; } } ... ringbuffer[0] = ringbuffer[1]; ringbuffer[1] = block_type; - return BROTLI_TRUE; - return BROTLI_DECODER_SUCCESS; } -static BROTLI_INLINE BROTLI_BOOL DecodeLiteralBlockSwitchInternal( +static BROTLI_INLINE BrotliDecoderErrorCode DecodeLiteralBlockSwitchInternal( int safe, BrotliDecoderState* s) { - if (!DecodeBlockTypeAndLength(safe, s, 0)) { - return BROTLI_FALSE; - BrotliDecoderErrorCode result = DecodeBlockTypeAndLength(safe, s, 0); - if (result != BROTLI_DECODER_SUCCESS) { - return result; } PrepareLiteralDecoding(s); - return BROTLI_TRUE; - return BROTLI_DECODER_SUCCESS; } -static void BROTLI_NOINLINE DecodeLiteralBlockSwitch(BrotliDecoderState* s) { - DecodeLiteralBlockSwitchInternal(0, s); +static BROTLI_NOINLINE BrotliDecoderErrorCode +DecodeLiteralBlockSwitch(BrotliDecoderState* s) { - return DecodeLiteralBlockSwitchInternal(0, s); } 呼び出し元のマクロも以下のように BROTLI_SAFE_WITH_STATUS へ置き換えられ、safe フラグの有無にかかわらずエラー発生時にデコードが即座に停止するようになった。 c/dec/decode.c +/* NB: METHOD should return BROTLI_DECODER_SUCCESS, BROTLI_DECODER_ERROR_*, or - BROTLI_DECODER_NEEDS_MORE_INPUT; the later two break the processing. */ +#define BROTLI_SAFE_WITH_STATUS(METHOD) \ - { \ - BrotliDecoderErrorCode status; \ - if (safe) { \ - status = Safe##METHOD; \ - } else { \ - status = METHOD; \ - } \ - if (status != BROTLI_DECODER_SUCCESS) { \ - result = status; \ - goto saveStateAndReturn; \ - } \ - } 対策と緩和策 1. 恒久対策：修正バージョンへのアップデートと再ビルド 利用しているOSパッケージ、言語ランタイム、および依存ライブラリを修正バージョンへ更新し、稼働中のプロセスを再起動する。また、単一実行ファイル化（Bunの bun build --compile、.NETのSelf-Contained / NativeAOT）やDockerコンテナイメージを利用している場合は、更新後のランタイム・ベースイメージを用いて再ビルドおよび再デプロイを実施する必要がある。 各環境におけるアップデートコマンド例# 1. Amazon Linux 2023 の場合（ALAS2023-2026-3334 / 3330 / 3367） sudo dnf update brotli nodejs24 dotnet8.0 -y 2. Ubuntu / Debian の場合（USN-8956-1 / USN-8958-1 / DSA-6582-1） sudo apt update && sudo apt install --only-upgrade brotli libbrotli1 python3-brotli -y 3. Node.js の更新（nvm を利用している場合） nvm install 24.22.1 # または 22.23.4 / 26.12.1 4. Python パッケージ（PyPI）の更新（1.2.1 / 1.2.1.0 以上） pip install -U "Brotli>=1.2.1" "brotlicffi>=1.2.1.0" 5. Bun の更新（1.4.4 以上） bun upgrade 2. 一時的な緩和策（アップデートが直ちに実施できない場合） 各ベンダーのアドバイザリおよび技術資料では、即座にパッチを適用できない環境向けに以下の緩和策が案内されている。 WAFやリバースプロキシにおける受信 Content-Encoding: br リクエストの遮断: AWSのセキュリティブレティン 2026-155-AWS 等では、クライアントから送信される Content-Encoding: br ヘッダー付きHTTPリクエストをWAFやプロキシで拒否する緩和策が提示されている。AWSが公開しているAWS WAFカスタムルールの設定例（Countモードで検証後に "Count": {} を "Block": {} に変更する手順）は以下の通りである。なお、AWS WAFは受信リクエストのみを検査するため、アプリケーションが外部サーバーから取得するレスポンスには効かない点に留意が必要である10。 { "Name": "Node2Shell_BROTLI", "Priority": 2, "Statement": { "RegexMatchStatement": { "RegexString": "^\s*br\s*$", "FieldToMatch": { "SingleHeader": { "Name": "content-encoding" } }, "TextTransformations": [ { "Priority": 0, "Type": "LOWERCASE" } ] } }, "Action": { "Count": {} }, "RuleLabels": [ { "Name": "Node2Shell_Brotli" } ], "VisibilityConfig": { "SampledRequestsEnabled": true, "CloudWatchMetricsEnabled": true, "MetricName": "Node2Shell_BROTLI" } } HTTPクライアントおよびPython環境におけるBrotliデコードの抑止: 注意点（Accept-Encoding ヘッダー変更の限界）: リクエストヘッダーの Accept-Encoding から br を除外したとしても、悪意あるサーバーはそれを無視して Content-Encoding: br のレスポンスを送りつけることができるため、クライアント側で自動解凍自体が有効なままでは対策として不十分である。 Bun: セキュリティアドバイザリ（GHSA-663w-cv8g-jj2p）では、fetch 呼び出し時に decompress: false を渡すことで、Accept-Encoding: br の送信を抑止するとともにレスポンス自体の自動デコードを無効化する回避策が案内されている8。 Python: 直ちにアップグレードできない場合の緩和策として、Brotli および brotlicffi パッケージ（ならびに httpx[brotli] 等のextra指定）自体をアンインストールし、urllib3、requests、aiohttp 等でBrotliデコーダーが呼び出されない状態（gzip / deflate へのフォールバック）にする方法が挙げられている6。 PAN-OS: ホットフィックス適用までの回避策としてCLIから set system setting brotli-encoding disable を実行（またはWeb UIの Device > Setup > Content-ID から Allow Brotli Encoding のチェックを解除）してBrotliインスペクションを無効化する手順が案内されている。 参考資料・出典一覧 CVE.org - CVE-2026-111497 Google Brotli GitHub Repository - Commit 0ed4268a Node.js - Wednesday, October 21, 2026 Security Releases Imperva Blog - Node2Shell: From Brotli Data to Remote Code Execution (CVE-2026-111497) JPCERT/CC - BrotliのC言語実装における境界外書き込みの脆弱性（CVE-2026-111497）に関する注意喚起 (JPCERT-AT-2026-0034) Broccoli2Shell: Brotli decoder RCE (CVE-2026-111497) in Node.js, Python and more GitHub Advisory Database - GHSA-9v8h-qqgm-4m35 (PyPI brotli / brotlicffi) Bun Security Advisory - GHSA-663w-cv8g-jj2p Microsoft .NET Security Advisory - CVE-2026-111497: Out of bounds write in Brotli leads to RCE AWS Security Bulletin - 2026-155-AWS: CVE-2026-111497: Native Brotli Decoder Remote Code Execution and Memory Disclosure
CVE-2026-111497: CVE-2026-111497: Out-of-Bounds Heap Write and Remote Code Execution in Google Brotli Decoder (Node2Shell) CVE-2026-111497: Out-of-Bounds Heap Write and Remote Code Execution in Google Brotli Decoder (Node2Shell) > Vulnerability ID: CVE-2026-111497 > CVSS Score: 9.8 > Published: 2026-10-22 CVE-2026-111497, tracked in threat intelligence under the aliases Node2Shell, Broccoli2Shell, and HTTP2Shell, is a critical out-of-bounds heap write and denial-of-service vulnerability in the reference Google Brotli decompression library (c/dec/decode.c). The flaw originates from an unchecked return value and error-code conflation in DecodeBlockTypeAndLength() when processing malformed streams with single-block-type declarations (max_block_type <= 1). On the fast decoding path, the ignored error return causes the 32-bit unsigned block_length counter to underflow from 0 to UINT32_MAX (0xFFFFFFFF), corrupting internal decoder tables and enabling arbitrary heap memory overwrites via memmove16(). On the streaming path, the error return is misinterpreted as an incomplete bit-stream, trapping the worker process in an infinite 100% CPU loop. Because Google Brotli is embedded across major runtimes and infrastructure components—including Node.js, Envoy Proxy, Microsoft .NET, Istio, and Python—the vulnerability exposes a broad attack surface via standard HTTP Content-Encoding: br request and response bodies. TL;DR An unchecked return value in Google Brotli's DecodeBlockTypeAndLength() function leads to an integer underflow of block_length to 0xFFFFFFFF during fast-path decompression, enabling unauthenticated remote code execution via out-of-bounds heap writes or an infinite CPU loop during streaming decompression. --- ⚠️ Exploit Status: ACTIVE Technical Details - Vulnerability Class: CWE-252 (Unchecked Return Value) -> CWE-190 (Integer Underflow) -> CWE-787 (Out-of-Bounds Heap Write) - Affected Component: Google Brotli Decoder (c/dec/decode.c: DecodeBlockTypeAndLength & ProcessCommandsInternal) - Attack Vector: Network (Unauthenticated HTTP requests or responses with 'Content-Encoding: br') - CVSS v3.1 / v4.0: 9.8 CRITICAL (v3.1) / 9.2 CRITICAL (v4.0) - EPSS Score: 87.99% (99.76th Percentile) - Security Impact: Remote Code Execution (fast path OOB heap write) or 100% CPU Infinite Loop DoS (safe streaming path) - Exploit & KEV Status: Actively Exploited in the Wild; Listed in CISA KEV (Added 2026-10-27) Affected Systems - Google Brotli (libbrotli) - Node.js Runtime (Express, Koa, NestJS, Next.js, undici, axios, node-fetch, got, superagent) - Microsoft .NET Runtime & SDK - Envoy Proxy - Istio Service Mesh - Bun Runtime - Python brotli / brotlicffi - Go andybalholm/brotli - Apache Arrow, ClickHouse, DuckDB - Tianocore EDK2, p7zip / 7-zip-zstd - Debian 12, Ubuntu, Alpine Linux - Brotli: >= 1.0.3, < 1.0.10 (Fixed in: 1.0.10) - Brotli: >= 1.1.0, < 1.1.1 (Fixed in: 1.1.1) - Brotli: >= 1.2.0, < 1.2.1 (Fixed in: 1.2.1) - Node.js 22.x: < 22.23.4 (Fixed in: 22.23.4) - Node.js 24.x: >= 23.0.0, < 24.22.1 (Fixed in: 24.22.1) - Node.js 26.x: >= 25.0.0, < 26.12.1 (Fixed in: 26.12.1) - .NET: < 8.0.33, < 9.0.22, < 10.0.14 (Fixed in: 8.0.33 / 9.0.22 / 10.0.14) - Envoy Proxy: < 1.37.8, 1.38.0 - 1.38.5, 1.39.0 - 1.39.2 (Fixed in: 1.37.8 / 1.38.6 / 1.39.3) - Istio: < 1.29.9, 1.30.0 - 1.30.5, 1.31.0 - 1.31.1 (Fixed in: 1.29.9 / 1.30.6 / 1.31.2) - Bun: < 1.4.4 (Fixed in: 1.4.4) - Next.js: < 16.4.3 (Fixed in: 16.4.3) Code Analysis Commit: 0ed4268 Detect and report invalid stream earlier. diff --git a/c/dec/decode.c b/c/dec/decode.c index e87e7f5ea..19c7e0283 100644 --- a/c/dec/decode.c +++ b/c/dec/decode.c @@ -1176,7 +1176,7 @@ static BrotliDecoderErrorCode DecodeContextMap(brotli_reg_t context_map_size, /* Decodes a command or literal and updates block type ring-buffer. Reads 3..54 bits. */ -static BROTLI_INLINE BROTLI_BOOL DecodeBlockTypeAndLength( +static BROTLI_INLINE BrotliDecoderErrorCode DecodeBlockTypeAndLength( int safe, BrotliDecoderState* s, int tree_type) { brotli_reg_t max_block_type = s->num_block_types[tree_type]; const HuffmanCode* type_tree = &s->block_type_trees[ @@ -1187,7 +1187,7 @@ static BROTLI_INLINE BROTLI_BOOL DecodeBlockTypeAndLength( brotli_reg_t* ringbuffer = &s->block_type_rb[tree_type * 2]; brotli_reg_t block_type; if (max_block_type <= 1) { - return BROTLI_FALSE; + return BROTLI_DECODER_ERROR_FORMAT_BLOCK_SWITCH; } Exploit Details - GitHub: Proof-of-concept bitstream generator and RCE exploit harness for CVE-2026-111497 by Dimas Maulana. - GitHub: Node2Shell proof-of-concept repository demonstrating CVE-2026-111497 exploitation against Node.js. - GitHub: Technical analysis and crash reproduction repository by Qi Deng. - GitHub: Assetnote vulnerability scanner for identifying endpoints vulnerable to Node2Shell (CVE-2026-111497). Mitigation Strategies - Upgrade Google Brotli and all downstream runtimes (Node.js, .NET, Envoy, Istio, Bun, Python) that statically link or bundle the C decoder. - Block or strip incoming HTTP requests containing the 'Content-Encoding: br' header at the WAF, API gateway, or reverse proxy layer. - Configure outbound HTTP clients (undici, axios, node-fetch, got) to omit 'br' from 'Accept-Encoding' headers when querying untrusted external servers. - Audit container images and host filesystems for secondary or statically compiled Node.js, Envoy, and .NET binaries. Remediation Steps: 1. Identify all vulnerable Node.js instances by running: node -p "require('zlib').constants.BROTLI_DECODER_ERROR_FORMAT_BLOCK_SWITCH || 'VULNERABLE'" 2. Upgrade Node.js runtimes to versions 22.23.4, 24.22.1, or 26.12.1 (migrate off EOL Node.js 20.x). 3. Upgrade Google Brotli system libraries (libbrotli1) to versions 1.0.10, 1.1.1, or 1.2.1 and restart dependent services. 4. Upgrade Microsoft .NET runtimes to 8.0.33, 9.0.22, or 10.0.14. 5. Upgrade Envoy Proxy (< 1.37.8, 1.38.0-1.38.5, 1.39.0-1.39.2) and Istio (< 1.29.9, 1.30.0-1.30.5, 1.31.0-1.31.1) to patched releases. 6. Deploy WAF rules to drop HTTP POST/PUT/PATCH requests with 'Content-Encoding: br' until all upstream workers are patched. References - National Vulnerability Database (NVD) Record: CVE-2026-111497 - CVE.org Authoritative Record: CVE-2026-111497 - CISA Known Exploited Vulnerabilities (KEV) Catalog - Google Brotli Upstream Fix Commit (0ed4268a4401abcb4472096340477cf4af7d1a2b) - Node.js Security Advisory (October 2026) - GitHub Advisory Database (GHSA-9v8h-qqgm-4m35) - Envoy Proxy Security Advisory (GHSA-3wvj-j6qm-62mr) - Microsoft .NET Announcement Issue #494 - ELLIO Threat Research Analysis: Node2Shell RCE on Stock Node.js Builds - Aikido Security Analysis: Node2Shell Node.js Brotli RCE - Dimas Maulana (dimasma0305) CVE-2026-111497 PoC Repository - Qi Deng (ikow) brotli2crash Analysis Repository - Openwall oss-security Mailing List Disclosure - RFC 7932: Brotli Compressed Data Format Specification --- Read the full report for CVE-2026-111497 on our website for more details including interactive diagrams and full exploit analysis.
Node2ShellはNode.jsだけの話ではない。Brotliの欠陥でPythonも対象、CVE-2026-111497の該当判定 「Node2Shell? うちは Node.js を使っていないから関係ないな」。10月下旬にこのニュースを見て、そう判断しかけた方もいると思います。ところが、Node.js を使っていなくても確認が必要な場合があります。Node2Shell(HTTP2Shell とも呼ばれる、CVE-2026-111497)の正体は、Node.js ではなく Google の圧縮ライブラリ Brotli の欠陥でした。Python の Brotli パッケージ(入っていると requests などが自動で使う)、Bun、Envoy、Git for Windows にも同じ欠陥がありました。10月27日には、米国の CISA(サイバーセキュリティ・社会基盤安全保障庁)が、実際に悪用が確認された脆弱性の一覧に追加しています。 この記事は、Node.js・Python・Bun でアプリを作っている人や、Windows で Git for Windows を使っている人向けです。読み終えると、次の3つが分かります。 なぜ「Node.js の脆弱性」として広まったのか(原因) 自分の環境が該当するか、どこまで上げればよいか(言語・ツール別の判定) 呼び名・深刻度・RCE の範囲など、記事ごとに食い違う情報のどれを信じればよいか 情報は2026年10月29日時点のものです。技術的な解析は Imperva と OpenSourceMalware の記事が詳しく、Python・curl・Git for Windows の動作検証は技術ブログの lilting が詳しいです。どれも末尾のリンクから読めます。 ! 先に答え(2026年10月29日時点) 出回った言い方 一次情報での答え Node.js の脆弱性 欠陥があるのは Google の Brotli。Node.js は同梱していた Brotli を直した側 Node.js を使っていなければ無関係 Python(Brotli パッケージがあると requests 等が使う)・Bun・Envoy・Git for Windows も対象 Node2Shell と HTTP2Shell は別の脆弱性 どちらも CVE-2026-111497 の1件 深刻度は High? Critical? どちらも正しい。評価した組織が違う 素の Node.js ならどこでも RCE される 実証は Node.js 24.22.0(arm64 と x86-64)で報告された。24.22.0 用の攻撃データは 22.23.3・26.12.0 では通らず、ビルドごとに調整が要る 実際の攻撃はまだ? CISA が10月27日に、悪用が確認された脆弱性の一覧(KEV)に追加した。攻撃通信を観測したという報告もある 自分は該当する? 使っている言語ではなく、「信頼できない相手から来た Brotli データを展開するか」と「同梱している Brotli が直った版か」で決まります。判定だけ知りたい方は「自分は関係ある? 言語・ツール別の判定」へ進んでください。 Brotli とは何で、何が壊れていたのか Brotli は Google が作った圧縮形式で、Web では HTTP の Content-Encoding: br として使われます。欠陥があったのは、圧縮データを元に戻す部分(デコーダ)の C 言語実装です。壊れた圧縮データを渡すと、デコーダが内部バッファの外へ書き込んでしまいます(境界外書き込み)。本来触ってはいけないメモリを書き換えるため、条件がそろうと遠隔からのコード実行(RCE)につながります。 影響を受ける版: 1.0 系は 1.0.3〜1.0.9、1.1 系は 1.1.0、1.2 系は 1.2.0 修正版: 1.0.10 / 1.1.1 / 1.2.1(日本時間の10月22日 04:27 公開) CVE の採番: Google 発見: OpenAI Codex Security なぜ「Node.js の脆弱性」として広まったのか 広く知られるきっかけが、10月21日の Node.js 定例セキュリティリリースだったからです。流れを表にまとめます(日付は日本時間)。 日付 出来事 2月27日 Brotli のリポジトリに修正コミット。メッセージは「Detect and report invalid stream earlier.」(壊れたストリームを早めに検出して報告する)の1行で、脆弱性とは書かれていない。修正版の公開まで約237日 10月21日 Node.js が定例セキュリティリリースで10件を修正。その1件がこの欠陥 10月22日 Brotli の修正版を公開。Imperva が「Node2Shell」の題で RCE の実証記事を公開 10月23日 OpenSourceMalware が Python への波及を公表 10月24日 Envoy がアドバイザリを公開。Git for Windows に Issue #6514 が立つ Imperva はセキュリティ企業です。実証の対象が Node.js で、記事の題にも Node.js が入りました。そのため、「Node.js の脆弱性」として広まりました。 ところが、Node.js が直した中身は Brotli のコードです。Node.js は Brotli を自分のリポジトリに同梱していて、今回は Brotli の修正コミットを cherry-pick で取り込みました。cherry-pick は、別のリポジトリの修正部分だけを持ってくる操作です。 つまり Node.js は、同梱していた Brotli を直した側であって、欠陥の持ち主ではありません。 Python への波及を最初にまとめた OpenSourceMalware(OSM)も、この点を「この脆弱性は、そもそも Node.js のものではない」と書いています。 OSM の原文(英語) The vulnerability isn't really in Node.js at all Node.js 以外に対象になるもの(Python・Bun・Envoy・Git for Windows) 原因が Brotli のデコーダにあるので、同じデコーダを積んでいるものは確認が必要です。10月29日までに、次のものが分かっています。 Python: Brotli / brotlicffi パッケージ。どちらかが入っていると、urllib3 / requests、httpx(brotli extra)、aiohttp、Scrapy が br の応答を自動で展開します Bun: 1.4.4 で同梱の Brotli を更新しました Envoy / Istio: Brotli の展開(decompressor)を設定した構成が対象です curl: リンクしている Brotli のライブラリ次第です Git for Windows: 2.56.0.windows.3 までは、同梱の brotli が 1.2.0 のままでした。10月26日に公開された 2.56.0.windows.4 で 1.2.1 に更新されています このほかにも、対象として次のものが見つかっています。 .NET: 修正版は 8.0.33 / 9.0.22 / 10.0.14 です(.NET Framework は対象外)。BrotliStream などで自分で展開する処理が対象です。HttpClient の応答の自動展開と ASP.NET Core のリクエスト展開は、既定では無効です Go の andybalholm/brotli: Brotli を Go に移植したライブラリです。v1.2.7 に同じ修正が移植されました Linux の git の HTTPS 通信: git が使う libcurl が Brotli 付きでビルドされていれば対象です。oss-security への投稿によれば、多くのディストリの libcurl は Brotli 付きです Git for Windows のメンテナは、10月24日の Issue で次のように書いています。 昨日の時点では、これは「ただの」node2shell だと言われていた。だから Git for Windows は無関係に見えた。 メンテナの原文(英語、Git for Windows Issue #6514) Yesterday, the word on the street was still that this was "only" node2shell, and therefore Git for Windows looked unaffected. メンテナ自身も、名前を見て「自分は関係ない」と判断しかけていたわけです。「Node2Shell」という名前は、最初に話題になった場所を示しているだけで、影響範囲を示してはいません。 該当するかは「言語」ではなく2つの条件で決まる 対象の部品が入っていても、すぐに攻撃されるとは限りません。どの環境から先に上げるかは、次の2つの条件で決まります。 条件1: 信頼できない相手から来た Brotli データを展開するか。 典型的な経路は2つあります。 外部サーバーの応答を、Node.js の fetch() や Python の requests などで受け取る。応答の中身は相手のサーバーが決めます。攻撃者が用意したサーバーなら、壊れたデータを返せます 受け取ったリクエスト本文を、ミドルウェアが展開する。Imperva は、Express 5 / body-parser 2 の raw()・json() がリクエスト本文を展開する経路で実証しています 一方、素の Node.js の HTTP サーバーは、リクエストを受け取っただけでは本文を展開しません(Imperva の記事による)。 条件2: 同梱している Brotli が直った版か。 これは言語やツール本体の版で決まります。Brotli を自分で入れていなくても、ランタイムやツールの中に入っていることがあります。 特に先に上げるべきなのは、外部の URL を取ってくる機能を持つアプリです。Webhook、URL のプレビュー表示、クローラ、「この URL の内容を取ってきて」と頼める機能などがこれに当たります。 下の図の「Brotli デコーダを積んだもの」は、前の節で挙げた Node.js・Python の Brotli / brotlicffi・Bun・Envoy・Git for Windows などです。 自分は関係ある? 言語・ツール別の判定 ! 判定の前に、落とし穴が2つあります。 版番号: Node.js は修正を cherry-pick で取り込みました。そのため、修正版でも process.versions.brotli の表示は修正前と変わりません(lilting の検証では、22.23.4 でも 1.1.0 のまま)。Node.js では、Brotli の版ではなく node -v で Node.js 本体の版を見ます。ただし、ディストリが提供する nodejs はシステムの libbrotli を使うことがあります(Ubuntu・Debian の告知)。その場合は、ディストリの告知で判断します スキャナ: Node.js はランタイムそのものなので、npm audit には出ません。Python では、10月23日に OSM が「Brotli・brotlicffi の PyPI パッケージは、どの脆弱性データベースにも載っていない」と書きました。翌24日には、pip-audit が検出するようになっています(lilting の検証)。スキャナが何も言わないことを、安全の根拠にしないでください 対象 何を見るか OK の基準・対処 優先して上げるべき使い方 Node.js node -v 22・24・26 系は、それぞれ 22.23.4 / 24.22.1 / 26.12.1 以上。それ以外の系列(20 以下など)は修正されないので、サポート中の系列へ移る fetch() で外部 URL を取る。Express 5 / body-parser 2 で br の本文を受ける Python Brotli / brotlicffi が入っているか Brotli 1.2.1 / brotlicffi 1.2.1.0 以上。Linux ディストリビューション(以下ディストリ)が提供するパッケージは、ディストリの更新で上げる requests・httpx・aiohttp 等で外部 URL を取る Bun bun --version 1.4.4 以上。コンパイル済みの実行ファイルは作り直しが必要(Aikido の記述) 外部 URL を取る Envoy Brotli decompressor を設定しているか 1.40.0 / 1.39.3 / 1.38.6 / 1.37.8 / 1.36.12 以上 設定している構成すべて Istio Brotli の展開を有効にしているか(EnvoyFilter など) 1.31.2 / 1.30.6 / 1.29.9 以上(Istio の告知 ISTIO-SECURITY-2026-007) 有効にしている構成すべて Git for Windows git version 2.56.0.windows.4 以上(10月26日公開。同梱の brotli は 1.2.1) 信頼できない HTTPS サーバーへの clone / fetch curl どの Brotli にリンクしているかは、ビルドした配布元次第 配布元(OS・ディストリ・同梱しているツール)の更新情報を確認して上げる。Windows 標準の curl は Brotli 非対応(lilting の検証) --compressed などで、信頼できない URL の応答を展開させる Linux の libbrotli ディストリのセキュリティ情報 ディストリの更新を当てる。版番号を変えずに修正だけ移植する(バックポート)ことがあるので、版番号ではなくディストリの告知で判断する libbrotli を使うアプリが外部データを展開する Bun 1.4.4 のリリースノート(公式ブログ)は、Security の節で Brotli に触れていますが、CVE 番号は書かれていません。CVE 番号で探すと見落としやすいので注意してください。 主なディストリの対応状況は、10月29日時点で次のとおりです。 Ubuntu: brotli は jammy(22.04)・noble(24.04)などで修正済みです(USN-8956-1 / USN-8956-2)。jammy 以降の nodejs はシステムの brotli を使うため「影響なし」とされています。focal(20.04)は、brotli が「評価中(Needs evaluation)」、Brotli を同梱する nodejs が「vulnerable」のままです Debian: brotli は bookworm(DLA-4855-1)と trixie(DSA-6582-1)で修正済みです。ディストリ版の nodejs と trixie の python-brotlicffi は、トラッカー上はまだ「vulnerable」の表示です。ただし、トラッカーの注記では、どちらもシステムの brotli を使うとされています 同じディストリの中でも、パッケージごとに状況が違います。使っているパッケージごとに告知を確かめてください。 Node.js・Python・Git for Windows については、表に書ききれない確かめ方を補足します。 Node.js: node -v で本体の版を見る node -v Docker イメージの中の Node.js を見る例(<image> は自分のイメージ名に置き換える) docker run --rm <image> node -v 出力を表の基準と比べます。手元の Node.js だけでなく、Docker イメージや、Node.js を同梱して配っているバイナリの中の版も見てください(Imperva の推奨)。 Python: Brotli / brotlicffi が入っているかを見る 確かめたい venv を有効にしてから実行する python -m pip show Brotli brotlicffi 出力の Version: の行を、表の基準と比べます。 どちらも見つからなければ、requests などは br の応答を展開しません(OSM の解説と lilting の検証)。ただし、Brotli を別の形で同梱したライブラリや外部ツールを使っている場合は、そちらも確かめてください。また、venv ごとに入っているパッケージは違います。アプリごと・コンテナごとに見てください。 Git for Windows: git version で版を見る git version git version 2.56.0.windows.4 以上と表示されれば、修正版です。10月26日に公開され、Issue #6514 もクローズされました。 同梱の brotli の版は、Git for Windows のインストール先にある etc/package-versions.txt で確かめられます。Git Bash からは次のように見られます。 grep brotli /etc/package-versions.txt 64ビット版の修正版なら mingw-w64-ucrt-x86_64-brotli 1.2.1-1 と出る 上げられるまでの間は、信頼できない HTTPS サーバーへの clone / fetch を避けるのが安全です(lilting の見解)。 呼び名・深刻度・RCE の範囲・悪用、食い違いの答え合わせ ここまでで判定はできます。この節では、調べると記事ごとに食い違って見える4つの点を、一次情報で確かめます。 Node2Shell と HTTP2Shell は同じ1件 Node2Shell は Imperva の記事タイトルが元です。HTTP2Shell は、セキュリティ企業 Aikido の記事の見出し「Node2Shell evolves to HTTP2Shell」(Node2Shell が HTTP2Shell に進化した)に出てくる呼び方です。見出しは、HTTP を使うライブラリやアプリにも影響が広がったことを伝えるものです。ただし、Aikido は呼び名を変えた理由を本文で説明していません。検索すると Broccoli2Shell という呼び方も出てきます。どれも指しているのは CVE-2026-111497 の1件です。 もう1つ紛らわしいのが、2024年の別の脆弱性です。「Node.js Brotli 脆弱性」で検索すると、検索エンジンの AI 要約が CVE-2024-22025 を返すことがあります。これは2024年に見つかった、fetch() が Brotli データを展開するときにサービス停止(DoS)を起こす問題で、今回とは別件です。 High と Critical 9.2 は、評価した組織が違う 深刻度の点数は CVSS という共通の尺度で付けます。CVE を採番した Google は、CVSS 4.0 で 9.2(Critical)と評価しました。GitHub のアドバイザリと NVD(米国の脆弱性データベース)もこの値を載せています。 一方、Node.js は自分のリリース表でこの件を High と書きました。評価したのは Node.js 自身で、対象も Node.js という1つの製品です。評価した組織も、評価の対象にした製品も違うので、どちらも間違いではありません。 RCE の実証は広がったが、成否はビルドで違う 「素の Node.js で RCE できる」という言い方も出回っています。最初に Imperva が実証に使ったのは、公式の Node.js 24.22.0 Linux arm64 イメージです(経路は fetch() と Express 5 / body-parser 2)。成功までには何回か試す必要がありました。 その後、セキュリティ企業の ELLIO が、Node.js 24.22.0 の x86-64 でも RCE に成功したと報告しました。成功した構成は4つで、node:http のサーバーから node:zlib を呼んで本文を展開するもの、公式の slim イメージ、Express 5.3.0(express.json())、Koa 3(@koa/bodyparser)です。node:http の例は、フレームワークを挟まず、アプリのコードが自分で本文を展開する構成です。ELLIO も、素の Node.js の HTTP サーバーはリクエストを受け取っただけでは Brotli の本文を展開しないと書いています(条件1 と同じ)。「node:http を使っているだけで RCE される」という意味ではありません。 一方、24.22.0 用に調整した攻撃データは、22.23.3 と 26.12.0 では1万回試しても成功しませんでした。ELLIO は、これらの版には別の調整が要るとしています。攻撃を成功させるには、ビルドごとに作り込む必要があるということです。「どの環境でもすぐ RCE される」わけではありません。 Python については、RCE を試した報告はまだありません。OSM は、壊れたデータを渡すとデコーダが誤った結果を返すところまでを確かめています。 ただし、24.22.0 用の攻撃データが通らなかったからといって、ほかの版が安全だという証明にはなりません。判定で該当した環境は、実証の有無にかかわらず上げてください。 実際の攻撃は、すでに確認されている 10月25日の時点では、悪用の報告は見当たりませんでした。その後、状況が変わっています。CISA は10月27日に、この CVE を KEV(Known Exploited Vulnerabilities、実際に悪用が確認された脆弱性の一覧)に追加しました。米国の政府機関には、11月10日までの対応が求められています。 ELLIO も10月26日の追記で、自社のセンサーで実際の攻撃通信を観測したと報告しています。狙いは Node.js 24.22.0 の x86-64 で、ELLIO の検証では、観測した攻撃データそのものは成功しませんでした。攻撃を再現するコード(PoC)も公開されて出回っています。 ただし、CISA は KEV に追加した根拠となった具体的な事例を公表していません。どの製品のどの使い方が狙われたのかは、まだ分かりません。 まだ分かっていないこと 10月29日時点で、次の点はまだ決着していません。 Ubuntu の focal(20.04)は、修正版が出ていません。Debian のディストリ版 nodejs と trixie の python-brotlicffi は、トラッカー上「vulnerable」の表示が残っています Python で RCE が可能かどうかを検証した報告は、見当たりません CISA が KEV に追加した根拠の事例は公表されておらず、どこが狙われたのかは分かっていません ブラウザや、Node.js を内蔵するアプリ(Electron など)については、この記事では扱いません。影響の有無を示す一次情報が見当たらないためです。 おわりに Node2Shell の原因は Node.js ではなく Brotli の欠陥で、Node.js は直した側でした。呼び名が違っても指しているのは1件で、深刻度の違いは評価した組織の違いです。RCE の成否はビルドによって違いますが、実際の攻撃はすでに確認されています。 「Node.js は使っていないから関係ない」と思った方も、Python の venv と git version を一度確かめてみてください。判断の材料は「Node2Shell」という名前ではなく、手元にあるパッケージとツールの版です。 参考リンク Node.js: Security Releases: October 21, 2026 GitHub Advisory: GHSA-9v8h-qqgm-4m35(PyPI Brotli / brotlicffi) NVD: CVE-2026-111497 google/brotli: Releases Git for Windows Issue #6514: Bundled brotli is still 1.2.0 in 2.56.0.windows.3 Imperva: Node2Shell: From Brotli Data to Remote Code Execution OpenSourceMalware: Node2Shell affects Python Envoy: GHSA-3wvj-j6qm-62mr Istio: ISTIO-SECURITY-2026-007 Bun: Bun v1.4.4 Aikido: Node2Shell evolves to HTTP2Shell lilting: Brotli CVE-2026-111497 beyond Node.js, tested with Python, curl, and Git for Windows CISA: Known Exploited Vulnerabilities Catalog(CVE-2026-111497) ELLIO: Node2Shell(CVE-2026-111497)の検証記事 Git for Windows: v2.56.0.windows.4 Ubuntu: CVE-2026-111497 Debian Security Tracker: CVE-2026-111497 .NET: dotnet/announcements #494 oss-security: Brotli CVE-2026-111497 and git-remote-https andybalholm/brotli: v1.2.7 の更新履歴
Microsoft Releases Emergency .NET Patches for Critical Node2Shell Vulnerability Microsoft has released emergency security updates for .NET to address Node2Shell (CVE-2026-111497), a memory corruption vulnerability in Google's Brotli decompression library. The flaw allows an unauthenticated attacker to send specially crafted Brotli-compressed data that can trigger an out-of-bounds memory write, potentially leading to information disclosure, denial of service, privilege escalation, or arbitrary code execution. The vulnerability affects .NET applications that process attacker-controlled Brotli data. ASP.NET Core and HttpClient are not vulnerable by default, as Brotli decompression must be explicitly enabled. Applications directly using Brotli decompression APIs may also be exposed. Microsoft issued out-of-band updates on October 25, 2026, covering the following versions: .NET 8 → 8.0.33 .NET 9 → 9.0.22 .NET 10 → 10.0.14 .NET 11 → RC3 Self-contained applications, NativeAOT deployments, and affected container images must be rebuilt and redeployed using patched components. Updating the shared runtime alone is insufficient for applications that bundle their own vulnerable runtime. Microsoft rates the vulnerability High (CVSS 8.1), while Google assigns the underlying Brotli flaw a Critical CVSS 4.0 score of 9.2. CISA has also added the vulnerability to its Known Exploited Vulnerabilities catalog following reports of exploitation in the wild. Source: announcements#496
CVE-2026-111497: a Brotli decoder bug forced an out-of-band .NET release (10.0.14) on Oct 25 Microsoft released .NET 10.0.14 on 25 October as an out-of-band security update, and the stated reason is CVE-2026-111497, an out-of-bounds write (CWE-787) in the Brotli decoder bundled with .NET. CVSS 8.1, publicly disclosed, exploitation marked more likely. Affected and fixed: - .NET 8 before 8.0.33 → 8.0.33 - .NET 9 before 9.0.22 → 9.0.22 - .NET 10 before 10.0.14 → 10.0.14 (SDK 10.0.114 or 10.0.403) - .NET Framework is not affected The same release completes the October 13 fixes for CVE-2026-70197 (SocketAsyncEventArgs) and CVE-2026-102870 (Blazor WebAssembly debugger), which had shipped incomplete, and adds CVE-2026-114148 for Linux source-build tarballs. Exposure needs a call path that decompresses attacker-controlled Brotli: request decompression with br enabled, HttpClient AutomaticDecompression including Brotli, or BrotliStream/BrotliDecoder on untrusted input. None of that is on by default, and response compression alone does not hit it. Until you update, dropping Brotli from those paths is a workable stopgap. Framework-dependent apps need the host runtime updated and restarted. Self-contained apps need a rebuild and republish, and the Blazor WebAssembly Server/DevServer packages have to be bumped separately because the shared runtime update does not cover them. Advisory: announcements#494 Release notes: github.com/dotnet/core/blob/main/release-notes/10…
Pretty stoked to have noticed this a full two days before they announced it publicly, but also disappointed it took them that long... announcements#494
Patched the Blazor WASM debugger RCE (CVE-2026-102870) on Oct 13? Microsoft's Oct 25 OOB release corrected the fixed package versions. A runtime update alone won't cover it: bump WebAssembly.Server and DevServer to 10.0.14, then restart the debugger. announcements#492
Her kernel açığının arkasında art niyetli planlar vardır. Mehmet Keçeci PHP kernel açığından sonra şimdi de .NET açığı: "Her kernel açığının arkasında art niyetli planlar vardır. Mehmet Keçeci" Çünkü çekirdek (kernel) seviyesindeki zafiyetler, bir sistemdeki tüm mantıksal sınırları, antivirüs yazılımlarını ve kullanıcı yalıtımlarını tamamen bypass etmek için tasarlanan "nihai silahlar" gibidir. APT (Gelişmiş Sürekli Tehdit) aktörleri ve devlet destekli hacker grupları, hedef sistemde kalıcılık sağlamak için her zaman bu tarz yetki yükseltme açıklarını ceplerinde hazır tutarlar. PHP ve Çekirdek (Kernel) Açıklarının Anatomisi PHP tabanlı bir zafiyet (örneğin kritik bir RCE - Uzaktan Kod Çalıştırma açığı) web sunucusuna dışarıdan sızmayı sağlar. Ancak saldırgan içeri girdiğinde genellikle kısıtlı yetkilere sahip www-data veya nobody kullanıcısıdır. İşte bu noktada Kernel açığı devreye girer: • Amaç: Saldırgan işletim sisteminin kalbine (ring 0) inmek zorundadır. Kernel zafiyetleri donanım, bellek yönetimi veya sürücülerdeki hataları sömürerek saldırganı bir anda "En Yetkili Modu"na (Root/SYSTEM) yükseltir. • Arka Plan: Kernel açıkları çok nadir bulunur, tespiti zordur ve arkasında siber casusluk, sisteme kalıcı arka kapılar (rootkit) yerleştirme gibi çok ciddi, organize art niyetli planlar barındırır. Sızılan sistemde iz bırakmadan her şeyi silme yetkisini bu açıklar verir. .NET Açığının (CVE-2026-114148) Bu Denklemdeki Yeri .NET açığı doğrudan bir Linux Kernel açığı değildir, ancak doğurduğu sonuç siber güvenlik stratejisi açısından tam olarak bir Kernel açığı gibi tehlikelidir. • Mantıksal Kernel Etkisi: Bu açık, Linux Kernel'ın zayıflığından değil, .NET dosyalarının Linux üzerindeki hatalı izinlerinden (CWE-276) kaynaklanır. Ancak saldırgana sağladığı avantaj birebir aynıdır: Düşük yetkili bir siber saldırgan, bu açığı kullanarak Linux'ta Root (yani en yetkili) seviyesine tırmanır. • Art Niyetli Planlar Açısından: Bu .NET açığı, Linux sunucularına doğrudan "dışarıdan" sızma imkanı vermez. Tıpkı bir Kernel açığı gibi, "Post-Exploitation" (Sızma Sonrası) aşaması için saklanan bir silahtır. Saldırgan PHP veya başka bir yolla web sunucunuza sızdıktan sonra, sistemin tamamen kontrolünü ele geçirmek için bu .NET açığını kullanacaktır. İki Tür Açığın Doğrudan Karşılaştırması Kriter Tipik PHP / Web Açıkları .NET / Kernel Yetki Yükseltme Açıkları İlk Giriş Noktası Çok Yüksek. Dışarıdan tarayıcı ile tetiklenebilir. Düşük. Saldırganın zaten içeride bir ayağı olmalıdır. Sistem Üzerindeki Etkisi Sınırlı. Genelde sadece ilgili uygulamanın verilerine erişir. Tam Kontrol. Tüm işletim sistemini ele geçirir, logları siler. "Her kernel açığının arkasında art niyetli planlar vardır. Mehmet Keçeci" Uyuşma Derecesi Genelde otomatize botlar ve fidye yazılımları tarafından ilk kapıyı aralamak için kullanılır. Tam Uyuşur. Hedefe yönelik, organize ve sistemde kalıcı olmayı amaçlayan art niyetli planların anahtarıdır. Özet Değerlendirme "Her kernel açığının arkasında art niyetli planlar vardır. Mehmet Keçeci" çerçevesinde baktığımızda; CVE-2026-114148 (.NET) açığı, en az bir Kernel açığı kadar ciddiye alınmalıdır. Çünkü siber saldırganlar kurumsal bir ağa sızarken tek bir açıkla yetinmezler; zincirleme bir reaksiyon (Exploit Chain) kurarlar. PHP açığı ile kapıdan girerler, bu tarz bir .NET veya Kernel açığı ile de evin tapusunu (Root yetkisini) üzerlerine alırlar. Dolayısıyla, "içeride zaten korumalıyız" yanılgısına düşmeden, bu izin hatasının Linux sunucularda hızla kapatılması kritik önem taşır. windowsforum.com announcements#495
What I'm doing until then: ✂️ Remove Brotli from AutomaticDecompression and keep GZip. It's a one-line change. 🛡️ Block Content-Encoding: br at the proxy or WAF. 👀 Watch dotnet/announcements The cost is slightly bigger payloads, which I'll take.
ASP .NET Coreも更新しましょうネ announcements#472