NGINXのCVE-2026-42945、公開直後から悪用観測。ワーカークラッシュと限定条件下のRCEが現実化です

今日の深掘りポイント

• 脆弱性はngx_http_rewrite_moduleに潜むヒープバッファオーバーフロー。設定依存ゆえ露出は環境差が大きい一方、攻撃側は狙い撃ちで踏み抜けます。
• 実運用でまず顕在化するのはサービス劣化（DoS）。RCEはASLR無効という強い前提が必要ですが、アプライアンスや一部の古い基盤では無関係ではないです。
• 「軽量な1リクエストでワーカーを落とす」非対称性が厄介。少トラフィックで可用性を蝕まれ、監視に“ノイズとして”紛れ込みやすいです。
• パッチ適用は最優先。それでも直ちに止血したい現場は、ASLRの確認・強制有効化、リライト周辺の入力面を狭める一時緩和、ワーカークラッシュの早期検知を並走させるべきです。
• 攻撃は広域拡散より“設定プロファイル特定→選択的悪用”に寄ると想定。CDNのエッジ、Kubernetes Ingress、政府・金融の公開系リバプロなど、踏み台価値の高い面に注意です。

はじめに

フロントに立つNGINXは、成功時は見えず、異常時だけが目立つ存在です。今回のCVE-2026-42945は、まさにその“異常”を引き起こす種類の欠陥で、公開から日を置かずに悪用が観測されています。影響バージョンが長く、しかも2008年導入のコード片に起因するため、運用年数の長い基盤ほど「どこで踏むか分からない」感が強いのが特徴です。深刻度は高い一方、RCEはASLR無効という条件付きです。現場が直面する一番の現実は、少ないリクエストでワーカープロセスを繰り返しクラッシュさせられる可用性リスクであり、ここをどう抑えるかが当面の勝負どころになります。

深掘り詳細

事実関係（報道ベースの確定情報）

• 脆弱性IDはCVE-2026-42945で、NGINX Open/NGINX Plusの0.6.27〜1.30.0に影響が及ぶヒープバッファオーバーフローです。
• 脆弱性はngx_http_rewrite_moduleに存在し、特定のNGINX設定と特定のHTTPリクエストの組み合わせでトリガーされます。
• 影響はワーカープロセスのクラッシュ（サービス劣化・DoS）から、条件がそろえばリモートコード実行（RCE）に至る可能性があります。
• RCEはASLRが無効なデバイスでのみ現実的とされています。ASLRが有効な一般的なサーバでは困難とされています。
• 公開から数日で実際の悪用が観測されており、ベンダは最新の修正適用を推奨しています（報道）です。
• 参考（報道）: The Hacker News: NGINX CVE-2026-42945 Exploited In The Wild

編集部の視点（仮説と運用示唆）

• RCEは“ASLR無効”という強い条件に縛られますが、脅威の実体は「低コストDoS」です。クラッシュしたワーカーは親プロセスから再生成されるため、一見“復帰している”ように見えることがあり、可用性劣化の検知が遅れやすいです。短時間に断続的なエラー率上昇や、NGINXのエラーログにおけるsignal 11/6の断続発生など、ノイズに見える兆候を“意図的な攻撃”として扱う視線が要ります。
• ngx_http_rewrite_moduleは、転送・正規化・A/B切替・多言語振分けなど広範な用途で酷使されます。可観測性が乏しいまま変数展開や外部由来の値を咬ませると、設定の「薄い氷」化が進みます。脆弱性自体はコード欠陥ですが、設定の安全帯を狭める慣行（変数の未制限展開、ヘッダ・クエリの直接利用）が、着火しやすい面を作っている点は、次の事故を防ぐ観点で見逃せないです。
• 選択的悪用の匂いがあります。広くばらまくよりも、特定の設定プロファイル（たとえば特定のrewrite/if/mapの組み合わせ）を持つ環境を指紋化して撃つほうが費用対効果が高いです。CDNのエッジ、APIゲートウェイ、Kubernetes Ingress Controllerなど、L7制御を濃く使う場所ほど要警戒です。
• なおASLRは多くのLinuxで既定有効ですが、パフォーマンステスト、古いベンチ用イメージ、特殊アプライアンスで無効化されている例が散見されます。加えて、ASLR有効でも別バグや情報漏えいと連鎖されればRCEの土台になりえます。DoSで済むと高を括らないほうが安全です。

脅威シナリオと影響

以下は編集部の仮説に基づくシナリオと、MITRE ATT&CKの観点整理です。

• シナリオ1: 低コストの可用性攻撃（DoS）

  • 前提: 公開NGINXが脆弱バージョン、該当のrewrite設定あり。
  • 振る舞い: 特定リクエストでワーカーがクラッシュ、再起動を繰り返し、レイテンシ増加や間欠的5xx、ヘルスチェック不合格を誘発します。
  • ATT&CK: Initial Access T1190（Exploit Public-Facing Application）、Impact T1499（Endpoint Denial of Service）、あるいはT1489（Service Stop）です。
  • 影響: エッジの連鎖（L7障害→オリジン切替→バックエンド過負荷）で面としてダウンを引き起こす恐れがあります。

