NGINX に critical な RCE 脆弱性 2 件｜パッチ前の暫定対処と影響判定

はじめに

F5 が NGINX に複数のセキュリティ修正を公開し、そのうち 2 件が CVSS v4 で 9.2 と評価される深刻な脆弱性として注目されています。いずれもリモートかつ認証不要で悪用される可能性があり、条件次第でリモートコード実行（RCE）に至るおそれがあります。ただし影響を受ける条件は限定的で、HTTP/3 を有効にしている環境や、特定のディレクティブが揃った HTTP/2 上流プロキシ構成に絞られます。「自分の環境は影響するのか」「パッチ適用までに何を打てるのか」を最初に切り分けることが、過剰な緊急対応を避けるうえで役立ちます。

結論を先に述べると、2 件とも worker プロセスの再起動による DoS が主たる影響で、RCE は ASLR が無効、または回避可能な環境という前提条件のもとで成立します。CVE-2026-42530 は HTTP/3 QUIC を有効にしている場合に、CVE-2026-42055 は 3 つの条件がすべて揃った HTTP/2／gRPC プロキシ構成の場合に影響します。いずれもパッチ前の暫定対処が用意されており、恒久対処は修正版（NGINX Open Source 1.31.2 または 1.30.3 以降など）へのアップグレードになります。

公開された 2 件の脆弱性の概要

今回 F5 が公開した修正のうち、RCE につながりうる critical な 2 件を取り上げます。どちらも NGINX の HTTP 処理モジュールにおけるメモリ破壊（use-after-free とヒープバッファオーバーフロー）であり、悪用に認証を必要としない点が共通しています。

参考: F5 Security Advisory（K000161616）
“There is no control plane exposure; this is a data plane issue only.”
（コントロールプレーンへの露出はなく、これはデータプレーン側の問題に限られる）
https://my.f5.com/manage/s/article/K000161616

CVE-2026-42530: HTTP/3 QUIC の use-after-free

ngx_http_v3_module に存在する use-after-free の脆弱性です。NGINX が HTTP/3 QUIC モジュールを使うよう構成されている場合、リモートの認証されていない攻撃者が細工した HTTP/3 セッションで QPACK エンコーダーストリームを再オープンさせ、worker プロセスに use-after-free を引き起こせます。直接的な影響は worker プロセスの再起動による DoS ですが、ASLR（アドレス空間配置のランダム化）が無効化されている、または攻撃者が ASLR を回避できる環境では、任意コードの実行に至るおそれがあります。

深刻度は CVSS v4.0 で 9.2、CVSS v3.1 では 8.1 と評価されています。影響を受けるのは NGINX Open Source 1.31.0 から 1.31.1 で、1.31.2 で修正されています。HTTP/3 はオプトインの機能であり、有効化していない環境はこの脆弱性の影響を受けません。

CVE-2026-42055: proxy_v2／gRPC モジュールのヒープバッファオーバーフロー

ngx_http_proxy_v2_module および ngx_http_grpc_module に存在するヒープベースのバッファオーバーフローです。次の 3 つの条件がすべて揃ったときに、リモートの認証されていない攻撃者が worker プロセスのメモリを破壊できます。

• proxy_http_version が 2 に設定されている、または grpc_pass で HTTP/2 トラフィックを上流にプロキシしている
• ignore_invalid_headers ディレクティブが off に設定されている
• large_client_header_buffers のサイズが 2 MB より大きい

こちらも直接的な影響は worker プロセスの再起動による DoS で、ASLR が無効、または回避可能な環境では RCE に至るおそれがあります。深刻度評価には差異があり、F5 および各セキュリティメディアは CVSS v4.0 で 9.2（critical）としていますが、nginx.org の公式 Advisory では NGINX Open Source 向けの深刻度を medium と表記しています。影響範囲は NGINX Open Source の 1.13.10 から 1.31.1 と広く、1.31.2 以降、または 1.30.3 以降で修正されています。NGINX Plus も対象に含まれます（バージョン詳細は次のセクションで整理します）。

