Node.js 2026年7月セキュリティ更新 — HTTP/2・Permission Model・HTTPSを重点確認
概要
Node.js プロジェクトは 2026年7月29日、26.x、24.x、22.x のアクティブなリリースライン向けにセキュリティ更新を公開しました。更新には undici と llhttp の依存関係更新に加え、HTTP/2、Permission Model、HTTPS Agent、node:sqlite、DNS、node:zlib などに関する複数の修正が含まれます。1
今回の重要点は、単に依存パッケージを更新することではありません。HTTP/2を公開しているサービス、--permission を利用するツール、複数のクライアント証明書を扱うmTLS通信、組み込みSQLite、DNS解決を行うバックエンドでは、更新後に利用経路を重点的に検証する必要があります。
| 領域 | 公式発表で示された問題 | 影響を確認したいシステム |
|---|---|---|
| HTTP/2 | セッションメモリ制限の回避、再入送信によるheap-use-after-free | HTTP/2サーバー、プロキシ、ゲートウェイ |
| Permission Model | 許可したパスの境界を越えるファイルアクセスなど | --permission を使うCLIや実行基盤 |
| HTTPS Agent | PFX証明書のmTLS ID再利用、ホスト名検証に関する問題 | 複数テナント・複数証明書のHTTPSクライアント |
| node:sqlite | キャッシュ済み文の再利用に伴う書き込み再実行 | DatabaseSync / SQLTagStore 利用アプリ |
| DNS / zlib | 異常なDNS応答やTypedArrayに起因するDoS | 外部入力を扱うネットワークサービス |
更新対象を最初に特定する
Node.js プロジェクトは、最高深刻度を High とし、サポート終了済みのバージョンもセキュリティリリース時には影響を受けると注意喚起しています。1 そのため、最初の作業は「どのサービスがどのNode.jsを実行しているか」を把握することです。
| 場所 | よくある見落とし | 確認方法 |
|---|---|---|
| 本番コンテナ | Dockerfileのベースイメージが古い | イメージタグとダイジェストを調べる |
| CI | actions/setup-node やキャッシュに古い固定値がある | ワークフローとロックファイルを確認する |
| サーバーレス | ランタイム設定がプラットフォーム側にある | 管理画面・設定ファイル・実行ログを確認する |
| 開発環境 | .nvmrc やVolta、miseの設定が残っている | バージョン管理ファイルを確認する |
| CLI・ジョブ | 対話アプリ以外の定期処理が更新対象から漏れる | プロセス一覧・スケジュール設定を棚卸しする |
優先順位の付け方：外部から到達可能なHTTP/2サービス、Permission Modelを使う実行環境、mTLSを利用する統合、
node:sqliteを使う書き込み処理を先に更新・検証します。その後、内部向けサービスと開発環境を揃えます。
HTTP/2とプロキシの確認ポイント
公式発表では、HTTP/2 の保持ヘッダーが maxSessionMemory 制限を回避してリモートのメモリ枯渇につながり得る問題と、送信APIの再入によるheap-use-after-freeを High としています。1 HTTP/2 を自ら有効化していない場合でも、リバースプロキシ、APIゲートウェイ、サービスメッシュ、CDNの背後で Node.js がどのプロトコルを処理しているかを確認します。
更新後は、標準的なAPIテストに加え、接続を長時間維持するクライアント、巨大または多数のヘッダー、ストリーミングレスポンス、タイムアウト時のメモリ使用量を観測します。これは脆弱性の再現を試みるのではなく、通常の防御設定と監視が更新後も期待どおり機能することを確認するためのテストです。
Permission Model と mTLS は構成テストを追加する
Permission Model では、許可リストのパス境界を越えて読み書きできる可能性、トレースイベントやプロセスレポートの出力先に関する問題が報告されています。1 --allow-fs-read や --allow-fs-write を利用する場合は、許可するパスと隣接する名前のパスを含めたテストを用意し、想定外の書き込み・読み出しが起きないことを確認します。
HTTPS Agent については、PFX配列を利用するmTLS IDの再利用やTLSセッション再利用時のホスト名検証が扱われています。1 これらの機能を使用するクライアントは、異なる証明書・異なるホスト・異なるテナントを跨ぐリクエストをテストケースに含め、接続プールの設定と証明書選択が期待どおりであることを確認します。
安全な更新手順
| 手順 | 実施内容 |
|---|---|
| 1. 実行環境を棚卸し | 本番、CI、開発、CLI、コンテナ、サーバーレスのNode.jsバージョンを記録する |
| 2. アクティブラインの最新パッチへ更新 | Node.jsの公式配布元・利用プラットフォームの更新手順に従う 1 |
| 3. 依存関係を再構築 | npm ci 等でクリーンにインストールし、ロックファイルの意図しない差分を確認する |
| 4. 重点機能を検証 | HTTP/2、mTLS、Permission Model、SQLite、DNS利用箇所の統合テストを行う |
| 5. 段階的に展開 | ログ、メモリ、接続エラー、TLS失敗、HTTPステータスを更新前後で比較する |
| 6. 開発環境を統一 | .nvmrc、CI、コンテナ、ドキュメントのバージョン表記を揃える |
まとめ
今回の Node.js セキュリティ更新は、Webサーバー運用だけでなく、ファイル権限、TLSクライアント、組み込みデータベース、DNS処理まで確認範囲を広げます。更新の成否は「バージョンを上げたか」ではなく、実行中の全環境を把握し、実際に利用する機能をテストし、段階的に展開できたかで決まります。運用上は、ランタイム更新を定例化し、対象一覧とロールバック手順を常に最新に保つことが最も効果的です。