• シナリオ2: 限定条件下のRCEと横展開

  • 前提: ASLR無効、もしくは別の情報漏えい・予測可能性低下が併存。権限分離が甘いワーカー（過剰権限）です。
  • 振る舞い: RCEからWebルートのウェブシェル設置、コンフィグ損傷、クレデンシャル窃取、バックエンドへの横移動です。
  • ATT&CK: Initial Access T1190、Execution（プロセス起動）T1106/あるいはT1059、Persistence T1053/T1547、Credential Access T1552/T1003、Lateral Movement T1021、Command and Control T1071です。
  • 影響: 公開系から内部への足掛かりを提供し、監査ログ改ざんやWAF回避を伴う持続化に発展します。

• シナリオ3: クラウドネイティブ環境での連鎖障害

  • 前提: KubernetesのIngress NGINX/NGINX Plusを使用、ヘルスプローブが厳格、HPA/オートスケールが有効です。
  • 振る舞い: クラッシュループがPod再起動・スケール誤動作を引き起こし、全リージョンでエラー波形が拡散します。
  • ATT&CK: T1190、Impact T1499/T1489です。
  • 影響: 長い障害復旧時間（MTTR）の増大、SLO違反、SaaSのS2/S1事故に直結します。

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

即応と恒久対策を併走させる計を提案します。具体的手順は各社標準に合わせてください。

• いますぐ（0〜24時間）

  • ベンダの修正適用とローリング再起動です。商用のNGINX Plus含め、提供された最新安定版への更新を最優先に計画・実施します。
  • ASLRの状態確認と強制有効化です。ホストカーネルのASLRが2（フル）であることを確認し、無効であれば組織標準に則り有効化します。コンテナはホストカーネルに従う点に注意します。
  • 一時緩和の検討です。特にrewrite/if/mapで外部由来の値（ヘッダ、クエリ、Cookie等）を直接扱う箇所の入力長や許容文字種を狭める、不要なルールを無効化するなど、影響が読める範囲で露出を下げます。変更はcanary導入で段階適用します。
  • 監視の強化です。NGINXのエラーログにおける「worker process exited」「signal 11/6」「core dumped」の短時間多発、5xx/499のバースト、Pod/プロセスの再起動増（コンテナならRESTARTS増）をアラート化します。低トラフィックでもエラーレートで発報する閾値を当面引き下げます。

• 近々（1週間以内）

  • コンフィグの健全性レビューです。rewriteの変数展開に対する長さ制約、正規表現の見直し、if in locationの乱用是正、マップテーブルの肥大化抑制など、安定性重視の原則に沿って棚卸しします。
  • 権限分離と実行環境の縮小です。workerプロセスの実行ユーザ権限最小化、不要モジュールの排除、systemd/AppArmor/SELinuxやコンテナのseccomp・capability最小化でRCE時の被害を絞ります。
  • 低コストDoSの吸収策です。アップストリームに対するサーキットブレーカ、接続・リクエストレート制限、bot対策ルールの導入で、クラッシュ誘発の繰り返しを緩和します。

• 中期（30日以内）

  • 攻撃観測に基づくルール整備です。実際のエラー波形・ログ特徴をもとにWAF/IDSのシグネチャや振る舞い検知（同一IP/ASNからのリクエストでワーカー異常が相関する等）をチューニングします。
  • 構成変更のテスト強化です。リライト系変更に対するステージング・回帰テストを標準化し、メモリ安全性や異常入力耐性をチェックリスト化します。
  • サプライチェーン点検です。NGINXを組み込むプロダクト（ロードバランサ、APIゲートウェイ、アプライアンス、Ingress等）のパッチ適用計画とSLAを整備します。

• ハンティングのヒント（目安）

  • ログ: error.logで「worker process exited on signal 11/6」「segfault」「core dumped」などの連発、access.logで短時間かつ特定送信元からの4xx/5xx集中を確認します。
  • メトリクス: レスポンスタイムのスパイク、Pod/プロセスの再起動回数、ヘルスチェック失敗率の同時上昇を相関させます。
  • 構成: rewriteで外部入力を利用するパスを列挙し、公開エンドポイントとの接続を洗い出します。

• コミュニケーション

  • ビジネス側へは「RCEは限定条件だが、可用性劣化が実害として先に来る」点を率直に共有し、緊急パッチとリリース凍結の合意形成を図ります。SLO/SLAインパクトと回避策（時間帯・カナリア・ロールバック）を明文化します。

参考情報

• 報道: The Hacker News — NGINX CVE-2026-42945 Exploited In The Wild

編集後記: 今回の件は、「バグ」そのものよりも、私たちが日々運んでいる“設定”という荷物の重さを思い出させます。Rewriteは便利で強力です。だからこそ、入力を丁寧に削ぎ落とし、見通しの良い道筋にしておくことが、次のゼロデイが来たときの転倒防止になります。現場の皆さんの一手一手が、今日の可用性と明日のレジリエンスを支えます。