NGINX HTTP/3 の Use-after-Free｜CVE-2026-42530・1.31.2 で修正

Web サーバの定番 NGINX Open Source の HTTP/3 モジュール（ngx_http_v3_module）に、Use-after-Free の脆弱性 CVE-2026-42530 が公表されました。HTTP/3（QUIC）を有効にした環境で、リモートの無認証攻撃者が細工した HTTP/3 セッションを使い、worker プロセスを落とせます（サービス妨害）。さらに、ASLR が無効、または攻撃者が ASLR を回避できる場合にはコード実行にも至りうるとされ、深刻度は CVSS v4.0 で 9.2（Critical） です。影響は 1.31.0〜1.31.1、修正は 1.31.2。すでに PoC（実証コード）が公開されており、更新の優先度は高い状態です。この記事は、成立の条件・自分が対象かの見分け方・直し方を、CVE 公式記録と F5 の勧告で裏を取って整理します。NGINX の別経路の脆弱性はNGINX の map 正規表現で RCE（CVE-2026-42533）やnginx RIFT のヒープオーバーフロー（CVE-2026-42945）に、依存するミドルウェアの欠陥が守りを崩す全体像はサプライチェーン攻撃とは｜手口・防御ツール比較・npm 12の新機構まで実践解説にまとめています。

まず自分の版と HTTP/3 の有無を確かめます。

nginx -v
nginx -T 2>/dev/null | grep -iE "listen.*quic|http3"

版が 1.31.0・1.31.1 で、かつ quic（HTTP/3）の listen があれば対象です。これは侵害の判定ではなく、修正版かつ対象構成かの確認です。

何が起きるのか

NGINX は、HTTP/3（QUIC）を ngx_http_v3_module で処理します。CVE 公式記録によれば、この構成のとき、リモートの無認証攻撃者が、細工した HTTP/3 セッションで QPACK エンコーダストリームを「再開」させることで、worker プロセスに Use-after-Free を起こせます。Use-after-Free は、いちど解放したメモリを使い続けてしまう不具合で、まず worker の異常終了（＝再起動によるサービス妨害）につながります。

HTTP/3 は比較的新しいプロトコルで、QUIC（UDP ベース）の上で動くぶん、TCP 時代とは別のコード経路を通ります。NGINX の HTTP/3 実装（ngx_http_v3_module）は mainline 系列で活発に開発されてきた部分で、今回の欠陥もその新しい経路に現れました。新しい機能ほど、実装が枯れるまでの間はこうしたメモリ安全性の不具合が出やすく、だからこそ「有効にしているか」を把握し、版を追いかけることが効いてきます。

どこまでの影響か

影響は二段階で理解すると整理できます。確実に起こりうるのは worker の再起動（DoS） で、HTTP/3 を受けている NGINX が繰り返し落ちれば、その経路のサービスは不安定になります。その先の コード実行は、条件つきです。CVE の記述は、ASLR が無効なシステム、または攻撃者が ASLR を回避できる場合に限ってコード実行に至りうる、としています。つまり「必ず RCE になる」わけではなく、環境とさらなる条件に依存します。ここでは攻撃に使える具体的な手順（PoC）は示しません。要点は、HTTP/3 を有効にしているかどうかが、対象かの分かれ目だということです。

NGINX は複数の worker プロセスでリクエストを捌きます。1つの worker が Use-after-Free で落ちても、別の worker や再起動でサービスは続きますが、攻撃者が繰り返し落とせば、その HTTP/3 の経路は不安定になり、応答が途切れます。可用性への影響だけでも、公開サービスには十分痛手です。そして今回は PoC が公開されている点が重く、攻撃の難易度が高め（AC:High）とはいえ、誰でも試せる実証コードが出回っている状況は、「まだ悪用されていないから後で」と先送りする根拠にはなりません。公開 PoC は、守る側にとっては検証の材料にもなりますが、攻める側の敷居も同時に下げます。

何を直すか

恒久策は 1.31.2 以上への更新です。更新の当て方は配布経路で変わります。nginx 公式リポジトリ（nginx.org）のパッケージを使っているなら、そのリポジトリの mainline を 1.31.2 以上へ上げます。ディストリのパッケージを使っている場合は、配布元が mainline 1.31.x を提供しているか、提供していなければ修正を取り込んだ版が出ているかを、配布元の告知で確認します。コンテナで動かしているなら、ベースイメージの NGINX の版を上げてイメージを作り直し、全ノードへ配り直す工程まで含めて「更新」です。どの経路でも、更新後に nginx -v で実際に動いている版が 1.31.2 以上になっているかを突き合わせます。対応の優先度は、次の2点で決まります。

自分の環境を確認する

版の確認に加えて、HTTP/3 を実際に受けているかを設定で見ます。

nginx -T 2>/dev/null | grep -niE "listen .*quic|http3 on"

listen 443 quic; のような行があれば HTTP/3 を有効にしており、版が 1.31.0・1.31.1 なら対象です。行が無ければ、この脆弱性の直接の影響は受けません。確認できたら、1.31.2 以上へ上げ、更新が難しい場合は一時的に HTTP/3 を止めます。いずれも「いま攻撃されているか」ではなく、対象構成か・修正版かの確認です。

影響範囲

直接の対象は、mainline 1.31.0・1.31.1 の NGINX で HTTP/3（QUIC）を有効にしている環境です。NGINX は世界で最も使われる Web サーバ・リバースプロキシの一つで、HTTP/3 を有効にしているサイトも増えています。そのうち該当する版で動かしているものが対象です。逆に、HTTP/3 を使っていない大多数の構成は、この経路の直接の対象ではありません。だからこそ、まず「自分は HTTP/3 を受けているか」を確かめ、受けているなら版を 1.31.2 以上へ上げる、という順で見ると、過不足なく対応できます。

見落としやすいのは、NGINX がリバースプロキシやロードバランサ、CDN のエッジとして、アプリの前段に立っている構成です。この場合、HTTP/3 を終端しているのは NGINX なので、背後のアプリの言語やフレームワークが何であれ、入口の NGINX が今回の対象になりえます。自社で NGINX を直接運用していなくても、前段に置いているマネージド基盤やコンテナイメージが該当版を含んでいないか、ベースイメージの版まで遡って確認する価値があります。構成管理で NGINX の版を固定しているなら、その固定値が 1.31.0・1.31.1 で止まっていないかも併せて見ます。PoC が公開されている以上、HTTP/3 を有効にした該当版は、後回しにせず塞ぐのが妥当です。まずは「HTTP/3 を受けているか」「版はいくつか」の2つを確認するだけで、自分がいま急ぐべき側かどうかが、はっきりと切り分けられます。

参照ソース

• CVE-2026-42530（CVE 公式記録・F5 採番・CVSS v3.1 8.1／v4.0 9.2・CWE-416）
• F5 セキュリティ勧告 K000161616（NGINX Open Source ngx_http_v3_module vulnerability）
• nginx/nginx リリースタグ release-1.31.2（修正を含む）
• nginx/nginx（HTTP/3 実装 ngx_http_v3_module のソース）