Node.js 2026年7月セキュリティリリース - HTTP/2とPermission ModelのHIGH 3件を含むCVE 11件を読み解く

2026年7月29日、Node.jsプロジェクトがCurrent・Active LTS・Maintenance LTSの3ラインすべてを対象にセキュリティリリースを公開しました。修正されたCVEは合計11件、うちHIGHが3件です。パッチ済みバージョンはv26.5.1(Current) / v24.18.1(Active LTS) / v22.23.2(Maintenance LTS)。

今回目立つのは、HTTP/2の内部処理でメモリ上限やメモリ安全性が破られる2件と、Permission Modelのパス照合が想定より広い範囲を許可してしまう1件です。いずれもHIGH評価が付いています。本記事では、この3件を中心に仕組みをやさしく解説し、残り8件(MEDIUM 5件・LOW 3件)は実務影響が大きそうなものを深掘りしつつ整理します。

なお、2026年6月18日にも「TLSホスト名検証バイパス」をテーマにした緊急リリースがありました(Node.jsが一気に塞いだ「TLSホスト名検証バイパス」4種)。今回はその続報ではなく、まったく別のCVE群です(ただし今回もHTTPS Agentのホスト名検証に関わる1件が含まれており、この点は後述します)。

このリリースの全体像(早見表)

項目	内容
公開日	2026年7月29日(水)
修正CVE数	11件(HIGH 3件 / MEDIUM 5件 / LOW 3件)
対象ライン	22.x(Maintenance LTS)・24.x(Active LTS)・26.x(Current)
パッチ版	`v26.5.1` / `v24.18.1` / `v22.23.2`
同梱更新	undici(8.9.0 / 7.29.0 / 6.28.0)、llhttp(9.4.3)

undiciのバージョンはライン別に異なります(26.xが8.9.0、24.xが7.29.0、22.xが6.28.0)。llhttpは全ライン共通で9.4.3です。

HIGH評価3件を読み解く

CVE-2026-56846: HTTP/2の保持ヘッダーがmaxSessionMemoryをすり抜ける

対象は24.x・22.x。Node.jsのHTTP/2実装には、接続ごとのメモリ使用量に上限を設けるmaxSessionMemoryという設定があります。ところが保持(retained)されたヘッダーブロックの扱いに欠陥があり、この上限の計算から漏れてしまうケースがありました。結果として、攻撃者が細工したリクエストを送り続けると、設定した上限を超えてメモリを消費させられ、リモートからのメモリ枯渇(DoS)につながります。

maxSessionMemoryは「これを設定していれば安全」という前提で運用しているサーバーが多い設定です。その前提が一部の入力パターンで崩れる、という点が実務上の要注意ポイントです。

CVE-2026-56848: HTTP/2の再入送信でheap-use-after-free

対象は26.x・24.x・22.xの全ライン。HTTP/2のネイティブ実装はnghttp2_session_mem_recv()(受信データの処理)とnghttp2_session_mem_send()(送信データの生成)という関数を軸に動いています。今回の問題は、nghttp2_session_mem_recv()の実行中に、何らかの経路でnghttp2_session_mem_send()が再入(re-entrant)されてしまうという欠陥です。

再入が起きると、片方の処理がまだ参照しているメモリ領域を、もう片方の処理が先に解放してしまうことがあります。これがheap-use-after-free(解放済みメモリへのアクセス)です。use-after-freeはクラッシュだけでなく、条件によっては任意コード実行につながる深刻度の高いクラスの欠陥として知られています。HTTP/2を受け付ける全てのサーバー・プロキシが対象になり得るため、対象ラインが全ラインに及んでいる点からも影響範囲の広さがうかがえます。

CVE-2026-58043: Permission Modelのパス照合が過剰許可を生む

対象は26.x・24.x・22.xの全ライン。Node.jsのPermission Model(--permissionフラグで有効化する実験的なサンドボックス機能)は、--allow-fs-readや--allow-fs-writeで許可したパス以外のファイルシステムアクセスを拒否する仕組みです。この許可判定には、パスの前方一致を高速に扱うためのradix-tree(接頭辞木)に近いデータ構造が使われています。

