Node.js、保守中の全3系統で深刻度「高」の脆弱性　7月27日以降に修正版公開へ

2026年7月25日 12:43

本番環境でNode.jsを運用している組織は、7月27日までに準備を整える必要がある。Node.jsプロジェクトは、2026年7月27日（月）またはその直後に、現在保守されている3つのリリースラインすべてにセキュリティアップデートを公開する予定であり、各ラインで対処される脆弱性のうち最も深刻なものは「高（HIGH）」と評価されている。Node.js 22.x、24.x、26.xのすべてで同時に深刻度「高」の脆弱性が修正されるという状況は、セキュリティチームがパッチの公開後ではなく、今のうちにメンテナンス枠を確保すべきだというシグナルだ。

■サポート中の全バージョンが対象に

OpenJS Foundationのガバナンス下にあるNode.jsプロジェクトは、7月21日にこのアドバイザリを公開し、リリース予定日まで6日間の準備期間を設けた。7月27日のリリースで対処される具体的な脆弱性について、技術的な詳細はまだ公開されていない。これは、攻撃者に標的となる情報を与えずに、運用担当者がデプロイメントパイプラインを準備できるようにする、同プロジェクトの協調的な脆弱性開示プロセスにおける標準的な対応だ。

7月27日のリリースは、現在サポートされているNode.jsの全リリースラインを対象とする。新規の本番アプリケーション向けにプロジェクトが推奨している現在のActive LTSライン、Node.js 24.xでは、深刻度「高」の脆弱性が修正される。2027年4月30日まで重大なセキュリティ修正を受けられるMaintenance LTSのNode.js 22.xでも、最も深刻な脆弱性は「高」と評価されている。2026年5月にCurrentリリースとなり、2026年10月にActive LTSへ移行する見込みのNode.js 26.xも同様に「高」と評価されている。

3つの現行リリースラインすべてで「高」評価が共通している点は注目に値する。これまでのNode.jsのセキュリティリリースでは、各バージョンでデフォルトで有効なサブシステムの違いによって、リリースラインごとに脆弱性の深刻度が異なることがあった。全ラインで一律に「高」となっていることは、3つのラインが共有するコードベースにまたがる種類の脆弱性が、1件または複数存在する可能性を示唆している。具体的なCVEは7月27日まで明らかにならない。

2026年4月30日にサポート終了（EOL）となったNode.js 20.xや、2026年6月1日にEOLとなったNode.js 25.xなどを使用しているチームも、プロジェクトが長年採用しているEOLポリシー上、7月27日のリリースで対処される脆弱性の影響を受ける。しかし、これらのバージョンには公式パッチが提供されない。EOLバージョンを対象として公開された新しいCVEは、公式ディストリビューションでは恒久的に未修正のままとなる。このため、該当バージョンを使用する組織は、プロジェクトから修正版を入手できない状態で、拡大する攻撃対象領域に対処しなければならない。

■Node.jsにおける深刻度「高」の実際の意味

Node.jsプロジェクトが使用するCVSS評価システムにおける深刻度「高」は、認証なしでリモートから悪用できる、低い攻撃難易度で誘発できる、またはシステムの機密性、完全性、可用性に重大な影響を及ぼす脆弱性であることを示す。Node.jsの運用という実務的な観点では、インターネットに公開されたNode.jsサーバーにおける「高」評価の脆弱性は、PCI DSSやSOC 2などのコンプライアンスの枠組みで一般に30日以内の修正が求められる種類の問題だ。規制対象業界のセキュリティチームが、通常のデプロイではなく緊急メンテナンス枠を設ける理由とすることも多い。

今回の事前告知の5週間前に公開された2026年6月18日のセキュリティリリースは、最近のNode.jsにおける深刻度「高」の脆弱性がどのようなものかを知る参考になる。このリリースでは、同じ3つのリリースラインにまたがる12件の脆弱性が修正され、そのうち2件が「高」と評価されていた。

1件目のCVE-2026-48933は、WebCryptoにおける整数オーバーフローだった。Web Cryptography APIのNode.js実装に含まれるsubtle.encrypt()関数で、入力サイズの境界チェックが行われていなかった。サイズが2GiBの倍数となる入力を与えると、AES暗号化実装のデータ長計算で整数オーバーフローが発生し、プロセスが異常終了する。その結果、リモートから誘発可能なサービス拒否（DoS）につながる。暗号化処理を行うNode.jsのエンドポイントに、攻撃者が制御できる入力を渡せる場合、細工した1件のリクエストでプロセスをクラッシュさせることが可能だった。2GiBというしきい値は、極端に特殊な条件とは限らない。暗号化されたファイルのアップロード、動画ストリーミングのパイプライン、クラウドストレージの暗号化を処理するアプリケーションでは、この範囲の入力を扱うことがある。

