Node.jsが11月セキュリティリリース、HTTPS処理で他の接続のメモリ（TLS秘密鍵を含む）が漏れ得る欠陥を修正

まず初めに

自分の鍵も、隣の客のリクエストも、同じメモリの海に浮かんでいる。その海に、認証なしで手を突っ込める穴が開いていた。派手な侵入経路ではなく、書き込み処理の呼び出し順序という、コードの作法の話であるところが実にいやらしい

※個人の感想です

公式発表の中身

Node.jsプロジェクトは2026年11月11日付の公式ブログで、11月のセキュリティリリースを公表しました。公開されたバージョンはNode.js 26.13.1、24.22.3、22.23.5で、各ラインで修正された問題の最高深刻度はHIGHです。二次集計では、深刻度HIGH 7件を含む計16件の修正と整理されています。件数の集計は集計主体によって参照される過去のCVEとの切り分けが異なる場合があるため、本記事では公式発表に記載された個別の問題を中心に整理します。

最も深刻な問題は、HTTPSサーバーにおけるメモリ漏えいです。公式発表によると、TLSの書き込み処理が、HTTPパーサーがリクエストボディを処理している最中に再入することで解放後使用と境界外のヒープ読み取りが起き、サーバーが解放済みまたは無関係なヒープメモリを、リクエストボディへの応答としてコピーしてしまうというものです。その結果、未認証のクライアントが、他の接続に属するメモリ（TLS秘密鍵や他の利用者のリクエストを含む）を読み得る状態でした。

発動には条件があります。ハンドラーがリクエストボディの終了前にヘッダーを送信し、その後に空でないチャンクで応答を終える処理と、リクエストボディをそのまま返すか保存する経路が組み合わさる場合に読み取りが可能になる、と公式発表は説明しています。平文のnode:httpは影響を受けないとされています。報告者はChris Rohlf氏（ClaudeとAnthropic Researchとの協力による）とされ、修正はmcollina氏が担当したとクレジットされています。

HTTP/2側の問題

HTTP/2でも複数の問題が修正されています。CVE-2026-123865（HIGH）は、セッションの終了処理中にプロトコルエラーが起きると、セッションが内部で破棄されたことをNode.js側が検知できず、メモリとファイルディスクリプタが漏れ続ける問題です。未認証のクライアントが、ソケットをCLOSE_WAIT状態のまま残し、接続ごとの状態を保持させ続けることができるとされ、過去の修正（CVE-2026-48937）の不完全な修正ケースだったと説明されています。

CVE-2026-123866（HIGH）は、HTTP/2ストリームの終了処理における解放後使用で、応答バッファが解放された後にその参照が使われ、解放済みまたは無関係なヒープメモリが相手に送信され得る問題です。相手からのストリームリセットや、サーバー側のストリームタイムアウトによる終了で到達し得るとされています。

このほか、TLSサーバーのハンドシェイク処理における遅延コールバック起因の未捕捉例外で、遠隔の未認証の攻撃者がプロセスを終了させ得る問題（CVE-2026-126051、HIGH）なども、今回のリリースに含まれます。

対象と更新

影響を受けるのは、現行のリリースラインである22.x、24.x、26.xの利用者です。公式発表は、サポート終了版については「セキュリティリリースが発生する際は常に対象の状態にある」として、最新版への移行を前提とする姿勢を明記しています。EOL版を使い続けている環境では、今回の修正版は提供されません。

更新先は、使用中のラインに応じて26.13.1、24.22.3、22.23.5です。HTTPSで外部公開しているNode.jsサーバー、とりわけ複数の利用者のリクエストを同じプロセスで処理する構成では、秘密鍵や他人のリクエストが読み取られ得たという性質上、優先度を上げて適用すべき修正です。言語ランタイムの更新という点では、Rust 1.100.0の公開（Rustの記事）と同日の動きですが、こちらは新機能ではなく緊急度の高い修正です。

影響の切り分け

今回の修正を自分のサービスに当てはめる際は、構成ごとに切り分ける必要があります。HTTPSで外部公開しているNode.jsサーバーは、中核欠陥の対象になり得ます。平文のnode:httpのみで待ち受ける構成は、この欠陥については対象外だと公式発表は説明しています。ただし、リバースプロキシの背後で平文通信をしている場合でも、プロキシから先の構成や、同じプロセスでHTTPSを併用していないかは個別に確認が必要です。

HTTP/2を有効化しているサーバーは、セッション終了時の漏えい（CVE-2026-123865）とストリーム終了時の解放後使用（CVE-2026-123866）の対象になり得ます。HTTP/2を使っていない構成では、この2件の到達経路は限られます。

そして、ラインそのものの棚卸しも欠かせません。22.x、24.x、26.xのいずれでもない古いライン、特にサポート終了版を動かしている環境は、今回の修正を受け取れません。フレームワークやコンテナのベースイメージに古いNode.jsが同梱されたままになっていないかも、あわせて確認する価値があります。

IT Postの見方

IT Postでは、今回の中核欠陥は「条件がそろわないと発動しないから大したことはない」とは読めないと考えます。秘密鍵が漏れる可能性は、漏れたかどうかを後から証明することがほぼ不可能な種類の事故です。条件付きであっても、未認証で到達可能だったという事実だけで、対象サーバーの更新と、必要に応じた証明書の扱いの点検を正当化します。

もう1つの論点はEOL版です。公式が「常に対象」と言い切る以上、EOLのNode.jsを外部公開で動かし続けることは、既知の穴を放置することと同義になりました。バージョンアップを先送りする理由として「動いているから」は、もう通用しません。

今後どうなりそうか

今後は、各クラウド事業者やコンテナイメージ、フレームワーク同梱ランタイムへの修正の行き渡りが焦点になります。利用者は、自分のサービスがどのNode.jsラインで動いているかを棚卸しし、EOLラインが残っていないかを確認するのが先決です。

新たな事実が公表されれば、本記事を更新します。