今回の欠陥は、radix-treeの接頭辞境界の扱いに誤りがあり、許可したパスの「接頭辞が同じだけの別パス」まで許可されてしまうというものです。たとえば/app/dataだけを許可したつもりが、境界判定のずれによって/app/data-secretのような、文字列としては接頭辞が一致するだけの隣接パスにもアクセスできてしまう、という構図です。アドバイザリは「1つのパスへのアクセスを許可された攻撃者が、allowlist外のパスを読み書きできる」と説明しています。Permission Modelを信頼境界(サンドボックス)として運用しているシステムでは、この1件は特に優先度を上げて確認する必要があります。

MEDIUM/LOW 8件の整理

残り8件を表で整理します。

CVE	タイトル	深刻度	対象
CVE-2026-56850	HTTPS AgentがPFX証明書間でmTLS識別情報を再利用できる	MEDIUM	26.x, 24.x, 22.x
CVE-2026-58040	HTTPS Agentのセッション再利用がホスト名検証をスキップできる	MEDIUM	26.x, 24.x, 22.x
CVE-2026-58041	`node:sqlite`のSQLTagStoreイテレータ再生が書き込みを再実行できる	MEDIUM	26.x, 24.x
CVE-2026-58042	`dns.resolveAny()`がAレコード多数のDNS応答で異常終了する	MEDIUM	26.x, 24.x, 22.x
CVE-2026-58045	`node:zlib`の同期APIが偽装TypedArray長でクラッシュする	MEDIUM	26.x, 24.x, 22.x
CVE-2026-56847	Permission Modelでトレースイベントがallowlist外に書き込める	LOW	26.x, 24.x, 22.x
CVE-2026-58039	Permission Modelでプロセスレポートがallowlist外に書き込める	LOW	26.x, 24.x, 22.x
CVE-2026-58044	HTTPパーサのヘッダ切り詰めがリクエストスマグリングを許す	LOW	26.x, 24.x, 22.x

このうち実務影響が大きそうな4件を掘ります。

HTTPS Agentのmtls/hostname系(56850・58040)

https.AgentはTCP接続とTLSセッションを再利用してパフォーマンスを上げる仕組みですが、この再利用がセキュリティ境界を破ってしまう問題が2件同居しています。

CVE-2026-56850は、クライアント証明書(PFX形式)を複数使い分けている構成で、Agentが別のPFX証明書のmTLS識別情報を誤って再利用してしまう問題です。テナントごとに異なるクライアント証明書で認証する多テナント構成が該当します。
CVE-2026-58040は、TLSセッションの再利用時にホスト名検証そのものがスキップされるという問題です。2026年6月に修正された「正規化の食い違い」による検証バイパスとは原因が異なりますが、結果として「本来検証すべきホスト名の一致確認が働かない」という同種の懸念を再び生んでいます。証明書の身元検証をhttps.Agentに委ねている構成は、あらためて棚卸しが必要です。

いずれも接続の再利用というパフォーマンスのための最適化がセキュリティ境界を壊すパターンで、この構図自体は6月のセッション再利用の問題(CVE-2026-48934)とも通じます。

node:sqliteのイテレータ再生(58041)

node:sqliteは26.x/24.xで使える組み込みのSQLiteバインディングです。SQLTagStoreのイテレータを再生(replay)する形で使うと、本来1回だけ実行されるはずの書き込みクエリが再実行されるという問題です。冪等性を前提にしたバッチ処理やマイグレーションスクリプトで意図しない重複書き込みが起きる可能性があります。node:sqliteを採用しているアプリは、イテレータの再利用パターンがないか確認してください。

dns.resolveAny()の異常終了(58042)

dns.resolveAny()は複数種類のDNSレコードを一括で取得するAPIです。Aレコードを多数含むDNS応答を受け取ると、プロセスが異常終了するという問題があります。DNSの名前解決の基礎はDNSの仕組み入門でも整理していますが、悪意あるDNSサーバー、あるいはキャッシュポイズニングなどで多数のAレコードを送り込める経路があると、繰り返しトリガーすることでDoSにつながります。resolveAny()を外部入力(ユーザー指定ドメインなど)に対して呼んでいる箇所は要確認です。

