2026年10月発表のNode.jsの脆弱性10件｜原因・影響と修正版への更新手順

2026年10月21日、Node.jsのプロジェクトは22.x・24.x・26.xの修正版（22.23.4・24.22.1・26.12.1）を、セキュリティリリースとして公開しました。公式発表の概要は次のとおりです。

The Node.js project will release new versions of the 26.x, 24.x, 22.x releases lines on or shortly after, Wednesday, October 21, 2026 in order to address security vulnerabilities. The highest severity issue fixed in this release is HIGH.

意訳

Node.jsプロジェクトは、脆弱性に対処するため、26.x・24.x・22.xの新しいバージョンを2026年10月21日（水）以降すみやかに公開します。今回のリリースで直す問題のうち、最も高い深刻度はHIGH（高）です。

Node.js公式「Wednesday, October 21, 2026 Security Releases」（2026年10月21日）

Node.jsは、サーバーでJavaScriptを動かすための実行環境です。今回の10件は、Node.js本体のモジュールと、本体に同梱しているライブラリの両方に及びます。

01.根本原因と原因のモジュール

10件の原因は1か所ではありません。修正コミットから原因の場所を並べると、Node.js本体の6つのモジュールと、同梱するBrotliの展開処理に分かれます。

このほか、同梱ライブラリ（undici・c-ares・OpenSSLなど）の更新による修正もあります。こちらは03章で扱います。

Brotliの展開処理の範囲外書き込み

Brotliは、Webの通信でよく使われる圧縮形式の1つです。Node.jsは展開処理のライブラリを本体に同梱しており、標準のzlibモジュールから使えます。公式発表は、このCVE-2026-111497を次の見出しで挙げています。

Node.js Brotli decoder out-of-bounds write permits remote code execution (CVE-2026-111497) - (high)

意訳

Node.jsのBrotliの展開処理（デコーダー）の範囲外書き込みにより、遠隔からのコードの実行が可能になる（CVE-2026-111497）。深刻度は高。

Node.js公式「Wednesday, October 21, 2026 Security Releases」の見出し（2026年10月21日）

範囲外書き込みとは、確保したメモリの外側にデータを書いてしまう欠陥のことです。遠隔からのコードの実行（RCE: Remote Code Execution）は、攻撃者が用意したプログラムを、通信を通じてサーバー上で動かされることを指します。Node.jsの修正は、Brotliの開発元であるGoogleが2026年2月に入れた変更を、同梱版へ取り込むものです。取り込んだコミットは、変更の中身を次のように記しています。

Detect and report invalid stream earlier.

意訳

不正なデータの並び（ストリーム）を、より早い段階で検出して報告する

Node.jsの修正コミット「deps: brotli: cherry-pick 0ed4268a4401abcb44720963」（元の変更の作成は2026年2月27日、Node.jsへの反映は10月20日）

修正版は、ブロックの切り替えが不正なデータを、新しいエラーコードで止めます。標準のfetchも、Brotli形式の応答をこの展開処理に渡しています（同梱のライブラリ（undici）のソース）。外部のサーバーに接続するだけのサービスも対象になります。

TLSのホスト名検証の照合の食い違い

HTTPSなどのTLS通信では、接続先が示した証明書が、接続しようとしたホスト名のものかを確かめます。CVE-2026-105483・106069・106072の3件は、このホスト名検証をIPアドレスの書き方の違いですり抜けられる問題です。修正コミットは、原因と直し方を次のように記しています。

TLS identity checks normalized non-canonical numeric hosts before matching certificates. Platform resolvers can interpret the original host as a different address. Reject hosts that become IP addresses only after domainToASCII() normalization.

意訳

TLSの身元の確認では、正規でない数値のホストを、証明書と照合する前に正規化していた。一方、OSの名前解決は、元のホストを別のアドレスとして解釈することがある。そこで、domainToASCII()で正規化して初めてIPアドレスになるホストを拒否する。

Node.jsの修正コミット「tls: reject non-canonical IP addresses」（作成は2026年9月15日、Node.jsへの反映は10月20日）

修正コミットのテストに並ぶ表記を、Node.js 22.22.0のurl.domainToASCII()で実際に変換すると、次のようになりました。

どれも、Node.jsのnet.isIP()ではIPアドレスと判定されない文字列です。修正前は、変換して初めてIPアドレスになる文字列を、IPアドレスではなくDNS名として証明書と照合していました。修正版は、こうしたホスト名をHost is a non-canonical IP addressというエラーで拒否します。

