Node2Shellとは｜Node.js Brotli脆弱性CVE-2026-111497の影響範囲・修正版・確認手順

Node2Shellは、Node.jsに同梱されたGoogle Brotliのデコーダーにある境界外書き込みの脆弱性（CVE-2026-111497）の通称で、細工したBrotliデータを展開させるとプロセスのクラッシュやメモリの漏えい、リモートコード実行につながります。Node.jsは22.23.4・24.22.1（24系は24.22.2以降を推奨）・26.12.1以降で修正しており、Node.js 20以前のサポートが終わった系列には修正版が出ていません。

2026年10月27日には、米CISAが「悪用が確認された脆弱性」の一覧（KEV）に追加しました。公開直後の記事には「KEVには入っていない」と書かれたものがありますが、現時点では悪用の証拠がある脆弱性として扱う必要があります。

この記事でわかること

• Node2Shellという名前の由来と、HTTP2Shellなど別名との関係
• 影響を受けるバージョンと、系列別の修正版
• 自分のアプリが影響を受けるかを判断する3つの質問
• バージョンの確認手順と、確認でつまずきやすい点
• AWS・Vercel・Docker・Debian/Ubuntuでの対応のしかた
• すぐ更新できないときの回避策と、その限界

この記事が役立つ人

Node.jsで動くWebサービスや社内システムを運用している開発者・インフラ担当者、委託先からNode.jsの更新を求められた情報システム担当者を想定しています。

Node2Shellで押さえるべき3点

1. 対策はアップデートだけです。Node.jsもGoogleも回避策は出していません。22系は22.23.4、24系は24.22.2、26系は26.12.1以降に上げて、プロセスを再起動します。
2. Node.js 20以前には修正版がありません。20系は2026年4月30日にサポートが終わっており、22系か24系以降への移行が必要です。
3. 影響があるかは、バージョンだけでは決まりません。「信頼できないBrotliデータを展開しているか」で決まります。ただし組み込みのfetch()はBrotliの応答を自動で展開するため、「うちは関係ない」とは決めつけないほうが安全です。

AIセキュリティ全体の論点から押さえたい人は、生成AIのセキュリティリスクもあわせて読むと位置づけがつかみやすくなります。

Node2Shellとは？名前の由来と別名

出典：Imperva Blog

Node2Shellは、CVE-2026-111497に付けられた通称です。名付けたのはセキュリティ企業のImpervaで、2026年10月22日のブログで「Brotliのデータからリモートでコードを実行できる」ことを実証した際にこの名前を使いました。

ただし、原因はNode.js本体ではなく、Node.jsが同梱しているGoogle Brotli（Webで広く使われる圧縮形式）のデコーダーにあります。そのため、Node.js以外のソフトにも影響が広がっており、呼び名もいくつかあります。

検索するときや社内で共有するときは、名前のゆれで情報を取りこぼさないよう、CVE番号を併記しておくのが確実です。

何が起きるのか：原因・被害・深刻度

出典：GitHub google/brotli

Node2Shellは、Brotliの不正なデータを「まだ続きが届いていないだけ」と誤って扱うことで、メモリの範囲外に書き込んでしまう脆弱性です。

Node.js公式のアドバイザリによると、デコーダーは不正な「block switch」を恒久的なフォーマットエラーとして扱わず、入力が足りないだけだと判断していました。その結果、ストリーミング処理のデコーダーが8バイトの内部バッファに入力を書き足し続け、範囲の外まで書き込みます。CVEレコードでは、Google Brotli 1.0.3〜1.2.0のc/dec/decode.cにあるバッファオーバーフローとされ、分類はCWE-787（境界外書き込み）とCWE-252（戻り値の未確認）です。

攻撃者は細工したBrotliデータを用意し、アプリにnode:zlibで展開させるだけで済みます。認証は必要ありません。起こりうる被害として、Node.js公式は次の3つを挙げています。

