F5が修正を公表—NGINXのHTTP/3(UAF)とHTTP/2(ヒープBOF)でRCEに至る恐れ、ウェブ基盤の足元を揺らす脆弱性です

今日の深掘りポイント

• HTTP/3のQUIC実装に潜むuse-after-freeと、HTTP/2プロキシ経路のヒープベースBOFという「実装境界」での破綻が同時期に露出しています。暗号化と多層プロトコルが生む複雑さが運用監視の盲点を拡大しやすい構図です。
• 当座の遮断は「UDP/443の無効化＝HTTP/3の停止」と「HTTP/2の撤回/制限」で実務的に実現できます。WAFはHTTP/3で回避されやすく、配置と機能サポートの再点検が鍵です。
• ASLR無効やコンテナ/Podがrootで動作している環境では、RCE成立後の被害半径が急拡大します。プロセス分離・強制ASLR・最小権限の基本対策が、パッチ適用前後の両局面で効きます。
• アセット管理の勝負所は「どこでHTTP/3/HTTP/2を終端しているか」を即座に示せることです。LB/CDNの外縁、リバプロ、サービスメッシュの多層で有効化点を素早く洗い出す仕組みが成熟度の差を生みます。

はじめに

NGINXは日本のウェブ基盤でもっとも広く用いられているOSSのひとつです。そこにHTTP/3(QUIC)とHTTP/2にまたがるRCE起点の脆弱性が指摘された以上、個社のリスクを超えて産業・社会の可用性に波及しうるテーマになります。今回の修正はCVE-2026-42530（HTTP/3 QUICモジュールのuse-after-free）とCVE-2026-42055（HTTP/2プロキシ時のヒープベースBOF）で、特定条件下では未認証のリモート攻撃者による悪用が成立しうると報じられています。F5はNGINXオープンソースとNGINX Plus向けにパッチと緩和策を提示しています。私たちは、単に「HTTP/3を切る」で終わらせず、プロトコル進化と運用現実の摩擦をどう解くかまで見据えて対応したいところです。

参考とした公開情報は以下です。

• The Hacker News: F5 Patches Two Critical NGINX Open Source Vulnerabilities (2026-06-19)

（以降の技術的含意や運用示唆は、上記の公開情報に基づく分析と明示した仮説に立脚します。）

深掘り詳細

事実関係の整理

• 対象脆弱性
  • CVE-2026-42530: HTTP/3のQUICモジュールにおけるuse-after-free。条件が揃うと未認証RCEの恐れがあると報じられています。
  • CVE-2026-42055: HTTP/2トラフィックをプロキシする際のヒープベース・バッファオーバーフロー。こちらも未認証RCEの恐れがあると報じられています。
• 影響範囲の概念
  • フロントでHTTP/3を終端するNGINX、あるいはHTTP/2をクライアント/アップストリームのいずれかで扱うNGINXが対象になりえます。
  • ASLRが無効な環境では攻撃成功確率が上がる可能性が示唆されています（報道ベース）。
• ベンダー対応
  • F5はNGINXオープンソースおよびNGINX Plusにパッチと緩和策を提示していると報じられています。報道ではOpen Source 1.31.2、NGINX Plus 37.0.2.1での修正提供に言及があります。

上記は報道をもとにした事実関係の要約です。一次情報（F5のアドバイザリやNGINXのリリースノート）の精読と自組織環境への適用判断は、最新の公式文書に即して進めるべきです。

インサイト（編集部の視点）

• プロトコル多層化の副作用を直視する時期です
  • HTTP/3はUDP/443上でTLS 1.3とQUICを重ねます。可視化やWAF適用、DLP、遅延耐性など運用制御の難易度が上がり、アプリ境界での脆弱性は「検知しづらく、遮断しづらい」傾向が強まります。HTTP/2もフレーミングや多重化が実装バグの温床になりやすく、今回の2件はこの構造的リスクを裏打ちしています。