影響が出るのは、tls.connect()やhttps.request()のhostオプションに、こうした文字列がそのまま渡る場合です。fetchやURLの文字列で接続先を指定すると、URLの解析（new URL()）の段階で正規の表記に直ります。

ホスト名の扱いをめぐる修正は、6月と7月のセキュリティリリースでも続いていました。同じ領域の修正を並べると次のとおりです。

利用者が入力したURLへ接続する機能（Webhookの送信先や、指定したURLの画像の取得など）は、表記の違いを突いた攻撃の対象になりやすい機能です。受け取ったURLをnew URL()で解析し、正規化されたhostnameを使えば、表記の違いによる食い違いは避けられます。旧来のurl.parse()は127.1などを正規化しないまま返すため、置き換えをおすすめします。

ただし、正規化はサーバー側リクエスト偽造（SSRF）への対策の一部にすぎません。OWASPのSSRF対策ガイドは、名前解決した接続先のIPアドレスを許可した範囲と照らし合わせることや、リダイレクトに自動で従わないことも求めています。

DNSの問い合わせとkeep-alive接続の原因

dns.resolveやdns.resolve4などの関数は、名前をC言語の文字列として下位のライブラリ（c-ares）に渡します。C言語の文字列はNUL文字で終わるため、名前の途中にNUL文字があると、それ以降がエラーにならずに切り捨てられていました（CVE-2026-105482）。アプリが確かめた名前と、実際に問い合わせる名前が食い違うおそれがあります。

修正版は、NUL文字を含む名前をERR_INVALID_ARG_VALUEのエラーとして受け付けません（修正コミット）。

fetchやhttpモジュールの名前解決はdns.lookup()を使うため、この件の対象はdns.resolveなどを直接呼ぶコードです。dns.lookup()側のNUL文字は、6月のCVE-2026-48930ですでに修正されています。

http.Agentは、使い終えた接続を閉じずに保持し、次のリクエストで使い回します（keep-alive）。標準のhttp.globalAgentは、v19.0.0から既定でkeep-aliveが有効です（公式ドキュメント）。

保持している接続に先にデータが届いたら、その接続を破棄する仕組みは、6月のCVE-2026-48931の修正ですでに入っていました。ただしこの仕組みは、イベントループが入出力を確かめるときにしか動きません。その前にOSへ届いたデータは見逃され、次のリクエストへの応答として扱われていました（CVE-2026-105481）。

修正版は、接続を使い回す直前に、未読のデータが届いているかをOSに問い合わせます。届いていれば、その接続を破棄して別の接続を使います（修正コミット）。

乱数・ZIP・権限モデルの原因

crypto.randomUUID()とcrypto.randomInt()は、速さのために乱数をまとめて作り、キャッシュしておきます。起動スナップショット（--build-snapshot）を作ると、このキャッシュがそのまま保存されていました（CVE-2026-106074）。

単一実行ファイル（SEA: Single Executable Applications）も、設定のuseSnapshotをtrueにして作った場合は同じです（既定はfalse）。同じファイルから起動したプロセスは、起動直後に同じUUIDや乱数を出していたことになります。修正は、スナップショットをまたいで乱数のキャッシュを消す処理を組み込むものです（24.22.1のリリースノートの「crypto: reset random caches across snapshots」）。

26.xは、v26.8.0でZIPファイルを読み書きするAPI（zlib.ZipFileなど）を追加しました。zlibのドキュメントでの安定度は1.0（Early development：開発の初期段階）です。

このAPIでは、ファイルの中身を読む前の整合性の確認に失敗しても、確認前の情報がキャッシュに残っていました。そのあとの読み込みが、攻撃者の用意したバイト列を返すおそれがありました（CVE-2026-106070、修正コミット）。

権限モデルは、ファイルやネットワークへのアクセスを、許可したものだけに絞る機能です。起動時に--permissionを付けると有効になります。

CVE-2026-106071（26.xのみ）は、ワイルドカード（*）を使った許可が意図より広く効き、許可したつもりの無いパスまで読めていた問題です（修正コミット）。

CVE-2026-106073は、fs.realpathSyncが権限の確認を通らず、許可していない場所のファイルの有無を調べられた問題です（修正コミット）。

02.想定される被害と悪用状況

どれほど危険かを、公式発表とアドバイザリの評価の段階で示すと、次のとおりです。

情報を抜かれる攻撃の流れ

深刻度「高」の2つの原因を、攻撃者とサーバーのやり取りとして単純化すると、次のようになります。

流れ1は、Brotliの範囲外書き込み（CVE-2026-111497）です。公式発表は、この欠陥でコードの実行が可能になると見出しに書いています（01章）。流れ2は、TLSのホスト名検証の3件で、修正コミットが説明する確かめた相手と実際の接続先の食い違いから、起こりうる被害を示しました。

