Node.js 20.20.0/22.22.0/24.13.0/25.3.0 セキュリティリリース｜全8CVEと4度の延期の記録

2026年1月13日に公開されたNode.jsのセキュリティリリースは、当初予定の2025年12月15日から4度日付が動いた末の公開でした。修正はNode.js 20.x/22.x/24.x/25.xの4ラインへ配られ、告知に並んだCVEはHigh 3件・Medium 4件・Low 1件の計8件です。ただし8件がそのまま4つの修正版に入ったわけではなく、公開の2日後には1件の影響範囲が書き換えられています。この記事は、その1回のリリースに何が入っていたのかと、配られた4つのバージョンが2026年10月2日時点でどうなっているのかを、公式告知の本文と各リリースノート、nodejs.orgリポジトリのコミット履歴から整理したものです。Node.jsの脆弱性そのものの調べ方や、自分の環境が影響を受けるかの確認手順はNode.jsの脆弱性とは｜影響の確認方法と対応バージョン・アップデート手順を参照してください。

まとめ：2026年1月13日リリースの要点

• 公開日：2026年1月13日（火）。当初の告知は2025年12月8日で、予定日は2025年12月15日（月）でした。以後4回変更されています。
• 修正版：Node.js 20.20.0、22.22.0、24.13.0、25.3.0。依存ライブラリはc-aresが4版とも1.34.6へ、undiciは20.20.0と22.22.0が6.23.0、24.13.0と25.3.0が7.18.2へ上がりました。
• 件数：告知に並んだCVEはHigh 3件・Medium 4件・Low 1件の計8件。12月8日の事前告知ではHigh 3件・Medium 1件・Low 1件の計5件と書かれており、延期の間に対象が増えています。
• 4版すべてに入ったのは6件：CVE-2025-59464は24.12.0で修正済みのため4版のどれにも入らず、CVE-2026-21636は25.3.0だけに入っています。
• 1月の修正には続きがある：CVE-2026-21637の修正は不完全で、2026年3月24日に同じ番号のHigh（SNICallbackの例外でプロセスが落ちる）として再修正されました。1月の版で止まっている環境は、この再修正を受けていません。
• 2026年10月2日時点の注意：20.xは2026年4月30日、25.xは2026年6月1日でサポートが終了しました。この2ラインはEOLのため、以後の修正が出ません。稼働中なら24.x（2026年10月20日からMaintenance LTS）か22.x（Maintenance LTS）へ移してください。26.xは10月28日にLTSへ入る予定です。判断材料は脆弱性の影響確認とアップデート手順の記事にまとめています。

修正された8件のCVEと公式告知の深刻度・リリースノート収録状況

公式告知のページ（nodejs.orgの脆弱性ブログにある Tuesday, January 13, 2026 Security Releases）は8件を深刻度順に並べ、それぞれに影響範囲と報告者・修正者を明記しています。深刻度はNode.js側が付けたもので、CVSSの基本値がそのまま載っているわけではありません。NVDが独自に付けたCVSS 3.1は告知より高いものがあり、CVE-2026-21636は10.0、CVE-2025-55130は9.1と評価されています。8件とも、2026年10月1日版のCISA KEV（悪用が確認された脆弱性の一覧）には載っていません。スコアの読み方はCVSSの深刻度スコアの見方を参照してください。下の表の右端は、各CVEが1月13日の4つのリリースノートに実際に載っているかを数えた結果です。

High 3件の異なる影響と発生条件：情報漏洩・権限回避・DoS

CVE-2025-55131は、vmモジュールをtimeoutオプション付きで使っているときに割り込みが起きると、Buffer.allocやUint8Arrayが前の処理の残留データを含んだまま返るというものです。公式はこれをトークンやパスワードのようなプロセス内の秘密情報の漏洩、あるいはデータ破壊につながると説明しています。攻撃には精密なタイミングかプロセス内でのコード実行が必要ですが、信頼できない入力が処理量やタイムアウト値に影響を与える構成ではリモートから成立しうる、という条件付きの評価です。報告と修正はいずれもNikita Skovorodaによるものでした。

