Node.jsプロジェクトは2026年11月11日、22.23.5、24.22.3、26.13.1 のセキュリティ更新を公開しました。Web通信の処理でサーバーが停止したり、メモリー内の情報が読み取られたりする問題などを修正しています。最高深刻度は「High」です。公式セキュリティ告知
Node.jsは、Webサイトや業務アプリのプログラムを動かす土台です。今回確認したいのは、本番環境で使っている版と、外部から届く通信をNode.jsのどの機能で処理しているかです。利用しているというだけで、すべての問題の成立条件に当てはまるわけではありません。
修正版は3系列。制作PCだけでなく本番を確認する
今回の修正版は次のとおりです。下の番号は11月11日に公開された版で、更新時には同じ系列の後続修正版も含め、提供元の最新案内を確認してください。
| 使用している系列 | 今回の修正版 |
|---|---|
| 22.x | 22.23.5 |
| 24.x | 24.22.3 |
| 26.x | 26.13.1 |
開発会社には、公開中のWebアプリ、API、定期処理などで使っているNode.jsを調べてもらいます。制作時だけにNode.jsを使い、公開したページを別の仕組みで配信する構成と、利用者の通信をNode.jsが受ける構成では、調べる範囲が違います。
サポートが終了した古い系列についても、今回の表にないことを理由に安全とは判断できません。公式は、セキュリティ更新時にはサポート終了版も影響を受けるものとして、更新済みのサポート対象版を使うよう案内しています。
停止と情報漏えいは、処理の条件が異なる
今回の告知には、HTTP/2という通信方式や、HTTPS・TLSという暗号化通信に関わる複数の問題が載っています。代表的なものを、業務への影響と技術担当者が照合する条件に分けると次のようになります。以下は全修正の一覧ではありません。 対象系列は公式セキュリティ告知の記載に基づきます。
HTTPSの特定の応答処理で、別の接続の情報を読み取られるおそれ
CVE-2026-123864は、22・24・26系列が対象です。公式は、別の利用者のリクエストやTLSの秘密鍵を含む、サーバーのメモリー内の情報が漏れる可能性を説明しています。
成立には、Node.jsのHTTPS処理で、リクエスト本文の受信完了前に res.flushHeaders() を呼び、その後に空でないデータを伴う res.end() を呼ぶ処理が必要です。漏れた情報を取得するには、受け取った本文を返したり保存したりする経路も必要です。暗号化しない node:http は、この問題の対象外とされています。
これは「HTTPSのサイトはすべて情報が漏れる」という意味ではありません。ブラウザーに鍵のマークが出るかではなく、Node.jsが実際にHTTPSを処理する場所と、そのアプリの応答処理を確認します。
HTTP/2では、接続終了やファイル配信も確認する
HTTP/2の接続を終了する途中で特定のエラーが起きると、メモリーや接続用の資源を解放できず、サービスの継続に影響する問題があります。CVE-2026-123865で、22・24・26系列が対象です。
また、HTTP/2で送信途中の処理を終了した際に、解放済みのメモリーを送信してしまうCVE-2026-123866も、22・24・26系列に関係します。ただし、未修正版のうち、26.9.0以降の26系列と24.22.0以降の24系列では、その時点で入った変更により、攻撃側だけで終了処理を起こせるようになったと説明されています。22系列を含む各系列では、アプリ側のストリームごとのタイムアウトなどによる終了処理でも到達し得るとされています。
ファイル配信に respondWithFile() や respondWithFD() を使う場合は、ダウンロードのキャンセルで停止するCVE-2026-123875も確認対象です。こちらは22・24・26系列が対象とされています。各問題の条件を記載した公式告知
接続先ごとに証明書の条件を変えている場合も確認する
クライアント証明書で接続する相手を確認する構成では、TLS 1.2の再交渉によってホスト名を変え、別のホストの厳しい認証条件を回避される問題があります。CVE-2026-123872で、22・24・26系列が対象です。ホスト名ごとに異なるクライアント証明書の条件を設定している場合が該当します。
このほか、TLSの接続時の SNICallback、OCSPRequest、newSession、resumeSession のいずれかのフック、または server.addContext() を使う場合に、外部からサーバーを停止される問題も告知されています。CVE-2026-126051で、公式告知の対象は24・26系列です。
HTTP/2を使っていなくても、こうしたTLS設定や、外向きHTTPS通信の証明書検証、プロキシの認証情報を含むエラー表示、ファイルアクセス制限などの修正があるため、代表例だけで対応不要とは判断しないでください。
更新完了は「本番で修正版が動いている」まで
対象となる環境は、保守担当者と更新の優先度と実施時刻を決めます。特に、影響する通信処理を外部へ公開している場合は、通常の機能改修とは分けて対応を確認したいところです。
アプリの依存パッケージや制作PCだけを更新しても、本番で動くNode.jsが置き換わるとは限りません。コンテナーを使う環境では、土台の更新に加えてアプリの作り直し・再配置が必要な場合があります。管理型サービスでは、提供元が行う更新と利用者側の作業を確認します。
担当者には、次の4点をまとめてもらうと対応状況を判断しやすくなります。
- 利用場所と版： 本番・検証・定期処理のどこでNode.jsを使い、どの版が動いているか。
- 該当する処理： HTTP/2、Node.js自身のHTTPS処理、証明書認証、ファイル配信など、どの条件に当てはまるか。対象外と判断した場合の根拠は何か。
- 反映と動作確認： 修正版または提供元の修正済みパッケージを、再起動・再配置も含めて本番へ反映したか。ログイン、API、ファイルの送受信などは正常に動くか。
- 不審な動作の調査： 異常終了、メモリーや接続数の増加、不自然な応答などがないか。情報漏えいが疑われる場合に、ログ保全や鍵の失効・再発行を誰が判断するか。
今回確認した公式告知に、これらの問題の実際の悪用を確認したという記載はありません。可能な影響と、自社で被害が起きたかは分けて調べる必要があります。更新するだけで、過去の漏えい有無まで確かめられるわけではありません。
Node.jsと共通部品の役割、本番まで更新する意味は、Node.js・Brotliと実行環境の更新を解説したガイドでも整理しています。
情報確認日：2026年11月12日。対象条件は公式セキュリティ告知、修正版は各系列のリリースノートで確認しています。