攻撃に使う通信の細かな中身は、再現に使えてしまうため書きません。どちらの流れも、修正版に上げれば成り立たなくなります。

悪用状況とCVEの公開時期

公式発表は、実際に悪用された事例には触れていません。米国のサイバーセキュリティ・社会基盤安全保障庁（CISA）は、悪用が確認された脆弱性のカタログ（KEV）を公開しています。10月21日版の時点で、このカタログにもNode.js本体の項目はありません。

2026年10月22日の確認時点では、CVEの公的なデータベース（CVE.org・NVD）にこれらの番号の詳細はまだ登録されていません。Node.jsのセキュリティポリシーは、その理由を次のように説明しています。

As a result, CVEs may not be immediately available when security releases are published, but will typically be disclosed within a few days of the release.

意訳

そのため、セキュリティリリースの公開時点ではCVEをすぐには参照できないことがありますが、通常はリリースから数日以内に公開されます。

Node.js「Security（CVE publication timeline）」

修正内容はコミットとして公開されており、攻撃の手がかりを誰でも読める状態です。公式発表にもKEVにも悪用の記載が無い今のうちに、更新を進めてください。

03.影響を受ける範囲

バージョン別の対象と修正版

使っているメジャーバージョンごとの更新先は、次のとおりです。表の件数は、そのバージョンに影響する脆弱性の数です。

OSのパッケージ（aptなど）で入れたNode.jsは、修正を取り込んでも番号が修正版と同じになるとは限りません。確かめ方は04章で説明します。サポートが終わったバージョンについて、Node.jsのサポート終了の説明ページは次のように明記しています。

When new security releases reveal issues and patches in newer major lines, even if the same vulnerability affects EOL release lines, there will not be any new releases for them. Users still clinging on to EOL release lines and using affected code paths will be immediately vulnerable to attacks exploiting these disclosed vulnerabilities.

意訳

新しいメジャーバージョンのセキュリティリリースで問題と修正が明らかになったとき、同じ脆弱性がサポート終了のバージョンに影響していても、そのバージョンの新しいリリースは出ません。サポート終了のバージョンを使い続け、影響を受けるコードを通している利用者は、公表された脆弱性を突く攻撃にすぐにさらされます。

Node.js公式「End-Of-Life」

修正された10件の一覧です。CVE番号は、脆弱性ごとに振られる共通の識別番号です。

サポート期限とリリース体制の変更

長期サポート版（LTS: Long Term Support）は、セキュリティ修正を長く受け取れるバージョンです。各バージョンの期限は、Node.jsのリリーススケジュール（schedule.json）のとおりです。

Node.jsは2026年3月、27.xからメジャーバージョンのリリースを年1回（4月）に減らし、すべてのメジャーバージョンを長期サポート版にすると発表しました。奇数バージョンと偶数バージョンの区別はなくなり、毎年10月からの半年間は、アルファ版で互換性を壊す変更を先に試せるようになります。22.xは残り半年でサポートが終わるため、24.xか26.xへ移る計画を早めに立てておくと安心です。

使い方別の影響

今回の修正は対象のAPIが広く、外部と通信するNode.jsのサービスはほぼ当てはまります。次の表で、自社の使い方に当てはまる行から確認してください。

どの行にも当てはまらない場合も、更新は必要です。サポート中のバージョンの修正版に上げれば、今回の10件はまとめて解消します。ただし、起動スナップショットとSEAは修正版で作り直す必要があります。

同梱ライブラリ経由の影響

Node.jsは、HTTPクライアントや名前解決、暗号の処理に外部のライブラリを同梱しています。今回は次のライブラリが更新されました。

c-aresの修正内容は1.34.9のリリースノートに、OpenSSLの修正内容はOpenSSL 3.5系の脆弱性一覧にまとまっています。どのライブラリがどのバージョンで更新されたかは、22.23.4・24.22.1・26.12.1の各リリースノートで確かめられます。

標準のfetchとWebSocketは、同梱のundiciで動いています（Node.js本体のソース）。そのため、undiciの修正はNode.jsを更新すれば反映されます。undiciのセキュリティアドバイザリのうち、今回の同梱版で修正されたものは次のとおりです（括弧内はCVSSのスコア）。

Agentやインターセプターに関わる項目は、主にnpmでundiciを入れ、そのAPIを直接使う場合に関係します。npmで入れたundiciを更新する手順は05章で扱います。

eMudhraの中間証明書の侵害への対応