CVE-2025-55130は権限モデルの穴です。相対パスのシンボリックリンクを組み合わせると、--allow-fs-readと--allow-fs-writeで許可したディレクトリの外へ出られます。カレントディレクトリだけを許可して起動したスクリプトが、ディレクトリとリンクを連鎖させて許可範囲を脱出し、任意のファイルを読み書きできる状態でした。--permissionを使っていない環境には関係がなく、権限制限に依存する処理を持つ環境では影響確認が必要です。ただし権限モデルは、もともと悪意あるコードを隔離する境界としては保証されていません。

CVE-2025-59465はHTTP/2サーバーのリモートDoSです。過大で不正なHPACKデータを持つHEADERSフレームを送ると、TLSSocketのECONNRESETが未処理エラーとして扱われ、接続を安全に閉じる代わりにプロセスが落ちます。公式告知は、セキュアソケットに明示的なエラーハンドラを付けていないアプリケーションが主な対象だとして、次のエラーハンドラの登録例を示しています。serverが指すのは、作成済みのTLS対応サーバーです。この断片は脆弱性の再現コードではなく、修正版への更新を代替するものでもありません。

server.on('secureConnection', socket => {
  socket.on('error', err => {
    console.log(err);
  });
});

Medium・Lowの5件の発生条件と利用機能ごとに異なる影響

Medium帯で実務への影響が大きいのはCVE-2025-59466です。async_hooks.createHook()が有効なとき、Maximum call stack size exceededが捕捉できなくなり、process.on('uncaughtException')に届かないままプロセスが終了します。22.xと20.xではAsyncLocalStorageに依存しているだけで対象になるため、リクエストコンテキストの伝搬に使っている構成は広く当たります。ここで見落とせないのは、公式が「このパッチは1つのエッジケースでの回復性を改善するだけで、より広いリスクを取り除くものではない」と明記している点です。スタック枯渇からの回復は仕様として保証されない最善努力の動作であり、可用性が要求される経路では再帰の深さを入力で決めない設計に寄せるべきだ、というのが告知の立場でした。パッチを当てて終わりにせず、再帰の境界を設計側で持つ必要があります。

CVE-2025-59464はOpenSSL連携のメモリリークで、socket.getPeerCertificate(true)を呼ぶとX.509証明書のフィールドをUTF-8へ変換したバッファが解放されません。TLS接続を繰り返すだけでメモリが増え続けるため、クライアント証明書を検証するサーバーがリモートDoSの標的になります。CVE-2026-21636は--permission有効時にUnix Domain Socket経由の接続が--allow-netの制限を受けないという問題で、URLやsocketPathを攻撃者が指定できると、ローカルの特権サービスへ到達される状態です。告知はこの時点でネットワーク権限が実験的段階にあることも併記しています。CVE-2026-21637はpskCallbackやALPNCallbackが同期例外を投げたときにtlsClientErrorとerrorの経路を迂回し、即時終了かファイルディスクリプタの静かなリークを起こすものです。これらのコールバックはTLSハンドシェイク中に攻撃者の入力を処理するため、繰り返し踏ませることができます。

Lowの1件はCVE-2025-55132で、fs.futimes()が読み取り権限しかない状態でもファイルのアクセス時刻と更新時刻を書き換えられるというものです。utimes()と違い書き込み権限のチェックが通らないため、読み取り専用ディレクトリでメタデータだけが変えられます。直接の被害は小さいものの、公式はタイムスタンプの改変によって活動の痕跡が曖昧になり、ログの信頼性が落ちる点を挙げています。

告知とリリースノートで食い違うundiciの搭載版と依存台帳への記録

依存ライブラリの版は、告知とリリースノートを突き合わせると数字がずれます。告知の冒頭は依存更新を「c-ares (1.34.6) と undici (6.23.0, 7.18.0)」と書いていますが、実際のリリースノートを見ると、20.20.0と22.22.0はundici 6.23.0、24.13.0と25.3.0はundici 7.18.2です。7.18.0は告知の記述で、搭載されたのは7.18.2でした。c-aresは4版とも1.34.6で一致します。SBOMや依存台帳に数字を転記するときは、告知の要約ではなく各リリースノートの記述を採ってください。

8件のCVEのライン別影響範囲と利用条件・修正済みバージョンの確認

