Node.js 脆弱性（2026 年 10 月）｜影響確認と更新判断

はじめに

2026 年 10 月 21 日（米国時間）、Node.js Project はサポート中の 22.x、24.x、26.x 系列に向けたセキュリティリリースを公開しました。修正対象は 10 件の CVE で、あわせて eMudhra の中間 CA 秘密鍵問題に対応するルート証明書の更新と公開鍵ブロックリストの追加、c-ares や undici などの依存コンポーネントの更新も含まれています。

Brotli デコーダーのリモートコード実行（RCE）や TLS 証明書検証の回避など、タイトルだけを見ると影響が大きく見える項目が並んでいます。一方で、成立には特定の処理経路や設定が必要な項目も多く、運用担当者にとっては「自社の Node.js がどこで動いていて、どの経路が該当し、更新後に何をもって完了とするか」を判断できることが重要です。本記事は、2026 年 10 月 22 日時点の公開情報に基づいて整理したもので、実機での検証は行っていません。

結論として、22.x は v22.23.4、24.x は v24.22.1、26.x は v26.12.1 が修正版で、EOL の 20.x 以前には公式の修正版が提供されません。確認すべきなのは操作中のシェルの node -v ではなく、本番で稼働しているプロセスやコンテナが修正版で動いているかどうかです。優先度は、攻撃者が制御できる Brotli 圧縮データを展開する経路と、外部の HTTPS サービスへ接続する処理の有無で判断します。

Node.js の脆弱性（2026 年 10 月）の概要と修正版

公式アドバイザリによると、今回の最高重要度は 3 系列とも High です。系列ごとに対象となる CVE の数が異なるため、まず自社で利用している系列と修正版を対応付けます。

修正版の公開日は、各リリースノートで 2026 年 10 月 21 日と記載されています。26.x は Current の段階にあり、Node.js のリリース情報ページは本番環境で Active LTS または Maintenance LTS を使うよう案内しています。24.x や 22.x を利用している環境は、同じ系列の修正版へ更新すれば今回の修正を取り込めるため、脆弱性対応のためだけに 26.x へメジャーアップグレードする必要はありません。

参考: Node.js Releases
“Production applications should only use Active LTS or Maintenance LTS releases.”
（本番アプリケーションでは、Active LTS または Maintenance LTS のリリースのみを使用すべきである）
https://nodejs.org/en/about/previous-releases

20.x は EOL のため、今回の修正版は提供されていません。公式アドバイザリは、セキュリティリリースのたびに EOL バージョンも影響を受けると明記しています。

参考: Node.js Wednesday, October 21, 2026 Security Releases
“End-of-Life versions are always affected when a security release occurs.”
（セキュリティリリースが行われるとき、EOL バージョンは常に影響を受ける）
https://nodejs.org/en/blog/vulnerability/october-2026-security-releases

20.x からの移行先の選び方や互換性の確認ポイントは、『Node.js 20 EOL と 3 月の DoS 脆弱性への対処手順』で解説しています。

執筆時点で、公式アドバイザリには実際の悪用に関する記載はなく、本記事では CISA KEV への登録も確認できていません。また、今回の CVE の CVSS スコアは公式アドバイザリに記載がなく、本記事では扱いません。以降の「悪用されうる条件」は、悪用が確認された事実ではなく、公表情報から読み取れる影響範囲の整理です。

10 件の CVE と影響が成立する条件

公式アドバイザリが公開しているのは各 CVE のタイトル、重要度、対象系列が中心で、攻撃手順や詳細な前提条件は示されていません。下表は公式の記載を短く要約したもので、影響を受けうる利用形態は表の後に、タイトルと修正内容から編集部が整理した内容として補足します。

CVE 一覧と影響を受けうる利用形態

各 CVE で影響を受けうる利用形態は次のとおりです（編集部の整理）。Brotli と TLS の 4 件は、次の H3 で詳しく扱います。

• CVE-2026-105482: 外部から影響を受ける名前を dns.resolve 系の API に渡して名前解決する処理
• CVE-2026-105481: HTTP クライアントとして keep-alive（接続の再利用）を使う処理
• CVE-2026-106074: ユーザーランドの起動スナップショットや SEA（単一実行ファイル）で配布し、crypto.randomUUID() や randomInt() を使うアプリケーション
• CVE-2026-106070: 26.x の ZipFile 機能で、外部から受け取ったアーカイブを扱う処理
• CVE-2026-106071 / CVE-2026-106073: --permission で権限を制限して運用している環境（106071 はワイルドカードを含む --allow-fs-* を使う場合）