認証局eMudhra（emSign）が運用する中間証明書8枚で、秘密鍵を第三者が簡単に割り出せる状態だったことが、2026年10月17日に報告されました（Mozillaのインシデント記録）。8枚のうち6枚はTLS用で、Chrome・Mozilla・Microsoft・Appleの各ルートプログラムで信頼されていました。

同じ記録へのeMudhraの書き込みによると、同社は8枚を失効させました。対象の中間証明書から、サイト向けの証明書は発行していないとも説明しています。そのため、このあと説明するブロックリストの主な役割は、漏れた鍵で偽の証明書を作られた場合の防御です。Node.jsの修正コミットは、対応の理由を次のように記しています。

Node.js embeds the Mozilla root store but has no equivalent of the browsers' CRLSet/OneCRL and no default online revocation checking, so a certificate chain through a compromised intermediate still verifies as long as it reaches a trusted root.

意訳

Node.jsはMozillaのルート証明書一覧を組み込んでいるが、ブラウザのCRLSetやOneCRLに当たる仕組みはなく、既定ではオンラインで失効を確かめることもしない。そのため、侵害された中間証明書を経由する証明書チェーンでも、信頼するルートまでたどれれば検証を通ってしまう。

Node.jsの修正コミット「tls: reject chains containing blocked public keys」（2026年10月20日）

そこで今回の修正では、対象8枚の公開鍵を載せたブロックリストをNode.js本体に組み込みました。検証済みの証明書チェーンにこれらの鍵が含まれていれば、失効扱いで拒否します。

修正コミットの説明によると、同じリストはGo（CVE-2026-111943）とElectronも採用しています。公開鍵で照合するので、別の認証局がクロス署名した同じ鍵の証明書も拒否されます。

04.Node.jsのバージョンの確認方法

まず、動いているNode.jsのバージョンと、同梱ライブラリのバージョンを確かめます。

# Node.js本体のバージョン
node -v

# 同梱ライブラリのバージョン（undici・ares・opensslなど）
node -p process.versions

# npmで入れたundiciが依存関係のどこにあるか
npm ls undici

node -vの結果が修正版より前なら、更新の対象です。process.versionsのundici・ares・opensslを見れば、同梱ライブラリが新しくなったかも確かめられます。

OSのパッケージ（aptなど）で入れたNode.jsは、番号だけで判断しないでください。Debianは、セキュリティのFAQで、新しい上流のバージョンへ上げる代わりに、安定版に収録したバージョンへ修正を移植すると説明しています。修正済みかどうかは、パッケージの変更履歴（changelog）や、ディストリビューションのセキュリティ情報で確かめます。

05.実行環境別の更新手順

修正版への上げ方は、Node.jsをどう入れているかで変わります。

手元の開発環境とサーバー

バージョン管理ツールを使っている場合は、修正版を入れてから、プロジェクトで指定しているバージョンを書き換えます。

# nvm
nvm install 24.22.1
nvm alias default 24.22.1

# mise（カレントディレクトリの mise.toml に書き込む）
mise use node@24.22.1

.nvmrc・.node-version・package.jsonのengines・CIの設定ファイルにバージョンを固定している場合は、それらも修正版に書き換えます。OSのパッケージで入れている場合は、ディストリビューションが修正済みパッケージを出しているかを確かめてから更新します。

Node.jsのバージョンをプロジェクトごとに固定して切り替える方法は、別記事で詳しく整理しています。あわせてご覧ください。

Dockerのイメージ

Docker Hubの公式のnodeイメージには、22.23.4・24.22.1・26.12.1のタグが10月21日に公開されています。FROM node:24.22.1-slimのようにバージョンまで書いておくと、どのバージョンで動いているかが明確になります。

node:24のようにメジャーバージョンだけを指定したタグでは、手元に残った古いイメージがそのまま使われることがあります。最新のイメージを取得し直してビルドし、デプロイまで済ませてください。

docker build --pull -t my-app .

AWS Lambdaのランタイム

Lambdaが管理するランタイム（nodejs24.xなど）について、AWSのドキュメントは次のように説明しています。

By default, for functions using managed runtimes, Lambda applies runtime updates automatically.

意訳

管理されたランタイムを使う関数では、Lambdaは既定でランタイムの更新を自動で適用します。

AWS「Understanding how Lambda manages runtime version updates」

反映の時期はAWSが決め、段階的に適用されます。Function updateモードでは関数を更新したとき、Manualモードでは手動で指定したときに、はじめて新しいランタイムへ切り替わります。