6月のもう1件の深刻度「高」の脆弱性であるCVE-2026-48618は、TLSのホスト名検証を回避できる問題だった。Node.jsのTLS実装では、ホスト名の名前解決と証明書の検証に、それぞれ異なるコードパスを使用している。ホスト名にUnicodeのドット区切り文字、すなわち通常のピリオドと見た目は似ているものの、異なる方法で符号化され、国際化ドメイン名で使用される文字が含まれている場合、名前解決側はそれをASCIIのピリオドへ正規化する一方、検証側は正規化しない。この不一致により、ある範囲のサブドメインを対象としたワイルドカードTLS証明書が、本来対象外である別のサブドメインでも検証を通過する可能性がある。マルチテナント型SaaSプラットフォーム、相互TLS（mTLS）を使用するAPIゲートウェイ、企業向けの証明書ピニング実装など、認証にワイルドカードTLS証明書を利用するアプリケーションでは、ワイルドカード証明書を持つ攻撃者が特定の条件下で認証境界を越えられることを意味する。

6月のリリースでは、攻撃者が制御するORIGINフレームによってメモリ使用量が無制限に増加する問題（CVE-2026-48619）や、不正なプロトコルエラーの発生後にセッションが適切にクリーンアップされない問題（CVE-2026-48937）など、Node.jsのHTTP/2実装における脆弱性も修正された。

■Permission Modelのバイパス問題

2026年の一連のセキュリティリリースを振り返ると、7月27日の事前告知によって改めて重要となる点がある。Node.js 20で導入され、「--permission」フラグで有効にする実験的なサンドボックス機構「Permission Model」が、2026年のすべての主要なセキュリティリリースでバイパスされていることだ。

2026年1月のリリースでは、「--allow-net」フラグを指定していなくても任意のローカルソケットへネットワーク接続できるPermission Modelのバイパス（CVE-2026-21636）が修正された。2026年3月のリリースでは、以前の不完全な修正を改めるとともに、UDS（Unixドメインソケット）サーバーに関する別のバイパス（CVE-2026-21711）が修正された。2026年6月のリリースでは、制限されたファイルシステムパスへの意図しないアクセスを可能にする2件と、適切な権限なしでローカルネットワークサーバーを作成できる1件の、計3件のPermission Modelバイパス（CVE-2026-48617、CVE-2026-48935、CVE-2026-48936）が修正された。

Permission Modelをセキュリティ境界として使用しているチームにとって、これは同機能が依然として実験段階にあり、本番環境のセキュリティアーキテクチャが通常求める分離保証をまだ実証できていないことを意味する。侵害された依存パッケージがアクセスできる範囲を制限するなど、サプライチェーン攻撃への緩和策として「--permission」を使用している組織は、これを主要なセキュリティ対策ではなく、多層防御の一手段として扱うべきだ。7月27日のパッチについても、利用可能になり次第適用する必要がある。

■今後数日間で推奨される4つのステップ

ステップ1：環境内にあるすべてのNode.jsインスタンスを特定する。本番サーバーだけでなく、開発環境とステージング環境、CI/CDパイプライン、コンテナ化されたワークロード、サーバーレスランタイム、Node.jsバイナリを同梱する社内ツールも対象となる。いずれかでNode.js 20.x以前を実行している場合、プロジェクトから公式パッチは提供されない。新しいセキュリティリリースが公開されるたびに、サポート対象ラインへアップグレードする緊急性は高まる。

ステップ2：メンテナンス枠を計画し、日程を確保する。ブルーグリーンデプロイメント、カナリアリリース、複数リージョンへの展開など、複雑なデプロイメントプロセスを持つ組織にとって、深刻度「高」のパッチに備えるための6日間は短い。今すぐ日程の調整を始めるべきだ。パッチは7月27日またはその直後に公開される予定だ。「その直後」が具体的にいつまでを指すかはプロジェクトから示されていないものの、過去の例では同日または24時間以内だった。

ステップ3：nodejs-secに登録する。nodejs-secメーリングリストは、Node.jsプロジェクトが運営する、配信量の少ないセキュリティ発表専用のメーリングリストだ。7月27日にパッチが公開された際、確定した通知を速やかに受け取るための手段となる。

ステップ4：サードパーティーによるパッケージ提供の予定を確認する。マネージドホスティングやベースDockerイメージを使用している組織は、Node.jsの公式リリース後、プラットフォーム事業者やベースイメージのメンテナーが更新版をどれほど早く公開するか確認する必要がある。サードパーティーによる再パッケージ化は通常、公式リリースより数時間から1日以上遅れる。修正済みのコンテナを直ちに必要とするチームは、下流の更新を待つのではなく、Node.js公式のDockerイメージを基にビルドすることを計画すべきだ。

■2026年のリリース動向と10月からのスケジュール変更