CVE-2026-106074 は、起動スナップショットや SEA を作成し直さない限り、古い状態が埋め込まれたままになります。Node.js の公式ドキュメントでは、SEA は Node.js バイナリーへアプリケーションのデータを注入して作成すると説明されています。システムの Node.js を更新しても、作成済みの SEA 実行ファイルやスナップショットには修正が反映されないため、修正版で作成し直す必要があります。再作成は今後生成する値への対策で、すでに発行した値には及びません。生成した値を認証トークンやセッション ID、一意であることを前提とした識別子として使っていた場合は、利用方法に応じて、発行済みの値の重複の有無を確認し、必要に応じて無効化や再発行を検討することを推奨します。

重要度表記の差異（CVE-2026-106072）

CVE-2026-106072 は、公式アドバイザリでは Medium と記載されています。一方、3 系列のリリースノートでは「(CVE-2026-106069, CVE-2026-106072) tls: reject non-canonical IP addresses – High」と、CVE-2026-106069 と同じ行に High として記載されています。1 つの修正で 2 件の CVE に対応しているため、行としての重要度が高い方に合わせて記載されていると考えられます（編集上の推論）。本記事では、CVE ごとの重要度はアドバイザリの個別評価に従い、CVE-2026-106072 を Medium として扱っています。

このほか、26.12.1 のリリースノートの Notable Changes には CVE-2026-106071 の番号付きの記載がなく、コミット一覧に「src: fix the fs permission tree node on wildcard nodes」が含まれています。両者の対応関係はリリースノート上で明示されていないため、Permission Model をワイルドカード付きで利用している環境は、公式情報の更新を確認してください。

Brotli の RCE（CVE-2026-111497）が成立しうる経路

Brotli は Google が開発した可逆圧縮形式で、RFC 7932 で規定されています。HTTP では Content-Encoding: br として広く使われており、Node.js は Brotli のライブラリーを同梱しています。今回の修正は、リリースノートで「deps: brotli: cherry-pick 0ed4268a4401abcb44720963」と記載された、同梱ライブラリーへの修正の取り込みです。

問題があるのは圧縮（エンコード）ではなく展開（デコード）の処理です。Node.js が Brotli データを受け取っても、アプリケーションやライブラリーが展開しなければデコーダーは動作しません。Node.js の主な展開経路は次のとおりです。

アプリケーションによる明示的な展開

zlib.brotliDecompress() や zlib.createBrotliDecompress() などで、アップロードされたファイルやメッセージキューのデータを展開する処理です。入力の出所が外部であれば対象になります。

HTTP クライアントとしての応答の受信

Node.js 組み込みの fetch() は、応答の Content-Encoding に従って br を含む圧縮を自動で展開します。接続先のサーバーが攻撃者の管理下にある場合や、ユーザーが指定した URL を取得する処理（Webhook、クローラー、画像やページの取得など）では、応答の内容を攻撃者が制御できます。

HTTP サーバーとしてのリクエスト本文の受信

Node.js の http モジュール自体はリクエスト本文を自動展開しません。ただし、Express の body-parser は公式ドキュメントで gzip、br、deflate の自動展開に対応していると説明されており、既定の設定で圧縮されたリクエスト本文を展開します。

したがって、「Node.js で Web サーバーを動かしている」ことだけで外部から RCE が成立するとは判断できません。逆に、レスポンスの Brotli 圧縮を無効にしていても、上記の展開経路があれば対象です。優先度を判断する軸は、攻撃者が内容を制御できる Brotli データを、そのプロセスが展開するかどうかです。

公式アドバイザリには、攻撃に必要な入力の形式や成功の条件など、技術的な詳細は記載されていません。第三者の情報として、Vercel は自社の告知で、Node.js 自身は Brotli データを自動では展開せず、アプリケーションやライブラリーが攻撃者の制御するデータを展開する場合に影響を受けると説明しています。また、研究者が未修正の 22.x、24.x、26.x でプロセスのメモリー内容の漏えいとコマンド実行を実証したとも述べています（Vercel の告知）。これは Vercel の説明であり、公式アドバイザリで確認できる内容ではありません。

なお、Vercel の告知では、同社の WAF は Vercel を通過する受信トラフィックを対象とし、関数が外部から取得した応答は対象外であるとしています。前段の WAF やリバースプロキシーはリクエスト経路の対策にはなり得ますが、fetch() で取得する応答の展開には効果が及ばないため、Node.js の更新が基本の対策です。

TLS 証明書検証の 3 件と HTTPS クライアントへの影響

CVE-2026-105483、CVE-2026-106069、CVE-2026-106072 は、いずれも「接続先として指定したホスト（IP アドレス）」と「サーバー証明書の記載内容」を照合する処理の問題です。3 件の違いは、接続先がどのような表記で指定されたときに問題が起きるかにあります。