• プロセスのクラッシュ（サービス停止）
• プロセスメモリの漏えい
• リモートコード実行（サーバーの乗っ取り）

深刻度は出典によって表記が違う

深刻度は、どこの評価を見るかで表記が変わります。どれか1つだけを見て判断しないようにしてください。

Impervaは、公式のNode.js 24.22.0（Linux arm64）のイメージで、デバッガや特別なビルドを使わずにコード実行を実証しました。一方で、成功までには何度か試す必要があり、すべてのビルドで検証したわけではないとも書いています。「誰でも確実に乗っ取れる」わけではありませんが、KEVに入った以上、様子見で済ませる段階は過ぎています。

これまでの経緯（2026年10月21日〜30日）

公開から約10日で、修正版の公開、実証コードの公表、悪用の確認まで一気に進みました。

なお、KEVに追加されたこと以外に、攻撃の規模や被害を受けた組織、侵害が成功した事例の詳細は、2026年11月2日時点で公表されていません。Check Pointも、自社の観測では侵害の成功までは確認できていないとしています。

修正版：Node.jsの系列別とBrotli本体・ほかのソフト

出典：Node.js公式ブログ

Node.jsの修正版は、22.23.4・24.22.1・26.12.1です。24系は、24.22.1に不具合があり24.22.2が出ているため、24.22.2以降を入れてください。

Node.jsの系列別（2026年11月2日時点）

Node.js公式は「サポートが終わった系列は、セキュリティリリースのたびに必ず影響を受ける」としています。20系を使い続ける事情がある場合、公式が案内しているのはHeroDevsなどの商用の長期サポートです。

10月21日のリリースでは、Node2Shellを含めて10件（High 4件・Medium 3件・Low 3件）が修正されました。ほかのHighは、TLSのホスト名検証の回避（CVE-2026-105483 / CVE-2026-106069）とDNSのNULバイト切り捨て（CVE-2026-105482）です。修正版に上げれば、これらもまとめて直ります。

Google Brotli本体とPythonパッケージ

Node.js以外のソフト

脆弱性データベースのOSVでは、Bun 1.4.4、Envoy 1.37.8 / 1.38.6 / 1.39.3、Istio 1.29.9 / 1.30.6 / 1.31.2、Go移植版のandybalholm/brotli v1.2.7で修正したと案内されています。Apache Arrow、ClickHouse、DuckDB、EDK2なども影響を受ける製品として載っており、一覧は今も更新が続いています。.NET、PowerShell、PAN-OS、brotli4jにも影響があるとの報道もあります。

Brotliを使うソフトは幅広いので、Node.js以外の製品は、それぞれの開発元のセキュリティ情報で修正版を確かめてください。

影響を受けるかの判断：3つの質問

影響を受けるかどうかは、「バージョン」「展開する経路」「動いている場所」の3つで判断します。

影響を受けやすいケース

• リクエストボディを自動で展開している: Akamaiによると、Express 5 / body-parser 2のjson()・raw()・text()・urlencoded()は、inflateが既定で有効なため、Content-Encoding: brのボディを自動で展開します。誰でもこのリクエストを送れるため、もっとも狙われやすい経路です。Impervaは、Express 5.0.0 + body-parser 2.0.1、Express 5.3.0 + body-parser 2.3.0などで再現しています。
• 外部から取得した応答を展開している: 組み込みのfetch()はBrotliの応答を自動で展開します。悪意のあるサーバーや乗っ取られた外部サーバーの応答で攻撃が成り立ちます。この経路はWAFでは防げません。
• アプリのコードで外部の入力を展開している: zlib.brotliDecompress()やzlib.createBrotliDecompress()に、ユーザーのアップロードなど信頼できないデータを渡している場合です。

影響を受けにくいケース

Impervaによると、何も設定していないNode.jsのHTTPサーバーは、受け取っただけではBrotliのボディを展開しません。また、AWS LambdaのPython・Ruby・provided.al2023のランタイムはBrotliを同梱していません（自分でBrotliを入れている場合は別です）。