影響を受けるバージョンと製品

2 件の脆弱性は NGINX Open Source 単体にとどまらず、NGINX Plus やコンテナ／Kubernetes 系の製品（Ingress Controller、Gateway Fabric）、WAF・DoS 製品など幅広い製品ラインに影響します。自社で利用している製品とバージョンを照合してください。

参考: nginx 公式 CHANGES（nginx 1.31.2、2026 年 6 月 17 日）
“use-after-free might occur when using HTTP/3 and processing a specially crafted QUIC session”
（HTTP/3 を使用し、細工された QUIC セッションを処理する際に use-after-free が発生しうる）
https://nginx.org/en/CHANGES

CVE-2026-42530（HTTP/3）の対象製品とバージョン

CVE-2026-42055（proxy_v2／gRPC）の対象製品とバージョン

CVE-2026-42055 については、Open Source の影響範囲の表記に差異がある点に注意してください。上表は F5 KB のブランチ別表記に基づいていますが、nginx.org の公式 Advisory では「Vulnerable: 1.13.10 – 1.31.1、Not vulnerable: 1.31.2+／1.30.3+」とより広い範囲が脆弱と記載されています。1.30 系・1.31 系より前の系統を利用している場合も、自環境が後述の前提条件に該当するなら修正版への更新を検討してください。各製品の正確な修正バージョンは、F5 公式 KB（CVE-2026-42530: K000161616、CVE-2026-42055: K000161584）で最終確認することをおすすめします。

自環境が影響を受けるか判定する

恒久対処（アップグレード）を急ぐ前に、自環境がそもそも影響条件に該当するかを切り分けると、対応の優先度を冷静に判断できます。ここではインフラ運用の現場で実行しやすい確認手順を整理します。

バージョンと HTTP/3 モジュールの確認

まず稼働中の NGINX のバージョンと、ビルドに HTTP/3 モジュールが含まれているかを確認します。ngx_http_v3_module は既定ではビルドに含まれず、--with-http_v3_module を付けてビルドした場合のみ利用できます。

# バージョンの確認
nginx -v

# HTTP/3 モジュールがビルドに含まれているか確認
nginx -V 2>&1 | grep http_v3

grep の結果に --with-http_v3_module が表示されない場合、その NGINX は CVE-2026-42530 の影響を受けません。表示された場合は、次に設定ファイルで HTTP/3 が実際に有効化されているかを確認します。

# HTTP/3 を有効化する設定が存在するか確認
grep -RinE 'quic|http3' /etc/nginx/

listen ... quic や http3 on; が設定されていなければ、モジュールがビルドに含まれていても CVE-2026-42530 の経路は成立しません。

参考: nginx 公式ドキュメント（Module ngx_http_v3_module）
“This module is not built by default, it should be enabled with the –with-http_v3_module configuration parameter.”
（本モジュールは既定ではビルドされず、–with-http_v3_module 設定パラメーターで有効化する必要がある）
https://nginx.org/en/docs/http/ngx_http_v3_module.html

CVE-2026-42055 の 3 条件の確認

CVE-2026-42055 は、次の 3 条件がすべて揃ったときに初めて成立します。1 つでも該当しなければ、この脆弱性の影響は受けません。設定ファイルを横断的に確認します。

# (1) HTTP/2 上流プロキシ／gRPC の利用有無
grep -RinE 'proxy_http_version\s+2|grpc_pass' /etc/nginx/

# (2) ignore_invalid_headers が off に設定されているか
grep -Rin 'ignore_invalid_headers' /etc/nginx/

# (3) large_client_header_buffers のサイズ
grep -Rin 'large_client_header_buffers' /etc/nginx/

判定の目安は次のとおりです。