リリースノートでは、CVE-2026-106069 と CVE-2026-106072 は「tls: reject non-canonical IP addresses」、CVE-2026-105483 は「tls: fix ip normalization regression」で修正されています。CVE-2026-105483 の修正は「regression（リグレッション）」の修正と記載されており、24.x と 26.x の IP アドレスの正規化処理で生じた問題と読み取れます。22.x が対象外であることとも整合します。

3 件とも、照合の対象は「クライアントが接続しようとしたホスト」です。そのため、主に影響を受けるのは Node.js が HTTPS クライアントとして外部へ接続する処理（https.request()、fetch()、tls.connect() など）です。Node.js が HTTPS サーバーとして証明書を提示する処理や、mTLS でクライアント証明書を検証する処理は、公表されたタイトルが示す照合処理とは異なります（編集上の整理）。ただし、API ゲートウェイや BFF のように、サーバーとして動作しながら別のサービスへ HTTPS で接続するプロセスは、クライアント側の処理として対象になります。

公式は詳細な成立条件を公表していませんが、タイトルからは、接続先の文字列が特殊な表記になることが前提と読み取れます。設定ファイルで固定したホスト名に接続するだけの処理よりも、ユーザー入力や外部データから接続先を組み立てる処理の方が、影響を受ける可能性が高いと考えられます（編集上の推論）。

eMudhra と依存コンポーネント更新の確認点

今回のリリースには、10 件の CVE とは別に、公開済みの脆弱性へ対処するための依存コンポーネントの更新が含まれています。CVE の修正と依存コンポーネントの更新は、公式アドバイザリでも別の項目として記載されています。

系列ごとの依存コンポーネント更新

表は公式アドバイザリと各リリースノートの記載に基づきます。26.12.1 の undici 8.12.2 は Notable Changes ではなくコミット一覧に記載されています。各コンポーネントの更新でどの CVE に対処したかは、公式アドバイザリでは個別に示されていません。

Node.js での eMudhra 対応の仕組み

eMudhra の中間 CA 秘密鍵問題そのものと、ブラウザーや OS 側の対応状況は『eMudhra 中間 CA 証明書の秘密鍵問題｜影響範囲と確認・更新のポイント』で解説しています。本記事では Node.js 側の変更に絞って整理します。

Node.js 側の対応は、同梱ルート証明書の NSS 3.131.1 への更新と、「tls: reject chains containing blocked public keys」（PR #66871）の 2 点です。PR の説明によると、Node.js は Mozilla のルート証明書を同梱する一方で、ブラウザーの CRLSet や OneCRL に相当する仕組みも、既定のオンライン失効確認も持っていません。そのため、危殆化した 8 つの eMudhra / emSign 中間 CA の公開鍵（SPKI）の SHA-256 ハッシュを組み込みのブロックリストとして持ち、検証済みの証明書チェーンと照合します。一致した場合は通常の証明書検証の処理を通じて CERT_REVOKED として扱われます。

PR の説明では、この照合は Node.js が作成するすべての TLS コンテキストに組み込まれ、通常の検証経路を通るため rejectUnauthorized の設定に従うとされています。チェーンが拒否されるのは、通常の証明書検証が有効な場合に限られます。つまり、rejectUnauthorized: false や環境変数 NODE_TLS_REJECT_UNAUTHORIZED=0 で証明書検証を無効にしている処理では、更新後もこの保護は働きません。また、PR には既知の制約として次の記載があります。

参考: nodejs/node PR #66871
“Sessions resumed from before the upgrade are not re-verified.”
（更新前から再開された TLS セッションは、再検証されない）
https://github.com/nodejs/node/pull/66871

同梱 CA、OS ストア、NODE_EXTRA_CA_CERTS の違い

Node.js は既定で同梱のルート証明書だけを使い、OS の証明書ストアを参照しません。

参考: Node.js Learn「Enterprise Network Configuration」
“By default, Node.js uses Mozilla’s bundled root CAs”
（既定では、Node.js は同梱された Mozilla のルート CA を使用する）
https://nodejs.org/learn/http/enterprise-network-configuration

ただし、設定によって信頼する CA の範囲は変わり、Node.js の更新で変わる部分と変わらない部分があります。

同梱のルート証明書

Node.js のバイナリーに組み込まれた Mozilla 由来のルート証明書です。今回の修正版で NSS 3.131.1 に更新されており、Node.js の更新によって入れ替わります。

OS の証明書ストア