コンテナイメージで動かしている関数は、更新されたベースイメージから作り直してデプロイする必要があります。関数の中でprocess.versionをログに出しておくと、実際に動いているNode.jsのバージョンを確かめられます。

npmで入れたundici

undiciをnpmの依存関係に入れている場合は、Node.jsの更新とは別に上げる必要があります。04章のnpm ls undiciで、直接の依存か間接的な依存かを確かめてから更新します。

npm install undici@^8.12.2

修正版は6.29.1・7.30.1・8.12.2以降です。間接的な依存だけの場合は、それを使っているパッケージの更新を待つか、package.jsonのoverridesで修正版を指定します。

更新で変わる挙動

修正版に上げると、これまで通っていた処理がエラーになる場合があります。更新の前後で、次の4つの変更に当たらないかを確かめてください。

削除されたのは、emSign ECC Root CA - G3・emSign Root CA - C1・emSign ECC Root CA - C3の3つです（更新のコミット）。

このほか26.12.1には、脆弱性の修正ではない変更の取り消しも1件含まれます。10月14日の26.12.0で入ったES Modulesの読み込み方の変更が取り消され、26.11以前と同じ挙動に戻りました（取り消しのコミット）。

CVE番号は付いていませんが、24.xと26.xには、JavaScriptエンジンV8の修正も取り込まれています。JSON.parseで、エスケープを含むキーが後続の解析結果のキーを壊すおそれがあった不具合です（修正コミット）。

06.開発形態別の追加の対応

Node.js本体の更新は、どの作り方でも必要です。そのうえで、作り方ごとに足す確認は次のとおりです。

フルスクラッチで開発したアプリ

http・tls・dnsなどの標準モジュールを直接使っている場合は、03章の使い方別の表で、とくに次の3点を点検します。

• 利用者の入力を、tls.connect()やhttps.request()のhostにそのまま渡していないか
• 旧来のurl.parse()で取り出したホスト名を、接続先に使っていないか
• 外部から受け取った名前を、dns.resolveなどで直接問い合わせていないか

フレームワークで作ったアプリ

ExpressやNext.jsなどのフレームワークも、Node.jsの上で動きます。TLS・DNS・HTTP・展開処理の修正は、フレームワークではなくNode.js本体の更新で反映されます。

フレームワークやその周辺のパッケージが、npmでundiciを入れていることもあります。04章のnpm ls undiciで依存関係を確かめ、入っていれば修正版へ上げてください。フレームワーク自体のセキュリティ更新は、それぞれの配布元の告知で確認します。

Electronのアプリと単一実行ファイル

Electronは、公式ドキュメントのとおり、ChromiumとNode.jsをバイナリに組み込んで動きます。サーバーのNode.jsを更新しても、配布したElectronのアプリには反映されません。Electron自体の更新情報を確かめ、修正を取り込んだバージョンでアプリを作り直します。

単一実行ファイル（SEA）も、作ったときのNode.jsを内部に持ちます。修正版のNode.jsで作り直して、配り直してください。

07.発見の経緯とタイムライン

今回の修正にかかわる主な出来事を、日付の順に並べると次のとおりです。

修正コミットの多くには、報告を受け付けたHackerOneのページへのリンクが記されています（例：IPアドレスの正規化の修正コミット）。Node.jsのセキュリティポリシーは、修正を公開まで表に出さない手順を次のように定めています。

Fixes are prepared for all supported releases. These fixes are not committed to the public repository but rather held locally pending the announcement.

意訳

修正はサポート中のすべてのリリースに向けて準備します。これらの修正は公開のリポジトリにはコミットせず、公表まで手元で保持します。

Node.js「Security（Disclosure policy）」

修正コミットの一部には、AIツールの支援を受けたことを示す「Assisted-by」の行があり、ツールの名前が記されています。たとえば乱数のキャッシュの修正コミットには「Assisted-by: Codex」とあります。脆弱性の修正の作業にも、AIツールが使われていることが分かります。

08.よくある質問（FAQ）

09.まとめ

2026年10月21日のセキュリティリリースでは、Brotliの展開、TLSのホスト名検証、DNS、keep-aliveの接続など、外部との通信に関わる部分がまとめて修正されました。22.23.4・24.22.1・26.12.1以降か、OSの修正済みパッケージへ上げたうえで、Dockerのイメージ、Lambdaのランタイム、npmで入れたundiciの更新も確かめてください。

依存関係やランタイムの更新は、後回しにするほど一度に上げる幅が大きくなり、確認の手間も増えます。弊社では、AIをフル活用したWeb制作・運用の中で、こうした更新を継続して回す仕組みづくりのご相談も承っています。