• ignore_invalid_headers は既定値が on であり、off を明示的に設定していなければ条件を満たしません。
• large_client_header_buffers は既定値が 4 8k（1 バッファ 8 KB）で、2 MB を超えるには設定で大きな値を明示する必要があります。既定のままなら条件を満たしません。
• proxy_http_version 2（または grpc_pass）で HTTP/2 バックエンドへプロキシしていなければ、そもそも該当経路が存在しません。

つまり、多くの一般的な構成（既定値のまま運用している環境）では、3 条件が同時に揃わず CVE-2026-42055 の影響外となる可能性が高いといえます。逆に、大きなヘッダーを扱うために large_client_header_buffers を意図的に拡張し、かつ HTTP/2／gRPC バックエンドへプロキシしている構成では該当する可能性があるため、優先的に確認することをおすすめします。

ASLR の有効状態の確認

両脆弱性とも、RCE に至るのは ASLR が無効、または回避可能な場合に限られます。Linux では ASLR の状態を次のコマンドで確認できます。

cat /proc/sys/kernel/randomize_va_space

戻り値が 2 であれば完全な ASLR が有効、0 は無効です。ASLR が有効（2）であれば、攻撃が成立しても影響は worker プロセスの再起動による DoS にとどまりやすく、RCE のハードルは大きく上がります。ただしこれは恒久対処の代替ではなく、あくまで被害を抑える補助的な前提条件である点に注意してください。

コンテナ／Kubernetes 環境での確認

NGINX Ingress Controller や Gateway Fabric をコンテナで運用している場合は、ホスト上のバイナリではなくコンテナイメージのタグ（チャートのバージョン）が判定対象になります。稼働中の Pod が参照しているイメージタグを確認し、前掲のバージョン表と照合してください。

# 稼働中の Pod が使用しているイメージタグの確認（例）
kubectl get pods -n <namespace> -o jsonpath='{range .items[*]}{.metadata.name}{"\t"}{.spec.containers[*].image}{"\n"}{end}'

パッチ適用前にできる暫定対処

修正版へ即座にアップグレードできない場合に備え、F5 は脆弱性ごとに緩和策を提示しています。いずれも設定変更で攻撃経路をふさぐもので、メンテナンス枠を確保しにくい本番環境での時間稼ぎとして役立ちます。設定変更後は反映前に必ず構文チェック（nginx -t）を行うことをおすすめします。

参考: F5 Security Advisory（K000161584）で示された緩和策
“Remove the ignore_invalid_headers off directive from the configuration”
（設定から ignore_invalid_headers off ディレクティブを削除する）
https://my.f5.com/manage/s/article/K000161584

CVE-2026-42530: HTTP/3 の無効化

緩和策は HTTP/3 を無効化することです。具体的には、すべての listen ディレクティブから quic パラメーターを取り除き、http3 on; と HTTP/3 を広告する Alt-Svc ヘッダーを削除します。

server {
    # listen 443 quic reuseport;        ← 削除またはコメントアウト
    # listen [::]:443 quic reuseport;   ← 削除またはコメントアウト
    listen 443 ssl;
    listen [::]:443 ssl;
    http2 on;
    # http3 on;                          ← 削除またはコメントアウト

    # add_header Alt-Svc 'h3=":443"; ma=86400';  ← 削除（HTTP/3 の広告を停止）
    ...
}

変更後は構文チェックと再読み込みを行います。

nginx -t
systemctl reload nginx   # または nginx -s reload

HTTP/3 がクライアントへ広告されなくなったことは、レスポンスヘッダーに alt-svc の h3 エントリが含まれないことで確認できます。

curl -sS -D - -o /dev/null https://example.com | grep -i '^alt-svc:'

ネットワーク機器側で UDP/443 を遮断する方法も、HTTP/3 終端をエッジで行っていない環境では一時的な遮断策として検討できます。ただし QUIC を別経路で終端している構成では効果が限定的なため、設定側での無効化を基本とすることをおすすめします。

CVE-2026-42055: ディレクティブの見直し