Windows 証明書ストア、macOS キーチェーン、Linux の OpenSSL 既定パスなどです。Node.js が参照するのは後述の設定を有効にした場合だけで、内容は OS やディストリビューションの更新で管理されます。Node.js を更新しても OS ストアの内容は変わりません。

NODE_USE_SYSTEM_CA

NODE_USE_SYSTEM_CA=1 または --use-system-ca を指定すると、同梱の CA に加えて OS の証明書ストアも信頼します。公式ドキュメントでは v22.19.0、v24.6.0 以降で利用できると説明されています。

NODE_EXTRA_CA_CERTS

指定した PEM ファイルの証明書を、同梱の CA に追加して信頼します。社内 CA などを追加する用途で使われ、ファイルの内容は利用者が管理します。Node.js の更新ではこのファイルは変わりません。

コード内の ca オプション

tls.connect() や https.request() に ca を指定すると、既定の CA の一覧が指定内容で置き換えられます。この場合、同梱のルート証明書の更新はその接続には反映されません。

CA ストアは「どのルート証明書を信頼するか」を決めるもので、8 つの中間 CA を拒否するブロックリストは「検証済みのチェーンを照合する」処理として別に動作します。PR の説明に従えば、ブロックリストは CA の読み込み元に関係なく、通常の証明書検証が有効な接続に適用されます。一方、ルート証明書の一覧の更新が及ぶのは同梱 CA だけです。OS ストアや追加 CA ファイルに emSign 系のルートが含まれているかどうかは、OS の更新状況や各組織の設定によって異なるため、一律に危険とも安全とも判断できません。

CA ストアの内容を調べても、ブロックリストが適用されているかどうかは判定できません。Node.js 側の eMudhra 対応は、次の観点で確認します。

• 稼働中の Node.js の系列とバージョンが、今回の修正版（またはバックポート済みの版）であること
• アプリケーションのコードや設定で、ca オプションや tls.setDefaultCACertificates() による独自の CA 設定をしていないか、している場合はその内容を把握していること
• rejectUnauthorized: false、NODE_TLS_REJECT_UNAUTHORIZED=0 など、証明書検証を無効にする設定がないこと
• 実際の通信経路で、通常の接続先に対する TLS の証明書検証が正常に機能していること

CA ストアの仕組みは公式の「Enterprise Network Configuration」と TLS モジュールのドキュメント、ブロックリストの仕組みは PR #66871 を参照してください。

自社環境での Node.js バージョン確認と更新手順

Node.js は、OS パッケージ、バージョン管理ツール、コンテナイメージ、クラウドのマネージドランタイムなど、複数の経路で導入されます。1 台のサーバーに複数のバージョンが共存することも珍しくないため、更新対象の実行環境そのもので確認することが出発点です。

実行環境ごとの確認ポイント

バージョンと組み込みコンポーネントの確認コマンド

基本の確認は node -v です。process.versions では、undici、c-ares（ares）、OpenSSL など組み込みコンポーネントのバージョンも表示されます。

node -v
node -p "process.versions"

今回の Brotli の修正は、同梱ライブラリーへの個別修正の取り込みとして記載されています。そのため、process.versions.brotli の値が更新前後で変わらない可能性があります（編集上の推論）。Brotli の修正の有無は、ライブラリーのバージョンではなく Node.js 本体のバージョンで判断してください。また、ディストリビューションのパッケージなど OpenSSL を共有ライブラリーとして使うビルドでは、openssl の値は OS 側の OpenSSL を示します。

Linux で稼働中のプロセスを確認する場合は、プロセスが実際に実行しているバイナリーを /proc から確認できます。パッケージ更新などでバイナリーが置き換えられた後も再起動していないプロセスでは、リンク先に (deleted) と表示されることがあります。

ps -C node -o pid,lstart,args
sudo ls -l /proc/<PID>/exe
sudo /proc/<PID>/exe -v

Windows では、PowerShell で稼働中の node.exe のパスと起動時刻を確認し、そのパスのバイナリーで -v を実行します。

Get-Process -Name node | Select-Object Id, StartTime, Path

nvm などを使っている環境では、which -a node（Windows では where.exe node）と nvm ls で共存しているバージョンを洗い出し、サービスの起動設定がどのパスを参照しているかを確認します。

Docker では、ホストではなく実行中のコンテナ内で確認します。

docker ps --format "[1].Names\t[2].Image"
docker exec <container> node -v

Kubernetes では、Pod ごとに指定されたイメージと、実際に取得されたイメージのダイジェスト（imageID）を確認し、代表的な Pod でバージョンを確認します。