• 「終端点の特定」と「フォールバック制御」が勝負所です
  • フロントCDN、クラウドLB、エッジWAF、社内リバプロ、サービスメッシュなど、どこでh3/h2を終端/中継しているかを、構成図ではなく“インベントリから即座に列挙できるか”が対応速度を左右します。HTTP/3を落とす時はUDP/443のブロックやALPN広告からのh3撤去、HTTP/2を落とす時はlistenディレクティブのhttp2除去やプロキシのHTTP/1.1フォールバックを、サービスごとのSLOと突き合わせて意思決定する設計が重要です。
• WAFや観測基盤の限界を補うセキュリティ基本動作
  • ASLR強制、非root実行、Seccomp/AppArmor/SELinux、ファイルシステムのread-only化、ネットワークEgressのデフォルト拒否など、RCE成立後の「広がり」を抑える仕込みが、プロトコル高度化時代の“最後の防波堤”として再評価されるべきです。

脅威シナリオと影響

以下は公開情報に基づく仮説シナリオです。実際の悪用手口は公式アドバイザリや今後のインシデント報告を確認のうえ更新すべきです。

• シナリオA（HTTP/3経路/UAF起点の初期侵入）

  • 前提: NGINXがHTTP/3(QUIC)を有効化し公開。ASLRやハードニングが不十分。
  • 手口（仮説）:
    1. 攻撃者が特定のQUICフレーム/再送制御/接続クローズのエッジケースを突いたペイロードを連投
    2. use-after-freeを誘発し、プロセスメモリに任意コード実行
    3. Webシェル/バックドア設置、内部APIへの横展開、セッション・トークンの収集
  • 想定ATT&CK:
    • T1190 Exploit Public-Facing Application（初期侵入）
    • T1505.003 Server Software Component: Web Shell（永続化）
    • T1046 Network Service Discovery/T1040（探索）
    • T1021/SMB/SSHやT1071.001（横展開/C2）
    • T1041 Exfiltration Over C2 Channel（流出）

• シナリオB（HTTP/2プロキシ経路/ヒープBOF起点の境界突破）

  • 前提: クライアント→NGINX(HTTP/2)またはNGINX→上流(HTTP/2)のプロキシ経路が有効。
  • 手口（仮説）:
    1. 特殊なHTTP/2フレーム列（ヘッダ圧縮/ストリーム制御/フラグ組合せ）で境界検査を攪乱
    2. ヒープオーバーフローからRCEへ
    3. 認証基盤やメタデータサービス（クラウド環境）の資格情報窃取に進展
  • 想定ATT&CKは上記Aに同様。

• 影響評価の軸

  • 公開面積: h3/h2を終端・中継しているサービス数、ユーザ規模、リージョン分散。
  • 損害半径: 実行ユーザ権限、Pod/コンテナの特権度、Egress制御の有無、シークレット管理の厳格さ。
  • 可視性: QUICの観測・ブロック手段、HTTP/2のログ粒度、クラッシュ/ワーカー再起動の監視有無。

編集部の総合所見として、緊急度と実装普及度、運用での遮断難易度のバランスから、事業インパクトは高水準と読みます。すぐ動ける具体策が多く、攻撃成立確率を相応に下げられる点は救いです。逆に“HTTP/3をどこで使っているか即答できない”組織は、影響評価に時間を要し、対応の遅れが重大化に直結しやすいです。

セキュリティ担当者のアクション

時間軸で優先度順に並べます。技術コマンドは一般的なNGINX運用のベストプラクティスに基づく提案です。