緩和策は 2 通りあり、いずれか一方で攻撃の成立条件を崩せます。

1 つ目は、ignore_invalid_headers off; の設定を削除して既定値（on）に戻す方法です。

# ignore_invalid_headers off;   ← 削除して既定の on に戻す

2 つ目は、large_client_header_buffers のサイズを 2 MB 未満に引き下げる方法です。大きなヘッダーを扱う要件があり、既定の 4 8k まで戻せない場合でも、2 MB を下回る値であれば条件を崩せます。

# 例: 2 MB 未満に収める（要件に応じて調整）
large_client_header_buffers 4 1m;

どちらの方法も、適用後は nginx -t で構文を確認してから再読み込みします。なお、ignore_invalid_headers off; を設定している環境は限定的であり、まずは前掲の判定手順で該当の有無を確認したうえで対応することをおすすめします。

ASLR 有効化による被害の限定

前掲の判定手順で触れたとおり、RCE が成立するのは ASLR が無効、または回避可能な環境に限られます。/proc/sys/kernel/randomize_va_space が 2 であることを確認し、無効化されている場合は有効化を検討してください。これは恒久対処の代替にはなりませんが、万一攻撃を受けた場合でも影響を worker プロセスの再起動による DoS にとどめやすくする補助策として機能します。

恒久対処: 修正版へのアップグレード

恒久対処は、利用製品ごとに修正版へアップグレードすることです。前掲のバージョン表をもとに、自環境の製品ラインに対応する修正版へ更新してください。代表的な修正版は次のとおりです。

• NGINX Open Source: 1.31.2 以降、または 1.30.3 以降
• NGINX Plus: R36 P6、または 37.0.2.1 以降
• NGINX Gateway Fabric: 2.6.4 以降
• NGINX Ingress Controller / Instance Manager / WAF・DoS 製品: F5 公式 KB に記載の各修正版

本番反映にあたっては、HTTP/3 や HTTP/2 上流プロキシなど影響経路を含む構成ほど、段階的な適用（検証環境での確認後にカナリア的に展開）をおすすめします。あわせて、攻撃の兆候として worker プロセスの再起動が観測されることがあるため、アップグレードまでの期間はエラーログで worker プロセスのシグナル終了や異常な再起動が増えていないかを監視しておくと、早期の異常検知につながります。

# worker プロセスの異常終了・再起動の監視（例）
grep -iE 'worker process .* exited on signal|signal 11' /var/log/nginx/error.log

なお、F5 製品の脆弱性は過去に実際の攻撃で悪用された事例があり、直近では先月公開された NGINX の別の脆弱性（CVE-2026-42945、通称 NGINX Rift）が公開後まもなく悪用が観測されています。今回の 2 件について現時点で広範な悪用は報告されていませんが、悪用の有無にかかわらず早めの対応方針を立てておくことをおすすめします。

まとめ

今回 F5 が公開した 2 件は、HTTP/3 と HTTP/2／gRPC プロキシにおけるメモリ破壊の脆弱性で、いずれも CVSS v4 で 9.2 と評価されています。主たる影響は worker プロセスの再起動による DoS であり、RCE は ASLR が無効または回避可能な環境という前提のもとで成立します。暫定対処と恒久対処の双方が用意されているため、まず自環境の影響有無を切り分けたうえで対応するのが現実的です。

• CVE-2026-42530 は HTTP/3 QUIC 有効時の use-after-free 脆弱性
• CVE-2026-42055 は 3 条件が揃った HTTP/2／gRPC 構成でのみ成立する。
• 主たる影響は worker 再起動による DoS、RCE は ASLR 無効が前提
• 暫定対処は HTTP/3 の無効化と該当ディレクティブの見直し
• 恒久対処は修正版（1.31.2／1.30.3 以降等）へのアップグレード
• 既定値のままの構成は影響を受けない可能性が高い。
• ASLR 有効化は被害を DoS にとどめる補助策

以上、最後までお読みいただきありがとうございました。