とはいえ、fetch()で外部と通信するアプリは珍しくありません。展開していないことをコードで確かめきれないなら、更新してしまうほうが早く確実です。

確認手順：Node.jsのバージョンを洗い出して比べる

確認は「どこで動いているかを洗い出す → バージョンを調べる → 修正版と比べる」の3段階で進めます。

ステップ1：Node.jsが動いている場所を洗い出す

本番・検証のサーバー、コンテナイメージ、サーバーレス関数、CIランナー、開発者のPC、Electronなどで作られたNode.js同梱のアプリまで含めて一覧にします。見落としやすいのは、ビルドだけに使うCIの環境と、しばらくデプロイしていない古いサービスです。

ステップ2：バージョンを調べる

# サーバーやPCで
node -v

# アプリの中から
node -e "console.log(process.versions.node)"

# コンテナイメージの中のNode.js
docker run --rm --entrypoint node <イメージ名> --version

ステップ3：修正版と比べる

22系は22.23.4、24系は24.22.1（推奨は24.22.2）、26系は26.12.1より前なら影響を受けます。20系以前はどの版でも修正されていません。

Node.js以外のBrotliも、あわせて確かめておくと安心です。

# apt / dnf で入れたNode.jsが使うOSのBrotli
dpkg-query -W libbrotli1      # Debian / Ubuntu
rpm -q brotli                 # Amazon Linux 2023 など

# Pythonのパッケージ
pip show brotli brotlicffi

# Bun（1.4.4以上か）
bun --version

確認でつまずきやすい5つの点

バージョンを見るだけでは判断を誤るケースがあります。次の5つは、確認したつもりで未修正のまま残る原因になりがちです。

1. process.versions.brotliは修正の有無の判断に使えない

Node.jsは修正を個別に取り込んでおり、同梱Brotliの表示上の版を上げていません。そのため、修正済みでも未修正でも1.2.0と表示されます。判断には必ずNode.js本体のバージョンを使ってください。

2. AWS LambdaのNode.js 24はprocess.versionが変わらない

AWSによると、Lambdaでは修正が当たってもprocess.versionの表示が変わりません。Classmethodの検証でも、修正後にv24.21.0と表示されています。Lambdaでは、CloudWatch LogsのINIT_STARTに出るランタイムの版で確かめます。基準はnodejs:22.mainline.v157以上、nodejs:24.mainline.v114以上です。

3. 更新してもプロセスを再起動しないと古いまま

Node.jsのバイナリを入れ替えても、動き続けているプロセスは古いコードのままです。pm2やsystemdで動かしているサービスは、更新後に必ず再起動してください。シェルでnode -vを打つだけでは、動作中のプロセスの版はわかりません。起動時のログにprocess.versionを出すなどして、動いているプロセスそのものの版を確かめます。

4. apt で入れたNode.jsは、OSのBrotliを使っている

Debianのnodejsパッケージは、同梱のBrotliではなくOSのlibbrotliを使います。DebianやUbuntuのaptで入れたNode.jsは、OSのbrotliパッケージを更新する必要があります。Debianのセキュリティトラッカー（2026年11月2日確認）では、bookwormが1.0.9-2+deb12u1、trixieが1.1.0-2+deb13u1で修正済みです。Ubuntuも10月26日にbrotliの修正が出たと報じられているので、Ubuntuのセキュリティ通知（USN）で確認してください。Red Hat系は、2026年11月2日時点でRed HatのBugzillaが未解決のままで、RHEL向けの修正版は確認できていません。

5. node:ltsのようなタグでも、イメージを作り直さないと直らない

Dockerfileでnode:ltsやnode:22などのタグを使っていても、手元やレジストリにある古いイメージをそのまま使えば未修正です。docker pullで最新を取り直し、イメージを作り直してデプロイし直します。ベースイメージのダイジェストを固定している場合は、固定先を更新します。

