Node.js の TLS ホスト名にヌル文字を埋めると接続先が静かにすり替わる欠陥（NVD 9.8 / ベンダー Medium）

Critical（CVSS 9.8）に分類されるNode.js（OpenJS Foundation） Node.js 22 / 24 / 26（22.23.0・24.17.0・26.3.1 より前）の脆弱性です。Node.js の TLS ホスト名の扱いに欠陥がある。ホスト名の途中にヌル文字（\0）を埋め込むと、リゾルバのバインディングで C 言語文字列として切り詰められ、TLS の検証に使われる名前と実際に名前解決される名前がずれる。結果として、検証は通ったまま接続先の権威（authority）が静かに別のホストへ差し替わる。影響を受けるのはサポート中の全リリースライン、すなわち Node.js 22・24・26 で、修正は 2026年6月18日の定例セキュリティリリース（v22.23.0 / v24.17.0 / v26.3.1）に含まれる。 注意すべきは深刻度の評価が割れている点である。NVD は CVSS 3.1 基本値 9.8（Critical・AV:N/AC:L/PR:N/UI:N/C:H/I:H/A:H）を付けている一方、Node.js 自身はこの CVE を Medium と公表している。ヌル文字入りのホスト名を外部入力から組み立てて接続する経路が実際にあるかどうかで、現実の危険度が大きく変わるためである。自分のコードがユーザー入力や外部データからホスト名・URL を組み立てて https / tls で接続しているなら NVD 側の評価に近い扱いをし、固定のホスト名しか使っていないなら影響は限定的と判断してよい。 同じ2026年6月のリリースでは合計12件が修正されており、CVE-2026-48933（WebCrypto の AES 整数オーバーフローによる DoS・HIGH）、CVE-2026-48618（Unicode のドット類似文字を使った TLS ワイルドカード認証バイパス・HIGH）も含まれる。1件だけを見て個別パッチを当てるより、リリース単位で上げるほうが確実である。

対処は明快で、Node.js を v22.23.0 / v24.17.0 / v26.3.1 以降へ上げることである。回避策は公表されていないため、更新が唯一の対処になる。 優先順位の付け方としては、外部から受け取った値でホスト名や URL を組み立てて接続しているコードを先に洗い出す。Webhook の宛先をユーザーが設定できるもの、SSRF 対策のためにホスト名を検証してから接続しているプロキシ的な処理、URL をそのまま fetch や https.request に渡している箇所が該当する。こうした経路では、検証したホスト名と実際の接続先が食い違うため、SSRF 対策そのものが素通りになる。 コンテナで動かしている場合はベースイメージの Node.js バージョンを確認する。node:22-slim のようなタグは更新されるので、イメージを再ビルドすれば入る。Lambda や Cloud Functions のようなマネージドランタイムは、事業者側のランタイム更新を待つことになるため、ランタイムのバージョン表記を定期的に確認する。 更新後は、影響期間中にホスト名にヌル文字を含むリクエストが来ていなかったかをアクセスログで確認しておくとよい。%00 や生の \0 を含むホスト指定は通常の利用では現れない。

Node.js（OpenJS Foundation） Node.js 22 / 24 / 26（22.23.0・24.17.0・26.3.1 より前） を利用している場合、稼働バージョンが影響範囲に含まれるかを一次情報（https://nvd.nist.gov/vuln/detail/CVE-2026-48930）で確認してください。AWS・GCP・Azure・Linux それぞれの対応状況は本ページの「クラウド／OS 別の対応状況」表にまとめています。確認できていない項目は「情報確認中」と明記しており、存在しないパッチ番号・バージョンは記載していません。