kubectl get pods -n <namespace> -o custom-columns=POD:.metadata.name,IMAGE:.spec.containers[*].image,IMAGEID:.status.containerStatuses[*].imageID
kubectl exec -n <namespace> <pod> -- node -v

npm audit は、主に npm で導入した依存パッケージの既知の脆弱性を確認するコマンドです。Node.js 本体の脆弱性への対応が完了したことの確認には使えないため、本体のバージョン確認と分けて扱ってください。

ディストリビューションのパッケージとバックポート

Linux ディストリビューションが提供する Node.js パッケージや、クラウド事業者・商用サポートが提供するランタイムでは、公式の修正をバックポートし、公式とは異なるバージョン番号で提供する場合があります。公式の修正版と番号が一致しないことだけで、未修正と判断しないでください。この場合は、配布元のセキュリティ情報やパッケージの変更履歴で、今回の CVE 番号への対応が記載されているかを確認します。逆に、配布元が対応を公表していない場合は、修正済みとも判断できません。

更新手順

一般的な更新の流れは次のとおりです。具体的な更新コマンドは、導入元（公式バイナリー、OS パッケージ、バージョン管理ツール、コンテナイメージ）ごとの手順に従ってください。

更新後の完了確認と運用上の注意点

更新コマンドが成功したことは、対応完了の条件の一部にすぎません。稼働中のプロセスが修正版で動作し、主要な機能が正常であることまで確認して、はじめて完了と判断できます。

対応完了を判断する確認項目

1. 配布元と利用中の系列に対応する修正版（またはバックポート済みの版）を適用している
2. 対象のサービスを再起動し、コンテナや Pod を新しいイメージで再作成している
3. 稼働中のプロセスが更新後のバージョンを使用していることを、実行環境で確認している
4. HTTPS 通信、DNS の名前解決、圧縮データの処理など、主要な機能が正常に動作している
5. 更新後に、エラー率の上昇や予期しないプロセスの終了が発生していない
6. 問題が発生した場合の切り戻し手順と、その判断基準を決めている

TLS セッションの再開については、前述のとおり更新前から再開されたセッションは再検証されません。プロセスを再起動すれば通常はメモリー上のセッションが破棄されますが、外部のセッションキャッシュを共有している構成では、セッションの有効期限まで影響が残る可能性があります。

更新後に起こりうる動作の変化

今回の修正には、これまで受け入れられていた接続を拒否する方向の変更が含まれます。エラーが発生した場合は、検証を無効化して回避するのではなく、原因を確認してください。

• CERT_REVOKED の証明書エラー: 接続先のチェーンに eMudhra の 8 つの中間 CA が含まれている可能性があります。接続先の証明書の確認が必要です。
• IP アドレス表記での接続エラー: 「tls: reject non-canonical IP addresses」の修正により、非正規の IP 表記を接続先にしている設定で TLS 接続が失敗する可能性があります（修正タイトルからの推論）。設定ファイルの接続先の表記を確認してください。
• 26.x のモジュール読み込み: 26.12.1 には「module: synchronously load most ES modules」の差し戻し（Revert）が含まれます。26.x を利用している場合は、起動時の挙動も確認の対象に含めることを推奨します。

切り戻しの考え方

切り戻しに備えて、更新前のコンテナイメージのタグやダイジェスト、パッケージのバージョン、サービスの起動設定を記録しておきます。ただし、切り戻した状態は今回の脆弱性が残る状態です。切り戻しは原因調査のための一時的な措置とし、期限を決めて修正版へ戻す計画を立てることを推奨します。Brotli の展開経路がある環境では、切り戻し中に外部から受け取る圧縮データの展開を一時的に制限できないかも検討してください。

まとめ

2026 年 10 月の Node.js セキュリティリリースは、サポート中の 22.x、24.x、26.x に影響する 10 件の CVE と、eMudhra 対応を含む依存コンポーネントの更新で構成されています。対応の要点は、系列ごとの修正版を、実際に稼働しているプロセスやコンテナまで反映させることです。

• 修正版は 22.23.4、24.22.1、26.12.1 で、20.x 以前には提供されません。
• Brotli の RCE は、攻撃者が制御する圧縮データを展開する経路で優先度が上がります。
• TLS の 3 件は、主に Node.js が HTTPS クライアントとして接続する処理が対象です。
• 証明書検証が有効なら、修正版は eMudhra の中間 CA を含むチェーンを拒否します。
• OS ストアや追加 CA ファイルの内容は、Node.js の更新では変わりません。
• バージョン確認は、操作中のシェルではなく稼働中のプロセスで行います。
• npm audit の結果は、Node.js 本体の対応完了を示すものではありません。

以上、最後までお読みいただきありがとうございました。