ngx_http_rewrite_module にある heap buffer overflow（ヒープバッファオーバーフロー）今回のGitHubリポジトリ「Nginx-Rift」は、CVE-2026-42945 の exploit、つまり「脆弱性を実際に突くための実証コード」です。
こういうリポジトリは、研究・検証のために公開されることもあれば、攻撃者に悪用されるリスクもあるので、セキュリティ界隈ではかなり注目されます。
元記事の説明によると、問題の核心は NGINX の rewrite 処理 にあります。
rewrite とは、ざっくり言えば URLを条件に応じて書き換える機能 です。たとえば、古いURLを新しいURLに飛ばしたり、特定のパターンを別のパスに振り分けたりするときに使います。
そして set ディレクティブも絡むと、内部で使う文字列処理が複雑になります。
この脆弱性では、NGINX のスクリプトエンジンが 2回処理する設計 になっている点が問題になります。
ところが、計算フェーズでは is_args が 0 と見なされ、コピー時には is_args が 1 になってしまう、というズレが起きるそうです。
このズレのせいで、小さめのバッファを確保したのに、実際にはもっと大きいデータを書き込んでしまう。これが heap buffer overflow です。
heap buffer overflow は、たとえるなら 「小さい箱を用意したのに、大きい荷物を無理やり押し込む」 ようなものです。
箱の中身がはみ出すと、隣に置いてある別の大事なデータまで壊れてしまうことがあります。
今回の説明では、攻撃者が URI（URLの一部） を使って、そのはみ出し先を狙う形になっています。
しかも、実際の悪用では クロスリクエストの heap feng shui なんて言い方が出てきます。これは簡単に言うと、複数のリクエストを使ってメモリの配置を「都合よく並べる」テクニック です。名前は面白いですが、中身はかなりえげつないです。
さらに元記事では、ngx_pool_t の cleanup pointer を壊し、そこから system() を呼ぶように仕向ける流れが説明されています。
system() は、OSに対してコマンドを実行させる関数です。つまり、うまくいくと サーバー上で任意のコマンドを実行できる 可能性がある。これが RCE の怖さです。
正直、この手の脆弱性は「ただのクラッシュ」で終わらないのが厄介です。
メモリ破壊 → 制御情報の改ざん → コード実行 という流れが成立すると、Webサーバーが一気に危険な存在になります。個人的には、ここが一番ゾッとするポイントです。
元記事では、影響と修正状況が次のようにまとめられています。
| 製品 | 影響範囲 | 修正版 |
|---|---|---|
| NGINX Open Source | 0.6.27 – 1.30.0 | 1.31.0, 1.30.1 |
| NGINX Plus | R32 – R36 | R36 P4, R35 P2, R32 P6 |
また、F5 の vendor advisory として詳細情報が案内されています。
こういうときは、GitHub上のPoCだけを見て安心せず、ベンダーの公式アドバイザリを確認して、利用中のバージョンが影響を受けるかを必ず確認する のが大事です。
「うちはたぶん大丈夫」で済ませると、あとで痛い目を見ることが多いと思います。
このリポジトリは単なる説明ページではなく、実際に動く検証コード を含んでいる点が重要です。
README には、以下のような内容が書かれていました。
setup.sh でコンテナ環境を構築docker compose -f env/docker-compose.yml up で脆弱な NGINX サーバーを起動python3 poc.py --shell でシェルを取るつまり、これは「理論上こうなる」ではなく、現実に再現可能な形で脆弱性を示している ということです。
セキュリティ研究の世界では、再現性のあるPoCは非常に強い証拠になります。反面、悪用もされやすいので、公開のバランスは本当に難しいなと感じます。
今回の件で重要なのは、単に「NGINXにバグがあった」ことではありません。
ポイントは、長年使われてきた基盤ソフトウェアに、未認証RCE級の問題が入りうる という現実です。
NGINX は世界中で使われています。
Webサイトの前段にいることも多く、APIの入口やリバースプロキシとしても大活躍しています。そんな“縁の下の力持ち”に穴があると、影響は一気に広がります。
しかも今回の説明では、脆弱性が 2008年に導入された とされています。もし本当に長期間潜んでいたのだとしたら、かなり大きい話です。
個人的には、ここがいちばん怖いです。
派手な新機能の問題より、昔からある処理のズレやメモリ管理の勘違い のほうが、実は深刻な被害につながることが多いからです。
一般の人でも、次の観点は知っておくと役立ちます。
もちろん、個人利用の範囲なら直接の被害は少ないこともあります。
ただ、企業やサービス運営では話が別です。Webの入口にあるものほど、1つの脆弱性が全体事故につながりやすいので、運用側はかなり真剣に見る必要があります。
このGitHubリポジトリ「Nginx-Rift」は、CVE-2026-42945 を実証する exploit を公開したものです。
内容としては、NGINX の rewrite 処理にある heap buffer overflow を突いて、条件次第で 未認証RCE に至るという、かなり重い話でした。
技術的には難しいですが、要点だけ言えばこうです。
こういう事例を見るたびに、「ソフトウェアは便利だけど、裏ではすごく綱渡りで動いているんだな」と思います。
普段は意識しないNGINXのような基盤ほど、脆弱性が出たときのインパクトは大きい。まさに静かだけど危ないタイプのニュースです。
参考: GitHub - DepthFirstDisclosures/Nginx-Rift: exploit for CVE-2026-42945