• 0時間（インベントリと即時緩和）

  • 露出特定
    • どの経路でh3/h2が有効かを棚卸し（CDN/LB/リバプロ/サービスメッシュ/Ingress Controller）。
    • サーバ側確認例:
      • ビルド確認: nginx -V 2>&1 | grep -E "http_v3_module|http_v2_module"
      • 設定確認: listen 443 quic; や listen 443 ssl http2; の有無をgrep
      • プロキシでHTTP/2を使う設定（例: proxy_http_version 2 等）の有無を確認
  • 当座の遮断（事業影響に応じて段階適用）
    • HTTP/3の無効化:
      • NGINXのlisten 443からquicを除去、あるいは一時的にUDP/443をFWでブロック（TLSはTCP/443でHTTP/2/1.1へフォールバックします）。
      • ALPNでh3広告を停止（フロントのCDN/LB設定も忘れずに）。
    • HTTP/2の一時停止/抑制:
      • クライアント終端でlistenのhttp2を外す、あるいはproxy経路をHTTP/1.1へフォールバック。
      • どうしても外せない場合はhttp2_max_concurrent_streams/受信ヘッダサイズ等の下げ調整で攻撃面積を縮小（副作用に注意）。
  • ランタイム防御の底上げ
    • ASLRを強制（Linux: /proc/sys/kernel/randomize_va_space が2であることを確認）。
    • NGINXを非root実行、可能ならコンテナはroot非特権・readOnlyRootFilesystem・seccomp/AppArmor/SELinuxを有効化。
    • 送信Egressをデフォルト拒否にして、RCE成立時の外部C2通信を遮断。

• 24～72時間（パッチ適用と段階的復旧）

  • ベンダーの修正リリースに更新（NGINX OSS/Plus）。構成差分が大きいプロキシ群はカナリア→段階展開→観測の順で。
  • ロールバック手順とヘルスチェックを自動化（Blue/GreenまたはRollingUpdateで有事の転換を迅速化）。
  • h3/h2の復旧は、WAF/観測側の対応（HTTP/3対応可否、LBのALPN広告、メトリクス/ログ確認）とセットで。

• 検知・監視（すぐ着手し継続）

  • NGINXエラーログにおけるワーカープロセスの異常終了・Segfaultの有無を収集/アラート化（特にhttp_v3/http_v2関連のスタック痕跡）。
  • クラッシュ発生ホストのcoredumpと直前のアクセスパターン（同一IPの異常な接続確立/リセット/再送）を相関分析。
  • ネットワークでのUDP/443急増や短寿命接続のスパイクを可視化（HTTP/3悪用の挙動はL3/4で兆候が出やすい一方、内容は見えにくいです）。

• 構成とプロセスの恒常対策

  • アセット管理/SBOMに「プロトコル機能」を属性として持たせ、h3/h2の有効化点を即時抽出できるようにします。
  • WAF/ボット防御/レート制御はHTTP/3対応可否を棚卸し。非対応ならフロントの設計を見直し、少なくとも一段目でTLS終端と検査を通す配置にします。
  • 脆弱性対応SLOを「ゼロトラストの境界実装（LB/リバプロ）」に特化して短縮。影響半径が大きい層はパッチ適用の定期窓口を月1から週次へ見直すなど、運用リズムも更新します。

• インシデント対応準備

  • 侵害疑い時の証跡リスト（アクセス/エラー/コアダンプ/コンテナ監査ログ/Ingressログ）と保全手順をプレイブック化。
  • 影響評価のテンプレ（公開面積×権限×Egress制御×データ種別）で事業判断を早めます。

メトリクス全体像から読み取れるのは、「行動可能性が高く、発生確度と即時性も高い一方で、ポジティブ要素は乏しい」タイプのインシデントです。すなわち“迷わず先に動く価値が高い案件”です。規模の大きい組織ほど「どこでh3/h2を止めるか」の意思決定に時間を奪われがちなので、平時からのデザイン・ガバナンスが差になります。

参考情報

• F5 Patches Two Critical NGINX Open Source Vulnerabilities – The Hacker News (2026-06-19)

本稿は公開情報に基づく編集部の分析と仮説を含みます。一次情報（ベンダーのセキュリティアドバイザリ、リリースノート）の最新内容を必ず確認のうえ、自社環境に即したリスク判断・適用計画を策定してください、です。