7月27日のリリースは、1月13日、3月24日、6月18日に続く、2026年で4回目のNode.jsセキュリティリリースとなる。一連の脆弱性リリースは、プロジェクトが能動的な脆弱性調査への投資を増やしていることと、広く導入されているサーバーサイドランタイムが厳しい調査の対象となっていることの両方を反映している。Node.jsは、世界のWebサーバー、RESTおよびGraphQL APIのバックエンド、サーバーレス関数、開発者向けツールの相当部分を支えている。このため、セキュリティ研究者にとって価値の高い調査対象であると同時に、企業のセキュリティチームにとって優先的にパッチを適用すべき対象でもある。

2026年に複数のリリースラインで深刻度「高」の脆弱性が同時に確認されているという傾向は、プロジェクトによる事前告知の価値を一層高めている。パッチが公開された当日に初めて知ったチームには、準備する時間がないからだ。7月21日の事前告知により、チームには明確な準備期間が与えられた。

7月27日のパッチは、Node.jsのリリースプロセスが構造的に変化する時期に公開される。2026年3月、プロジェクトは年2回のメジャーリリースから、年1回のメジャーリリースへ移行すると発表した。新しいモデルでは、Node.js 27が2026年10月にAlphaチャネルへ入り、正式な27.0.0が2027年4月にリリースされる。バージョン番号は最初に正式リリースされる暦年と一致し、2027年には27.0.0、2028年には28.0.0となる。すべてのリリースが最終的に長期サポート（LTS）へ移行するため、25.xのように短期間で終了する奇数番号の「Current」ラインと、長期間サポートされる偶数番号のLTSラインという区別はなくなる。

アップグレードのロードマップを計画しているチームにとって、これはNode.js 26が、約10年間続いた奇数・偶数モデルに基づく最後のバージョンになることを意味する。Node.js 26は2026年10月にActive LTSとなり、2029年4月30日までサポートされる。7月27日のパッチ公開後も、現行のLTSラインへまだ移行していないチームにとって、Node.js 26は推奨されるアップグレード先となる。

各リリースラインの状況は次の通りだ。Node.js 26.xは現在Currentで、2026年10月にActive LTSへ移行する予定であり、EOLは2029年4月30日となる。Node.js 24.xはActive LTSで、EOLは2028年4月30日、Node.js 22.xはMaintenance LTSで、EOLは2027年4月30日である。この3ラインでは、7月27日のリリースで対処される脆弱性の最大深刻度がいずれも「高」と評価されている。一方、Node.js 20.xは2026年4月30日にEOLとなっており、公式パッチは提供されない。パッチは2026年7月27日（月）またはその直後に公開される予定だ。

■注目ポイントQ&A

●7月27日のセキュリティリリースで影響を受けるNode.jsのバージョンは何ですか？

現在保守されている3つのリリースライン、Node.js 22.x（Maintenance LTS）、24.x（Active LTS）、26.x（Current）のすべてに、2026年7月27日またはその直後にパッチが提供される予定です。Node.jsプロジェクトは、各ラインで対処される脆弱性のうち、最も深刻なものが「高（HIGH）」と評価されていることを明らかにしています。Node.js 20.xや25.xなどのサポート終了（EOL）バージョンも、今回対処される脆弱性の影響を受けますが、公式パッチは提供されません。

●Node.jsのセキュリティパッチが公開される際に事前通知を受け取るにはどうすればよいですか？

Node.jsプロジェクトのnodejs-secメーリングリストが、セキュリティ通知の公式チャネルです。配信量の少ない発表専用リストで、一般的な議論ではなく、リリース通知と事前告知が配信されます。プロジェクトは、本番環境の運用チームがメンテナンス枠を確保できるよう、7月21日の通知のような事前告知をリリースの数日前に公開しています。

●Node.jsのPermission Modelはこれらの脆弱性を防ぐことができますか？

確実には防げません。「--permission」フラグで有効にするNode.jsの実験的なサンドボックス機構であるPermission Modelでは、6月18日のリリースで修正された3件を含め、2026年のすべての主要なセキュリティリリースでバイパスが修正されています。Node.js 26でも実験的機能と位置付けられています。セキュリティ対策として使用している組織は、主要な分離保証ではなく多層防御の一手段として扱い、ほかの深刻度「高」の脆弱性と同じ優先度で7月27日のパッチを適用する必要があります。

●本番環境でまだNode.js 20を実行している場合、チームはどうすればよいですか？

Node.js 20.xは2026年4月30日にサポートを終了しました。その日以降に公開される深刻度「高」の脆弱性は、7月27日のリリースで対処されるものを含め、20.x向けの公式パッチを受け取ることができません。Node.jsプロジェクトは、サポート対象バージョンへのアップグレードを推奨しています。Node.js 20から22への移行手順は十分に文書化されており、一般に大きな混乱を伴わないとされています。アップグレードが完了するまで、EOLバージョンを使用する組織は、新たに公開されるNode.jsのCVEを恒久的に未解決となるリスクとして扱い、必要な代替策を重ねる必要があります。

元記事: Node.js Security Release: HIGH Severity Vulnerabilities Hit All Three Lines

関連記事

最新記事