ハクソク

世界を動かす技術を、日本語で。

新しいNginxの脆弱性利用方法

5時間前原文(github.com)

概要

  • CVE-2026-42945 は、NGINXの ngx_http_rewrite_module に存在する重大なヒープバッファオーバーフロー脆弱性
  • 未認証のリモートコード実行 がrewriteおよびsetディレクティブ使用時に可能
  • depthfirst のセキュリティ分析システムによる自動発見事例
  • 影響を受けるバージョンと修正済みバージョンが明確に提示
  • PoC および利用手順が公開されている

CVE-2026-42945: NGINX ngx_http_rewrite_moduleのヒープバッファオーバーフロー

  • 脆弱性内容

    • NGINXのscript engineは2パス処理（バッファサイズ計算→データコピー）を実施
    • rewrite置換に「?」を含む場合、 is_argsフラグ がメインエンジンでセット
    • 長さ計算パスではサブエンジンのis_argsが0のまま、 生データ長 を返す
    • コピー時はis_args=1で ngx_escape_uri(NGX_ESCAPE_ARGS) を呼び出し、各エスケープ対象バイトが3バイトに拡張
    • 攻撃者制御のURIデータにより、 ヒープバッファオーバーフロー が発生

  • 攻撃手法

    • クロスリクエストheap feng shui を利用し、隣接するngx_pool_tのcleanupポインタを破壊
      • POSTボディでスプレー（URIバイト列はnullバイト不可のため）
      • ngx_pool_cleanup_s構造体を偽造し、pool破棄時に system() を呼び出すよう誘導

  • 自動発見

    • depthfirstのセキュリティ分析システムがNGINXソースを1クリックでオンボーディングし自律的に発見
    • 他の3件のメモリ破損（CVE-2026-42946, CVE-2026-40701, CVE-2026-42934）も同時検出

影響範囲と修正バージョン

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

    • NGINX Open Source
      • 0.6.27 ～ 1.30.0
    • NGINX Plus
      • R32 ～ R36

  • 修正バージョン

    • NGINX Open Source
      • 1.31.0, 1.30.1
    • NGINX Plus
      • R36 P4, R35 P2, R32 P6

  • ベンダー公式アドバイザリ

    • https://my.f5.com/manage/s/article/K000160932

検証・PoC利用手順

  • 検証環境

    • Ubuntu 24.04.3 LTS上で動作確認済み

  • 手順

    • ./setup.sh
      • コンテナビルド
    • docker compose -f env/docker-compose.yml up
      • 脆弱なNGINXサーバ起動
    • python3 poc.py --shell
      • シェル取得（RCE発動）

depthfirstのセキュリティ分析システム紹介

  • depthfirst による自動バグ検出
    • ソースコードをワンクリックでオンボーディング
    • メモリ破損・RCEなどの重大バグを自律的に検出
  • 同様の分析を自身のコードで実施可能
    • https://depthfirst.com/open-defense

総括・推奨対応

  • 即時アップデート 推奨（該当バージョン利用時）
  • rewrite/setディレクティブ利用環境では 特に注意
  • サードパーティの自動脆弱性検出ツールの活用提案

Hackerたちの意見

これはかなりヤバいけど、いくつか前提条件があるよ。置き換え文字列に疑問符が入った「rewrite」ディレクティブが必要で、その後に正規表現のキャプチャグループを参照する「set」ディレクティブが続く感じ（例えば、set $var $1）。それに、POCはASLRが無効になっていることを前提にしてる。

└

どのディストリビューションがデフォルトでASLRを無効にしてるの？手動でやるとしたら、nginxは候補に思いつかないな。

└

例: https://github.com/DepthFirstDisclosures/Nginx-Rift/blob/mai...

POCはASLRを無効にしてるよ: https://github.com/DepthFirstDisclosures/Nginx-Rift/blob/mai...

└

ワーカープロセスはマスターからフォークされるから、同じメモリレイアウトを受け取るんだ。ワーカーに対して無限にクラッシュできるよ。それを利用してリードオラクルを得る方法があるかも。少なくとも、これは確実なサービス拒否攻撃になるね。Depth Firstの詳細なレポート: https://depthfirst.com/research/nginx-rift-achieving-nginx-r...

もっといいリンク: https://depthfirst.com/research/nginx-rift-achieving-nginx-r... (https://news.ycombinator.com/item?id=48126029) https://depthfirst.com/nginx-rift (https://news.ycombinator.com/item?id=48123365)

Debian 12はこれにパッチ当ててるのかな？でも、rewriteやsetをどこでも使わなければ影響を受けないってことだよね？

└

nginxを使っている人がsetを全く使わないってことはまずないと思う。ほとんどのnginxの使い方は、TLSを終わらせてからリクエストをnode/php/goなどに渡すことだから。だから、少なくとも「proxy_set_header X-Host $host;」みたいな行に攻撃者のコントロールデータが含まれているsetが一つはあるんじゃないかな。追記：気にしなくていいみたい。名前付きキャプチャは影響を受けないみたいだから。$1がどこかにない限り、大丈夫だと思う。

└

Ubuntuは今朝パッチを当てたみたい。Debianはまだtrixieのパッチを当ててないみたいだね。

└

https://security-tracker.debian.org/tracker/CVE-2026-42945