また、npm updateでは直りません。npmのパッケージではなく、Node.jsのランタイム（バイナリ）側の問題だからです。

クラウド・ホスティング別の対応

出典：Vercel Knowledge Base

マネージドサービスでも、利用者が何かしないと修正が入らないケースがあります。主なサービスの対応は次のとおりです（AWS・Vercelは公式情報、2026年11月2日時点）。

Lambdaで環境変数を足して更新する方法は、ClassmethodがTRIGGER_RUNTIME_UPDATEという環境変数を使って検証しています。AWS CLIの--environmentは環境変数を丸ごと置き換えるため、既存の変数を消さないよう注意が必要です。

Vercelは、外部のバックエンドについて、Vercel経由以外からのアクセスを制限することも勧めています。Netlify、Cloud Run、Azure App Service、Heroku、Renderなどは、各社のステータスページやセキュリティ情報で対応を確認してください。

すぐ更新できないときの回避策と限界

更新まで時間がかかる場合は、回避策で時間を稼げます。ただし、どの回避策も一部の経路しか塞げず、特に外部から取得した応答の展開には効かないものがほとんどです。

Rapid7も、すぐに直せない場合は信頼できないBrotliを展開する経路を制限するよう勧めています。回避策を入れた場合でも、更新の期限を決めて進めてください。

侵害されていないかを調べる観点

JPCERT/CCは、修正版の適用に加えて、侵害されていないかを調べることも勧めています。更新前にインターネットへ公開していたサービスは、次の観点でログを見直しておくと安心です。

• Brotliの展開中にNode.jsのプロセスが予期せず終了していないか
• デコーダーのエラーがログに出ていないか
• Content-Encoding: brの不審なリクエストが届いていないか（WAF・ロードバランサーのログ）
• Node.jsのプロセスの権限で、身に覚えのない子プロセスやシェルが起動していないか
• そのサーバーから想定外の外部通信が出ていないか

Impervaは、プロセスの異常終了やデコーダーのエラーは、それだけでは悪用の証拠にならないとしています。後半の2つは、リモートコード実行の脆弱性で一般的に確認する観点です。不審な点が見つかった場合は、認証情報やAPIキーの入れ替えも検討してください。

AIが見つけた脆弱性という側面

Node2Shellを見つけて報告したのは、OpenAIのCodex SecurityのKhai Tran氏とSylvie Mayer氏です（Node.js公式のクレジット）。修正はNode.jsのmcollina氏とaduh95氏が担当しました。

AIを使った脆弱性探しが、Node.jsという広く使われるランタイムの重要な修正につながった例といえます。AnthropicもAIを使ったセキュリティの取り組みを進めており、その動きはAnthropic Cyber Missionとはで整理しています。

同じ時期に話題になったPHP2Shell（CVE-2026-109618）は、名前は似ていますが別の脆弱性です。AIツールそのものの脆弱性としては、Flowise RCE（CVE-2025-59528）のような例もあります。

急いで対応すべき人・比較的優先度が低い人

更新が必要なことはどのケースでも同じですが、緊急度には差があります。

急いで対応すべき人

• Express 5 / body-parser 2で、インターネットからのリクエストを受け付けているサービスを運用している
• fetch()で外部のAPIやユーザーが指定したURLの内容を取得している（URLプレビュー、Webhookの中継、スクレイピングなど）
• Node.js 20以前を本番で使っている
• EC2やECSなど、自分でNode.jsを管理する環境で動かしている
• 長くデプロイしていないLambda関数やApp Runnerのサービスがある

比較的優先度が低い人

• 社内ネットワークだけで使い、外部と通信しないツールを動かしている
• Vercel（Node 22.x / 24.x）やAmplify HostingのSSRなど、事業者側で自動更新される環境だけを使っている
• 何も設定していないnode:httpのサーバーで、fetch()も使っていない

優先度が低いケースでも、開発者のPCやCIの環境に古いNode.jsが残っていれば、次の更新の機会にまとめて上げておくのが無難です。