HTTPパーサのヘッダ切り詰めによるスマグリング(58044)

HTTPパーサが特定のヘッダを切り詰める処理に欠陥があり、リバースプロキシとNode.jsサーバーとでリクエストの解釈がずれることでリクエストスマグリングが成立し得ます。深刻度はLOWですが、リクエストスマグリングはフロント(CDN/プロキシ)とバックエンドの解釈の不一致を突く攻撃であるため、キャッシュ汚染やアクセス制御回避の踏み台になりやすい種類の欠陥です。Node.jsをリバースプロキシの背後で運用している構成では見過ごさないようにしてください。

悪用について

公式アドバイザリの各CVEには、繰り返しトリガーした場合の影響(DoSに至る、allowlist外に書き込める等)についての説明はありますが、本リリースのCVEが実際に悪用(active exploitation)されたという記述は一次情報に見当たりません。攻撃条件や影響の説明は「こう使われるとこうなる」という技術的な解説であり、悪用が観測された事案ではない点は区別しておきます(この点は未確認であり、断定はしません)。

いま実務でやること

まずランタイムを上げる。node -vで現在のバージョンを確認し、v26.5.1 / v24.18.1 / v22.23.2以上へ。nodebrewを使っているならnodebrew install-binary v24.18.1 && nodebrew use v24.18.1、nvmならnvm install 24.18.1 && nvm use 24.18.1で上げられます。
HTTP/2を受け付けるサーバー・プロキシを優先する。CVE-2026-56848(heap-use-after-free)は全ラインが対象で、HTTP/2を有効にしている以上は無条件に影響を受けます。http2.createServer()やHTTP/2対応のリバースプロキシ(Nginx/Envoy越しにHTTP/2でNode.jsへ転送している構成など)は最優先で確認してください。
Permission Model(--permission)を使っているなら、allowlistの境界を再確認する。CVE-2026-58043はパスの接頭辞境界のずれが原因なので、--allow-fs-read/--allow-fs-writeで許可したパスの隣接パス(同じ接頭辞を持つ別のディレクトリ・ファイル)が意図せず許可されていないか、アップデート後にあらためて確認するのが安全です。
HTTPS Agentでの証明書・セッション再利用を確認する。クライアント証明書(mTLS)を複数使い分けている構成、TLSセッション再利用を有効にしている構成は、CVE-2026-56850・CVE-2026-58040の対象です。
コンテナイメージ・CIのベースを更新する。固定タグ(node:24.18.0など)で運用している場合は明示的に上げる必要があります。サプライチェーン全体の考え方はnpmのインストールスクリプトデフォルト無効化も参考になりますが、今回のようなランタイム自体の欠陥はロックファイルやSBOMでは防げず、ランタイム更新そのものが唯一の対策です。

Node.jsのリリース運用そのものについてはNode.jsの年次リリーススケジュール変更も参照し、LTSラインの追従を仕組み化しておくと、今回のような月次を超えた不定期リリースにも対応しやすくなります。

まとめ

2026年7月29日、Node.jsが全アクティブライン(22/24/26)でCVE 11件を一斉修正。HIGHは3件。
パッチ版はv26.5.1 / v24.18.1 / v22.23.2。同梱でundici・llhttpも更新。
HIGHはHTTP/2のmaxSessionMemory回避(CVE-2026-56846)、HTTP/2再入によるheap-use-after-free(CVE-2026-56848)、Permission Modelのパス照合過剰許可(CVE-2026-58043)。
MEDIUM/LOWにはHTTPS Agentのmtls/hostname系、node:sqliteのイテレータ再生、dns.resolveAny()の異常終了、リクエストスマグリングなど実務影響のあるものが含まれる。
悪用が観測されたという記述は一次情報になし。ただし放置する理由にはならない。
2026年6月のTLSホスト名検証バイパス4件とは別のCVE群。ただしHTTPS Agentのホスト名検証をめぐる懸念は今回も再登場している。