公式のF5ページはここだよ: https://my.f5.com/manage/s/article/K000161019 他のところでも言われてるけど、ASLRは君を守ってくれる。影響を受けてるプラットフォームが修正されるのを待ってる間、彼らは緩和策を示してる: 「rewrite定義で無名キャプチャの代わりに名前付きキャプチャを使う」 「この例の脆弱性を緩和するために、$1と$2を適切な名前付きキャプチャ、$user_idと$sectionに置き換えて」 F5は1.31.0と1.30.1にパッチを当てたよ。OpenRestyは1.27と1.29のパッチがある: https://github.com/openresty/openresty/commit/ee60fb9cf645c9... OpenResty（NginxベースのLuaアプリケーションサーバー）の進捗はここで追えるよ: https://github.com/openresty/openresty/issues/1119

セキュリティの仕事をしていると、ここで多くの人が「公開されたエクスプロイトがASLRをバイパスしないから、そんなに怖くない」って直接言ったり、ほのめかしたりするのを見るのが疲れる。記事には、この攻撃でASLRを確実にバイパスする方法があるって書いてある。証拠がなくても、そういう前提を信じるのは悪くないと思う。ASLRは、エクスプロイトを難しくするための防御策の一つだからね。ほとんどの場合、ASLRのバイパスを含めるのは時間とスキルの問題だ。数週間ごとにLLMエージェントによってそのハードルは下がり続けている。完全に武器化されたエクスプロイトが開発されるのも時間の問題だと思う（多分、そんなに時間はかからないだろうけど）。それが公開されるか、プライベートに保たれるかはわからない。「ASLRを有効にしていれば、これにはリスクがない」と言うのは完全に間違っているし、そういうことを信じている人には非常に有害だ。セキュリティの脆弱性を気にしなくていいという誤った考えは、過去に多くの害をもたらしてきた。現代の緩和策が存在することを喜ぶべきだけど、すぐにパッチを当てるべきだよ。もしあなたがベンダーなら、研究者がASLRのバイパスを提供していないからといって脆弱性レポートを無効だと扱わないで。根本原因を修正して、緩和策がパッチを当てるまでの時間を稼いでくれることを願おう。

└

そういうことを信じている人には非常に有害だ。 読む側に責任があるような気もするけど、ネットでの誤情報を広めるのを止めるのは難しいよね。多くの人は自分が間違ってることすら気づいてないし。ランダムなネットのコメントを信じるのが一番危険だよ。そういうのを見抜く力をつければ、セキュリティだけじゃなくて他の面でも役立つよ。

└

リモートからアクセス可能な脆弱性は軽視すべきじゃない。ただ、今のところ前提条件が変だね。10年間いろんな形でnginxを使ってきたけど、リライトとセットを一度も組み合わせたことはないよ。

└

ASLRは、攻撃を難しくするための防御層の一つなんだ。ほとんどの場合、ASLRのバイパスを含めるのは時間とスキルの問題に過ぎない。数週間ごとにLLMエージェントによってその要件はどんどん低くなってる。完全に武器化されたエクスプロイトが開発されるのも時間の問題だと思う（たぶんそんなに時間はかからない）。それが公開されるか、プライベートにされるかはわからないけど。この意見には賛成できないな、少なくとも違う言い方をすると思う。ASLRは、推測しなきゃいけない追加のパスワードみたいなもので、ある程度のエントロピーがあって、通常は安定してる。脆弱性に情報漏洩の部分がない限り、ASLRはそれを完全に軽減するか、もう一つの脆弱性が必要になる。それは別の話だね。ASLRは個々の脆弱性を完全に軽減できるけど、エクスプロイトチェーンは別の話。情報漏洩の可能性のある二次脆弱性を利用して、人々に早くパッチを当てさせる理由にはなると思う。でも、エクスプロイトチェーンはあらゆる種類の脆弱性にリスクをもたらすからね。

ApacheやNginxの代わりに、メモリ安全な言語で書かれていてセキュリティホールが少ない良い代替品ってある？ Jetty（Javaで書かれてる）やCaddy（Goで書かれてる）をちょっと見たけど、他のタイプの脆弱性（例えば、Jettyのシェルインジェクション）の歴史があるみたいだから、あんまり良くないかも。

└

Caddyは使いやすいけど、「プラグインの組み合わせによって何千ものバイナリがある」っていうモデルはちょっと微妙だね。ちゃんとしたプラグインシステムじゃないから。でも、ソースからビルドするなら、かなり便利でシンプルだよ。

└

Apacheやnginxの規模で使われるソフトウェアは、脆弱性の歴史があるのは当然だよね。彼らが長い間市場シェアを維持しているのは良い兆候だと思う。

└

ApacheとNginxは機能がめっちゃ多いよね。他のHTTPサーバーは機能がかなり制限されるから、どの機能に興味があるかを明確にしないといけない。でも、メモリ安全な言語でのHTTPサーバーについての話はあまり見ないな。Cベースのサーバー、Apache、Nginx、lighttpdはどれもかなりしっかりしてるし、言語のためだけに新しいプロジェクトに乗り換えたいって人はあまりいないと思う。あと、ほとんどのメモリ安全な言語を使うと、時にはかなり大きなランタイムや仮想マシンも一緒に使うことになるからね。Javaのウェブサーバーは、たぶんlog4jを使ってるだろうし、どんなランダムなJavaプロジェクトもそうだし。

誰かLowLevelに教えてあげて

知れてよかった、ありがとう。次までどれくらいか気になるな。