Node2Shell RCEがNode.jsで発生：リスクにさらされるアプリと必要なパッチ

Node.jsのセキュリティ上の欠陥により、悪意のある圧縮データがリモートコード実行（RCE）につながる可能性がある。研究者は、変更を加えていないランタイムに対する攻撃を実証し、信頼できないBrotliデータを処理するアプリケーションへの懸念を高めた。

Impervaは2026年10月22日、Linux arm64上で稼働するNode.js 24.22.0におけるコード実行を実証し、Node2Shellの概念実証（PoC）を公開した。CVE-2026-111497として追跡されているこの脆弱性は、Node.jsの22、24、26の各リリース系列に影響する。セキュリティ修正は10月21日にリリースされた。

ExpressミドルウェアやNode.js組み込みのfetch() APIを使用するアプリケーションでは、直接呼び出していなくても脆弱なデコーダーに遭遇する可能性がある。攻撃者が制御するBrotliデータが影響を受けるコードに到達するかどうかによって、影響の有無は決まる。

Node2Shellの影響は独自の展開コードにとどまらない

Node2Shellは、Node.jsに組み込まれたBrotliデコーダーの境界外書き込みを悪用する。形式が不正な圧縮入力によってメモリが破壊され、クラッシュや情報漏えい、コード実行につながる可能性がある。関連するメモリ安全性のリスクは、OpenSSLのセキュリティアップデートも促しているが、脆弱性のメカニズムは異なる。

Akamaiの10月26日付の分析では、CVSS v4.0スコアを9.2（緊急）としている。一方、Node.jsはこの欠陥の深刻度を「高」と評価している。

Impervaの調査によると、影響は次の3つの経路から生じる可能性がある。

• Express 5ミドルウェア：設定されたリクエストパーサーが、Brotliでエンコードされたリクエスト本文を展開する可能性がある。
• Node.jsfetch():アプリケーションは、信頼できないサーバーから悪意のあるBrotliレスポンスを展開する可能性がある。
• node:zlib:攻撃者が制御するBrotliストリームを直接展開するサービスは、脆弱なデコーダーに到達する可能性がある。

「このバグは実装固有のものであり、Node.jsを標準のまま実行しているすべてのサーバーに影響するわけではない」と、watchTowrのプリンシパル脅威インテリジェンス・スペシャリスト、Yordan Ganchev氏は述べた。

Ganchev氏は、依存関係によって見落とされていた展開経路が持ち込まれる可能性があると警告した。同様の依存関係に伴うリスクは、WordPressのHEICアップロード脆弱性でも明らかになっており、画像処理ソフトウェアによってサーバーがRCEの危険にさらされる可能性があった。

ImpervaによるLinux arm64での実証には複数回の試行が必要だった。研究者は、他のプラットフォームで同程度に安定した悪用が可能かどうかは確認していない。ただし、基盤となる脆弱性はLinux arm64に限定されない。

パッチ適用済みNode.jsのバージョンと緩和策の優先順位

Node.jsのセキュリティアドバイザリでは、次の修正済みリリースを挙げている。

組織は、該当するパッチ適用済みリリース、またはそれ以降の修正済みバージョンをインストールすべきだ。サポート対象外のインストール環境では、サポート対象のブランチへ移行する必要がある。Expressやbody-parserだけを更新しても、ランタイムの欠陥は修正されない。

セキュリティチームは、次の6つの対策を優先すべきだ。

• 露出したアプリケーションを棚卸しする：サーバー、コンテナ、サーバーレスワークロード全体でNode.jsのバージョンを確認する。Express、fetch()、およびnode:zlib展開経路を特定する。
• デプロイにパッチを適用して検証する：ランタイムをアップグレードし、影響を受けるコンテナイメージを再構築して、本番プロセスがパッチ適用済みのバイナリを使用していることを確認する。
• 不要な展開を無効にする：Expressのbody-parserでinflateオプションをfalse圧縮されたリクエスト本文が不要な場合は設定する。
• 信頼できないトラフィックを制限する：適切な場合は受信Content-Encoding: brリクエストを一時的にブロックし、不要な外向き接続を制限する。受信トラフィックのフィルタリングでは、fetch()レスポンスは保護できない。
• 侵害の可能性を抑える：サービスを分離し、アプリケーションの権限、ファイルシステムへのアクセス、クラウド認証情報を制限する。
• インシデント対応計画を監視・テストする：原因不明のクラッシュ、展開エラー、予期しない子プロセス、疑わしい接続を調査する。アプリケーションログとネットワークログを相関分析し、インシデント対応計画をテストする。

境界でのフィルタリングによる保護は一時的なものにすぎない。過去のPeopleSoftのWAFバイパス攻撃は、パッチ適用の代わりにフィルタリングを行うと、脆弱なシステムが露出したままになり得ることを示した。

Ganchev氏は、「Decompression failed（展開に失敗しました）」を含むログを調査するよう推奨した。ただし、このようなエラーがあっても、悪用されたことの証明にはならない。セキュリティチームは、信頼できないBrotliデータを処理しているアプリケーションを特定し、パッチ適用済みのNode.jsランタイムが本番環境で稼働していることを確認すべきだ。

詳しくは：10月にGitLabが公開した2件目の重大なRCEパッチは、以前の修正を適用した後も、管理者がセキュリティリリースの確認を続けなければならない理由を示している。