リリース対象のラインと、各CVEの影響条件は分けて確認する必要があります。告知の冒頭に「25.x、24.x、22.x、20.xのリリースラインに更新が提供されました」と書かれているため、4ラインすべてが8件すべてを抱えていたように読めますが、実際は違います。1月13日の4つのリリースノートで各CVE番号を数えると、4版すべてに載っているのは6件です。

残る2件はライン固有です。CVE-2025-59464は24.x限定で、しかも告知本文が「この脆弱性はNode.js v24.12.0ですでに修正されています。他のアクティブなリリースラインには影響しません」と述べており、1月の4つのリリースノートにはどれにも載っていません。24.12.0以降を使っていれば、この1件だけを理由とする24.13.0への更新は不要です。CVE-2026-21636は25.3.0のリリースノートにだけ現れ、20.x/22.x/24.xの利用者には関係しません。

逆に注意したいのがCVE-2026-21637です。告知のImpact欄だけはライン番号ではなく条件で書かれており、PSKまたはALPNのコールバックを安全にラップせずに使っているTLSサーバーが対象だとされています。しかし修正自体は4版すべてに収録されています。該当コールバックを使っていない場合も、ほかのCVEへの該当状況を確認して更新の優先度を決めてください。棚卸しではライン番号に加え、修正済みの版と該当機能の利用有無を確認する必要があります。

このCVE-2026-21637には続きがあります。2026年3月24日のセキュリティリリースは「CVE-2026-21637の不完全な修正」を同じ番号のHighとして扱いました。1月に手当てされたのはPSKとALPNのコールバックだけで、SNICallbackが想定外のサーバー名で同期例外を投げると、TLSのエラー処理を素通りしてプロセスが落ちる状態が残っていたためです。対象は1月の修正を受けた20.x・22.x・24.x・25.xのすべてで、修正版は20.20.2、22.22.2、24.14.1、25.8.2でした。CVE-2026-21636にも同様の続報があり、2026年6月のリリースで「不完全な修正」がCVE-2026-48936（Low、26.xのみ）として直っています。1月の4版を「対応済み」と記録した台帳は、ここで書き換えが必要です。

公開2日後に書き換えられたCVE-2025-59464の影響範囲

先ほどの「24.x限定」という記述は、公開時点のものではありません。nodejs.orgリポジトリの履歴をたどると、2026年1月15日のコミット7a949e8（Blog: change impact for CVE-2025-59464）で、この1件のImpact欄が差し替えられています。公開当日の本文は「アクティブなリリースラインの全利用者に影響します：20.x、22.x、24.x」でした。それが2日後に「v24.12.0ですでに修正済み。他のアクティブラインに影響なし」へ変わり、「この公開CVEは影響を受けるv24リリースに対してのみ発行されています」という一文が足されています。さらに1月19日のコミット46e0f2bでは、本文内の版表記の揺れが揃えられました。

実務上の意味ははっきりしています。公開当日にこの告知を読んで20.xと22.xの対応計画を立てた担当者は、2日後に前提が1件分ひっくり返っていたことになります。セキュリティ告知は公開後に訂正されるものだという前提で運用を組むべきで、公開直後のスクリーンショットや、それを引き写した二次記事の要約を根拠に棚卸しを確定させるのは避けたほうが安全です。判断を残す必要があるなら、告知ページの本文を再読するか、nodejs.orgリポジトリの該当ファイルの履歴を引いて、どの時点の記述に基づいて決めたのかを記録しておくことをおすすめします。

2025年12月8日の告知から4度動いた公開日と延期理由の変遷

このリリースでは、事前告知から公開までに予定日が4回変更されました。Node.jsのセキュリティリリース手順は、予定日の1週間前に事前告知を出すと定めています。実際、事前告知は2025年12月8日のコミットa815445で出され、当初予定の12月15日のちょうど7日前でした。告知ページは1つのURLを使い回して更新セクションを積み上げる運用だったため、どの時点で何が理由だったのかがリポジトリの履歴にそのまま残っています。スラッグが december-2025-security-releases のままタイトルだけが Tuesday, January 13, 2026 Security Releases になっているのは、その名残です。

休暇シーズンが理由になった2回目の延期と利用者の更新対応への配慮