業務システムでの対応チェックリスト

社内システムや委託開発のシステムでNode.jsを使っている企業は、次の順で進めると漏れを防げます。

委託先が開発・保守しているシステムでは、「どの環境を、いつまでに、どの版に上げたか」を報告してもらうと確認が早く進みます。脆弱性診断などで指摘を受けた箇所の直し方を整理したい場合は、脆弱性診断の指摘を修正するときの進め方も参考になります。AIを使ったコード生成で作ったシステムは、依存関係の管理が後回しになりやすい点にも注意が必要です。この点はAIコーディングのセキュリティリスクでまとめています。

自社の業務や既存システムにAIを組み込む場合、Node.jsのようなランタイムの更新も含めた保守の手間と費用を、開発の計画段階で見積もっておくと、今回のような緊急対応で慌てずに済みます。費用の目安はAI開発の費用相場で整理しています。

よくある質問

Q. Node2ShellとHTTP2Shellは別の脆弱性ですか？

同じ脆弱性（CVE-2026-111497）です。Node.jsでの悪用に注目した呼び名がNode2Shell、HTTPでBrotliを使うソフト全般に広がることに注目した呼び名がHTTP2Shellです。

Q. 24.22.1に上げましたが、24.22.2にも上げる必要がありますか？

上げることをおすすめします。Node2Shell自体は24.22.1で修正されていますが、AWSは24.22.1に既知の不具合があるとしており、10月28日に24.22.2が出ています。不具合の詳しい内容は公式には確認できていないため、24系は最新の24.22.2以降に揃えておくのが安全です。

Q. フロントエンドのJavaScriptやブラウザも影響を受けますか？

この脆弱性はNode.jsに同梱されたBrotliデコーダーのものなので、ブラウザ上で動くJavaScriptのコードが直接の対象になるわけではありません。ただし、Next.jsなどのビルドやSSRはサーバー側のNode.jsで動いているため、サーバー側の更新は必要です。

Q. 日本で被害は出ていますか？

2026年11月2日時点で、国内の被害は公表されていません。米CISAが悪用の証拠があるとしてKEVに追加しましたが、攻撃の規模や被害を受けた組織の詳細は明らかになっていません。

Q. Node.js 20をすぐに移行できない場合はどうすればよいですか？

当面はWAFやinflate: falseで受け取るリクエストの経路を塞ぎ、外部から取得する応答のBrotli展開を止めたうえで、22系か24系以降への移行を急ぐのが現実的です。どうしても20系を続ける必要がある場合は、Node.js公式が案内している商用の長期サポートを検討します。

Q. Node.jsを使っていなくても関係ありますか？

Brotliを使う他のソフトにも影響があります。Pythonのbrotli・brotlicffi、Bun、Envoy、Istio、.NETなどで修正版が案内されているため、使っている製品のセキュリティ情報を確認してください。

まとめ

Node2Shell（CVE-2026-111497）は、Node.jsが同梱するBrotliデコーダーの境界外書き込みで、2026年10月27日にCISAのKEVへ追加された、悪用の証拠がある脆弱性です。

• 修正版は22.23.4・24.22.1（推奨24.22.2）・26.12.1以降。20系以前には修正版がない
• 影響の有無は、外部から来たBrotliデータを展開しているかで決まる。Express 5 / body-parser 2とfetch()は自動で展開する
• process.versions.brotliは当てにならない。LambdaはINIT_START、aptで入れた環境はOSのbrotliで確かめる
• 更新後は再起動・イメージの作り直し・デプロイし直しまで行う
• WAFなどの回避策は外部から取得する応答には効かないため、アップデートが唯一の確実な対策

公式の情報は、Node.jsのセキュリティリリース、JPCERT/CCの注意喚起、CISAのKEV追加の発表、AWSのセキュリティ情報、Vercelの案内で確認できます。影響を受ける製品の一覧はOSVで更新が続いているので、Node.js以外の製品を使っている場合も定期的に見直してください。