Node.jsのBrotliデコーダーの脆弱性により公式ビルドでリモートコード実行が可能に

Impervaのセキュリティ研究者らは、公式のNode.jsランタイムにおける重大なリモートコード実行（RCE）脆弱性を実証しました。同梱されているデコーダーに特別に細工したBrotli圧縮データを入力することで、標準的なLinux arm64ビルドのNode.js 24.22.0上で任意のコードの実行に成功しました。Node.jsチームはこの欠陥をCVE-2026-111497として公開し、10月21日に修正版をリリースしました。開発者に対し、信頼できないBrotliストリームを処理するすべてのアプリケーションを更新するよう呼びかけています。

何が起きたか

「Node2Shell」と名付けられたこの実証は、以前の概念実証（PoC）試行からの大きな進展を示しています。過去の研究者たちは、意図的に弱体化させたテストビルドでのみコード実行を達成しており、標準ビルドではクラッシュするか、限定的なメモリ読み取りしかできませんでした。しかし、Impervaのチームは、デバッガーやカスタム修正を加えていない公式のNode.js 24.22.0イメージ上でエクスプロイトを実行しました。このエクスプロイトは決定論的ではなく、Linux arm64環境では成功までに複数回の試行が必要でしたが、本番グレードのセットアップでも完全なコード実行が可能であることが確認されました。

この脆弱性は、Node.js自体に同梱されているBrotliデコーダーに存在するため、幅広いアプリケーションに影響を与えます。アクティブな22.x、24.x、および26.xリリースラインが影響を受けます。リスクは、アプリケーションがBrotli圧縮データを復号する場合に生じます。これは主に2つの方法で発生します。組み込みのfetch() APIを通じて圧縮レスポンスを読み取る場合、またはミドルウェアが明示的に圧縮リクエストボディを復号する場合です。例えば、Express 5のボディパーサーはgzipやdeflateと同様にBrotliも処理するため、信頼できないソースからの受信リクエストを処理する多くのモダンなバックエンドサービスが危険にさらされています。

Impervaは、Express 5.0.0から5.3.0およびbody-parser 2.0.0から2.3.0を使用してこの攻撃ベクトルをテストし、リクエストとレスポンスの両方のパスを通じてコード実行を再現しました。素朴なNode.js HTTPサーバーは、ミドルウェアやボディを復号するための明示的な呼び出しを使用しない限り、デフォルトでは脆弱ではありません。10月22日時点で、実際の悪用に関する報告はありませんでしたが、公式ビルド上で動作する概念実証が存在することは、パッチ適用の緊急性を高めています。

仕組み

根本原因は、同梱されているBrotliデコーダーが圧縮ストリーム内の無効な状態遷移をどのように処理するかという点にあります。Brotliストリームは、復号の進行に伴って使用するブロックの種類を通知します。Impervaによって作成された悪意ある入力では、ストリームがその構造上不可能であると明確に排除されていたブロック変更に至りました。脆弱なデコーダーはこの矛盾を拒否する代わりに、追加入力の要求として解釈し、無効な状態で処理を継続しました。

デコーダーがこの破損した状態で継続すると、適切な境界チェックを実施できなくなります。メモリーサニタイザーを用いたテストにより、このロジックエラーが意図したバッファ制限を超えた書き込み（アウトオブバウンズ書き込み）を引き起こすことが判明しました。このメモリー破損は、攻撃者がコードを注入し実行するための隙を生み出します。Node.jsプロジェクトは、Brotliライブラリの上流パッチを取り込むことで問題を解決しました。この修正により、デコーダーはこうした不可能な構造的矛盾に遭遇した場合、直ちに停止してフォーマットエラーを返すようになり、無効な状態が発生することを防ぎます。

主要な詳細

• 脆弱性ID: CVE-2026-111497は、Node.jsに同梱されているBrotliデコーダーに影響します。
• 影響を受けるバージョン: アクティブなリリースライン22.x、24.x、および26.xは脆弱です。20.xなどのサポート終了（EOL）バージョンには修正が提供されません。
• 攻撃ベクトル: ミドルウェアによって復号されるHTTPリクエストボディ経由、またはfetch()レスポンス経由で送信される細工されたBrotliデータ。
• エクスプロイトの信頼性: Impervaの概念実証はLinux arm64上で成功するために複数回の試行が必要であり、他のアーキテクチャではテストされていません。
• 修正状況: パッチは10月21日にリリースされました。バージョン24.22.1では、悪意あるデータを安全に拒否します。
• ランタイムワークアラウンドなし: アドバイザリーによれば、Node.js内でこの問題を緩和するための設定変更はありません。更新が唯一の対策です。

なぜ重要なのか

ソフトウェアエンジニアや技術リードにとって、この脆弱性は依存関係チェーンにおける隠れたリスクを浮き彫りにします。欠陥がサードパーティのnpmパッケージではなくランタイム自体にあるため、標準的なパッケージ在庫ツールでは検出されない可能性があります。開発者はしばしば、圧縮ライブラリは安全な低レベルユーティリティだと仮定しますが、今回の事件はそれらがリモートコード実行への直接の経路となり得ることを証明しました。外部APIのプロキシを行うサービスやユーザーアップロードを受け入れるサービスは、厳格な検証なしにコンテンツを自動的に解凍する場合、特にリスクが高いです。

ランタイムワークアラウンドがないため、運用チームは機能フラグを切り替えるだけで安全を確保することはできません。インフラストラクチャがコンテナイメージやプリビルドアーティファクトに依存している場合、基盤となるNode.jsバイナリが更新されていることを確認する必要があります。これには、単なる再起動ではなく、サービスの再ビルドと再デプロイが必要なことがよくあります。さらに、Vercelのようなプラットフォームは、受信攻撃をブロックするためのWebアプリケーションファイアウォールルールを追加しましたが、これらはサーバーが他のホストから取得する悪意あるBrotliレスポンスに対する保護を提供せず、パッチ適用までの間、アウトバウンドパスが脆弱なまま残ります。

対応策

• すべてのNode.jsインスタンスを、22.x、24.x、または26.xラインの最新のパッチ適用済みバージョンに直ちにアップグレードしてください。
• コンテナイメージとCI/CDパイプラインを監査し、アプリケーションコードだけでなく、ベースとなるNode.jsバイナリが更新されていることを確認してください。
• Express 5またはbody-parserを使用し、信頼できないリクエストボディを受け入れるサービスを特定し、それらのパッチ適用を優先してください。
• 組み込みのfetch() APIの使用状況をレビューし、外部の信頼できないサーバーからのレスポンスが慎重に処理されていることを確認してください。
• 20.xなどのサポート終了バージョンで稼働しているすべてのアプリケーションを、セキュリティ修正を受け取れるサポート対象リリースラインに移行してください。
• 圧縮データを処理するサービスにおける異常なクラッシュやメモリエラーについてログを監視してください。これらは悪用の試みを示唆している可能性があります。