1回目の延期理由は「チームは依然として難易度の高いパッチに取り組んでおり、そのためリリースを12月18日かその直後へ延期する」という短いものでした。2回目はこれと質が違います。12月17日の更新では1月7日への延期が告げられ、その3日後の12月20日のコミット9f38df8で文面自体が書き直されています。差し替え後の理由はこうです。年末は多くの下流プロジェクトと利用者が休暇に入っており、セキュリティリリースはパッチが出ると同時に修正対象の脆弱性を開示する。だから、大半の利用者が休暇から戻っていて、自分が影響を受けるかを評価し、時間的猶予のないアップグレードを実施できる状態で出したい、というものです。

書き直し前の文面は「チームが十分に準備する時間を確保するため。休暇シーズンをセキュリティリリースで乱したくもない」でした。前者は開発側の都合、後者は利用者側の対応能力を理由にしています。同じ延期でも説明の軸を入れ替えた形で、セキュリティリリースを年末年始に出さないという運用判断の根拠としては、後者のほうが引用しやすい記述です。

CIの不具合とCITGM再実行が挙げられた最後の2回の延期理由

年が明けてからの2回はどちらも技術的な理由でした。1月7日の更新は「Node.jsのテストCIの複雑な問題により、リリースを1月8日（木）へ延期する」という1文だけです。翌1月8日の更新で日程はさらに1月13日（火）へ移り、理由は「すべてのバックポートを適切にテストし、CITGMを再実行して最高の品質を確保するため」と説明されました。

CITGMはCanary in the Goldmineの略で、npmから任意のモジュールを取得し、特定のNode.jsランタイムで実際にテストを走らせるツールです。Node.jsプロジェクトはこれをリリースと影響の大きい変更のスモークテストに使っています。今回は20.x/22.x/24.x/25.xの各ラインへ対象となる修正を提供するため、ラインごとの検証が必要でした。告知は追加の検証時間を確保すると説明していますが、1月8日から13日までの実作業の内訳までは公表していません。この告知から確認できるのは、バックポートのテストとCITGMの再実行が延期理由に挙げられたことです。

金曜ではなく火曜を選んだ理由とアジア太平洋地域の業務時間への配慮

1月8日の更新にはもう1つ、日程選択の説明が添えられていました。金曜ではなく火曜にリリースすることで、すべてのタイムゾーンで通常の業務時間内にセキュリティ更新が利用可能になる、特にアジア太平洋地域の利用者にとってそうである、という趣旨です。日本の運用担当者にとっても週末直前の対応を避けやすくする意図ですが、日本時間の業務時間内に公開されることを保証する説明ではありません。金曜夜の公開を避けるという判断を、リリース元が延期の告知に理由として書き残している点は、自社のリリース運用を決めるときの参考になります。

1月に配られた4バージョンの現在地と移行先（2026年10月2日時点）

ここから先は、当時の告知には書かれていない内容です。1月13日に配られた4つのバージョンのうち2つは、すでにサポートが終わっています。移行先の判断に必要なので、1月時点では存在しなかった26.xも表に含めました。状態とEOL日はnodejs/Releaseのschedule.json、各ラインの版と日付はnodejs.orgの配布一覧（dist/index.json）を2026年10月2日に取得したものです。

20.x・25.xのサポート終了と修正提供を受けるための別ラインへの移行

20.xは2026年4月30日、25.xは2026年6月1日でサポートが終了しました。同じライン内の後続版は存在し、20.xは3月24日の20.20.2、25.xは3月31日の25.9.0が最後です。ただし両ラインともEOLに達しているため、これ以上の修正は出ません。1月のセキュリティリリースで20.20.0や25.3.0へ上げてそのまま止まっている環境は、3月24日以降に公開された修正を受け取っていないうえ、上げ先も同じラインには残っていません。25.xが短命だったのは事故ではなく仕様で、奇数番号のリリースラインはLTSへ移行しないと公式が定めています。

この点について、今回の告知自体が先回りして書いています。セキュリティリリースが発生したとき、End-of-Lifeのバージョンは常に影響を受けるものとして注意するよう促す記述です。個別CVEへの影響が未確認でも、公式の修正提供を期待できないサポート外の環境として扱う必要があります。棚卸しでは、20.xや25.xのラインを「1月のパッチ適用済み」と記録するのではなく、サポート外として別枠に出すほうが実態に合った分類です。移行先のバージョンを手元で切り替えて試すならNodebrewでのバージョン管理と切り替えが使えます。

