Node.jsに脆弱性11件 HTTP/2の高深刻度に注意

Node.js開発チームは2026年7月29日、11件の脆弱性を修正したセキュリティリリースを公開しました。修正版は26.5.1 / 24.18.1 / 22.23.2の3系列です。深刻度「High」は3件で、うち2件はnode:http2モジュールを使うサーバ、1件は--permission（Permission Model）を使う環境が対象です。EOL済みの20.x以前には修正が提供されません。

まずやることは1つ。社内で動いているNode.jsのバージョンを棚卸しし、上記3系列の最新版へ更新することです。ただし「全部が全部、緊急」ではありません。該当条件がはっきり分かれる回なので、優先度の付け方まで含めて整理します。

この記事でわかること

• 修正された11件の内訳（High 3件／Medium 5件／Low 3件）と修正版バージョン
• High 3件がそれぞれ「どういう環境で刺さるのか」という該当条件
• 自社が影響を受けるかを判定する具体的な手順
• 先日話題になった別のHTTP/2脆弱性（VU#885548）との切り分け
• 2か月連続で発生した「Node.jsの脆弱性の定期便」への向き合い方

何が起きたのか

Node.js開発チームは事前に「7月27日にセキュリティリリースを行う」と予告していました（Node.js、7月27日にセキュリティ更新を予告）。実際の公開はインフラ側の問題により2日遅れ、7月29日となりました。予告の時点では件数も内容も非公開でしたが、蓋を開けると11件でした。

対象となる系列と修正版は次のとおりです。

あわせて同梱依存関係のundici（8.9.0 / 7.29.0 / 6.28.0）とllhttp（9.4.3）も更新されています。HTTPまわりの修正が本体だけで完結していない点は、後述する検証時の注意点につながります。

修正された11件の一覧

Node.js公式アドバイザリに記載された内容を整理すると、次のとおりです。深刻度はNode.jsチーム自身による評価ラベルです。

並べてみると、11件のうち3件がPermission Model関連、4件がHTTP/HTTP/2関連、2件がHTTPS Agent（TLSクライアント側）関連という構成です。バラバラの11件ではなく、3つのかたまりとして捉えると優先度がつけやすくなります。

特に注意すべきHigh 3件はどんな環境で刺さるのか

CVE-2026-56848：HTTP/2サーバを外部公開しているなら最優先

HTTP/2の送信処理が受信処理の途中で再入的に呼ばれることで、解放済みのヒープメモリを参照してしまう欠陥です。use-after-freeは一般に、クラッシュにとどまらず任意コード実行へ発展しうる型の欠陥として扱われます。ただしNode.js公式アドバイザリは実行可能性まで明言していません。一部の報道では実行の可能性に言及していますが、現時点では公式に裏付けられた情報ではないため、断定は避けるべきです。

該当条件は明快で、node:http2モジュールでサーバを立てているかです。Expressなどで一般的なHTTP/1.1のサーバを動かしているだけなら該当しません。ここは切り分けの起点になります。

CVE-2026-56846：メモリ上限の設定が効かなくなる

HTTP/2セッションのメモリ使用量を抑えるためのmaxSessionMemoryという設定が、保持されたヘッダブロックによって回避され、メモリを枯渇させられるというものです。26.xは影響を受けず、24.xと22.xのみが対象という珍しい構成になっています。「上限を設定して守っていたつもり」が守れていなかったという性質のため、設定で緩和する回避策は期待できません。更新が必要です。

CVE-2026-58043：Permission Modelを「サンドボックス」として信頼していた組織に効く

Node.jsの--permissionフラグは、プロセスがアクセスできるファイルパスなどを制限する仕組みです。今回はそのパス照合ロジックの不備により、許可したつもりのない場所を読み書きできてしまいます。Low 2件（CVE-2026-56847 / CVE-2026-58039）も同じPermission Modelの許可リスト逸脱で、トレースイベントとプロセスレポートの出力経路が抜け道になっていました。

Permission Modelは比較的新しい機能で、実運用に入れている組織はまだ多くありません。裏を返せば、「新しい安全機能を積極的に採用した組織ほど今回のHigh 1件＋Low 2件が刺さる」という構図です。セキュリティ機能そのものに欠陥があるパターンは、導入していない組織が結果的に無傷になるという、対応判断としてはやりにくい形になります。

自社は影響を受けるか──判定の手順

「Node.jsを使っているか」ではなく、「どこで、どの機能を使っているか」まで降りないと優先度は決まりません。次の順で確認するのが現実的です。

1. バージョンの棚卸し：本番・検証サーバでnode -vを確認します。コンテナ運用ならnode:22-alpineのようなベースイメージのタグも対象です。イメージを再ビルドしない限り古いままである点に注意してください。
2. HTTP/2の使用有無：ソース内でrequire('http2')やfrom 'node:http2'を検索します。ヒットしなければHigh 2件は該当しません。
3. Permission Modelの使用有無：起動オプションやsystemdのユニットファイル、DockerfileのCMDに--permissionがあるかを確認します。
4. HTTPSクライアントの構成：外部APIへの接続でクライアント証明書（PFX/mTLS）を使っているなら、Medium 2件（CVE-2026-56850 / CVE-2026-58040）を軽視できません。証明書の取り違えやホスト名検証の抜けは、可用性ではなく認証と機密性に効きます。
5. 20.x以前が残っていないか：EOL系列には修正が来ません。動いていること自体がリスクとして固定されます。

現場目線の課題──Node.jsは「台帳に載っていない」

この手の対応でいちばん厄介なのは、脆弱性そのものより「どこでNode.jsが動いているか把握しきれていない」ことです。Webアプリケーションのサーバなら資産管理台帳に載っています。しかし実際には、社内の業務自動化スクリプト、監視ツールの実行基盤、CI/CDのビルドエージェント、Electron製のデスクトップアプリの内部など、「主役ではないNode.js」が組織のあちこちに埋まっています。台帳に「Node.js」と書かれていないものを、限られた人員でどこまで洗い出すか。ここが毎回の悩みどころです。

現実的な折り合いとして、外部公開している経路から順に潰すのは妥当な判断だと考えます。今回のHigh 2件はHTTP/2サーバ、つまり外部からリクエストを受ける面に集中しています。逆に、閉じたネットワークでビルドを回しているだけのNode.jsを最優先で止めて更新する必要は薄いはずです。全部を同時に扱おうとすると、結局どれも終わりません。

先日のHTTP/2脆弱性（VU#885548）とは別件です

ここは混同しやすいので明記しておきます。2026年7月16日に米CERT/CCが公表したHTTP/2サーバのフロー制御を悪用したDoS脆弱性（VU#885548）と、今回のNode.jsの件は別の脆弱性です。時期が近く、どちらも「HTTP/2」「メモリ枯渇」というキーワードを含むため紛らわしいのですが、CVE番号も対象製品も異なります。社内やベンダーとのやり取りで「先日のHTTP/2の件」と言うと話が噛み合わなくなるので、CVE番号かVU番号で指し示すのが安全です。

2か月連続、という事実の重み

Node.jsは2026年6月18日にも12件の脆弱性を修正しています。今回と合わせて2か月で23件です。これは「Node.jsが特別に危険になった」というより、広く使われているランタイムでは脆弱性の公表が定常的に発生するという当たり前の事実の現れと捉えるべきでしょう。単発の緊急対応として毎回消耗するのではなく、Microsoftの月例パッチと同じように、あらかじめカレンダーに入っている定期作業として運用に組み込むほうが結果的に楽になります。

情シスはどうすべきか

個別の対応手順を長々と並べるより、公的機関の指針に沿って運用の型を作るほうが再現性があります。

• ソフトウェア資産の把握から：IPAの中小企業の情報セキュリティ対策ガイドラインは、資産の洗い出しと管理台帳の整備を出発点として示しています。今回のように「どこで動いているか分からない」が最大のボトルネックになる場面では、まずここに戻るのが結局の近道です。
• 脆弱性情報の受け取り口を決める：Node.jsは公式ブログでセキュリティリリースを事前予告します。Node.js公式のVulnerabilityブログと、国内であればJVN・JPCERT/CCを購読対象に入れておけば、「気づいたら1か月経っていた」を防げます。
• 開発チームとの役割分担を明文化する：Node.jsのバージョンは多くの場合、情シスではなく開発チームやアプリのベンダーが握っています。誰がいつまでに更新するのかを都度交渉していると間に合いません。年に数回は必ず来る作業として、あらかじめ合意しておくべきです。
• 更新後の検証を軽視しない：今回は同梱依存のundici・llhttpも更新されています。HTTPクライアントの挙動が変わる可能性があるため、外部API連携のあるシステムでは疎通確認を入れてから本番へ進めてください。

中長期の視点

20.x（Iron）は2026年3月にEOLを迎えています。今回のような修正はもう届きません。にもかかわらず、動いているものを止める理由がないという現場の力学で、EOL系列はしぶとく残ります。EOLは「そのうち直せなくなる」のではなく「もう直らない」状態です。次のLTS移行を、脆弱性が出てからの緊急作業ではなく、年間計画の中に置いておくことをおすすめします。

あわせて、利用者側の啓発も地道に効きます。「業務効率化のために個人で入れたNode.jsツール」が管理外で動いているケースは珍しくありません。禁止するより、「使っているなら申告してほしい」と言える関係を作っておくほうが、結果的に把握できる範囲は広がります。

まとめ

1. Node.jsが2026年7月29日に11件の脆弱性を修正。修正版は26.5.1 / 24.18.1 / 22.23.2で、EOLの20.x以前には提供されません。
2. High 3件の該当条件は明確です。node:http2でサーバを立てているか（CVE-2026-56848 / 56846）、--permissionを使っているか（CVE-2026-58043）。ここを確認すれば優先度が決まります。
3. 7月16日公表のHTTP/2脆弱性（VU#885548）とは別件です。社内共有ではCVE番号で指し示してください。

出典

• Node.js — Wednesday, July 29, 2026 Security Releases（Node.js公式）
• Node.js — Previous Releases（各系列のサポート状況）
• 「Node.js」のアップデートが公開 – 脆弱性11件を修正（Security NEXT）
• 中小企業の情報セキュリティ対策ガイドライン（IPA）