22.22.0と24.13.0のその後と、1月以降の3回のセキュリティリリース

1月13日以降、Node.jsのセキュリティリリースは2026年3月24日、6月18日、7月29日の3回公開されています。直近の7月29日分はHigh 3件・Medium 5件・Low 3件の計11件で、26.5.1、24.18.1、22.23.2が出ました。HTTP/2のmaxSessionMemory回避やuse-after-free、権限モデルのパスマッチングの過剰許可などが含まれており、1月に修正されたHTTP/2と権限モデルの周辺が引き続き手当てされていることが分かります。

2026年10月2日時点の各ラインの直近版は、Currentの26.10.0（9月21日）、Active LTSの24.21.0（9月7日）、Maintenance LTSの22.23.3（9月23日）です。22.23.3と26.10.0はセキュリティ修正を含まない通常のリリースで、配布一覧の security 欄は false でした。新規に版を選ぶなら24.xが素直な選択です。ただし24.xも2026年10月20日にMaintenance LTSへ移り、以後は重大なバグ修正とセキュリティ修正だけになります。22.xは2025年10月21日からMaintenance LTSに移行しているため、依存製品の対応などで24.xを選べない既存環境の継続先として検討できます。26.xは2026年10月28日にLTS入りが予定されているので、切り替え時期を決める際の起点はこの予定日です。26系で何が変わったかはNode.js 26の新機能・変更点とLTSスケジュールにまとめています。セキュリティリリースはこのとおり数か月おきに出るので、最新の公開状況はnodejs.orgの脆弱性ブログで確認してください。

数か月おきのセキュリティリリースに、ラインの移行（20.xから24.x、22.xから24.xや26.x）まで重なると、社内の手だけでは検証が追いつかないことがあります。一創の保守運用・内製化支援では、Node.jsのランタイム更新と依存関係の定期更新を、検証手順ごと引き受けています。

Node.jsの修正版・サポート終了と公開延期に関するよくある質問（FAQ）

Node.js 20.20.0を使っていれば今も安全ですか？

いいえ。20.20.0は2026年1月13日時点の修正版であり、その後3月24日に20.20.2が出たあと、20.xは2026年4月30日でサポートが終了しました。6月18日と7月29日のセキュリティリリースの修正は20.xへは配られていません。24.xまたは22.xへ移行してください。

Node.js 22.22.0と24.13.0は今も最新ですか？

いいえ。2026年10月2日時点の直近版は22.23.3（2026年9月23日）と24.21.0（2026年9月7日）です。22.22.0と24.13.0は1月13日のセキュリティリリースで出たバージョンで、3月にはCVE-2026-21637の再修正を含む22.22.2と24.14.1が出ています。その後もそれぞれ複数回更新されています。

Node.js 20と25のEOLはいつでしたか？

20.x（Iron）は2026年4月30日、25.xは2026年6月1日です。nodejs/Releaseリポジトリの schedule.json に記載されている日付で、22.x（Jod）は2027年4月30日、24.x（Krypton）は2028年4月30日が予定されています。

CITGMとは何で、なぜ延期の理由になったのですか？

CITGMはCanary in the Goldmineの略で、npmから任意のモジュールを取得して特定のNode.jsランタイムでテストを実行するツールです。Node.jsプロジェクトはリリースのスモークテストに使っています。1月のリリースでは、対象となる修正の検証とCITGMの再実行のため、1月8日の告知で公開予定が13日に延期されました。

1月13日のリリース以降、セキュリティリリースは出ていますか？

2026年3月24日、6月18日、7月29日の3回公開されています。7月29日分は計11件を修正し、26.5.1、24.18.1、22.23.2がリリースされました。

関連記事

• Node.jsの脆弱性とは｜影響の確認方法と対応バージョン・アップデート手順【2026年6月最新】
• Node.js 26の新機能・変更点とLTSスケジュール総まとめ
• CVSSとは？脆弱性の深刻度スコアの見方・計算方法とv4.0の変更点を解説
• Snykとは？CLIでの脆弱性スキャンとCI組み込み・料金の実額を実装視点で解説