GitHubに公開された DepthFirstDisclosures/Nginx-Rift は、CVE-2026-42945 を狙う exploit / PoC（検証用の攻撃コード） です。
元記事の説明によると、この脆弱性は NGINX の ngx_http_rewrite_module にある critical な heap buffer overflow で、条件がそろうと 認証なしの remote code execution（RCE）、つまり「外部から勝手にサーバ上でコードを実行される」状態になり得ます。
個人的には、ここがいちばん怖いです。
“認証なし” で “RCE” という組み合わせは、サーバ運用者にとってかなり最悪級 だからです。しかも NGINX は Web の前線で使われることが多いので、影響範囲が広くなりやすいんですよね。
ngx_http_rewrite_module にあるリポジトリ名は Nginx-Rift。README には、
「CVE-2026-42945 を再現するための RCE Proof of Concept」 とあります。
PoC というのは、ざっくり言うと
「この脆弱性、本当に悪用できるのかを確かめるための実演コード」 です。
攻撃そのものに使える危険なものでもありますが、セキュリティ研究では「被害を防ぐために、どう壊れるのかを明確にする」目的でも使われます。
README の説明から読み取れるのは、この脆弱性が単なるクラッシュではなく、メモリ破壊を通じて任意コード実行まで狙える という点です。
これはかなり重いです。メモリ破壊系のバグは、放置すると「たまたま落ちる」では済まず、サーバ乗っ取りの入口 になることがあるからです。
元記事では、問題の中心をこう説明しています。
rewrite の置換文字列に ? が含まれると、is_args フラグが立つis_args が立っていない 新しくゼロ初期化された sub-engine が使われるngx_escape_uri(..., NGX_ESCAPE_ARGS) により文字が 3倍程度に膨らむ「箱を作るときにサイズを見積もるけど、その見積もりが甘かったので、実際に物を入れたら箱からあふれた」という話です。
しかも書き込み先は単なる文字列ではなく、メモリ上の近くにある別の重要データ にもかかる可能性がある。
だから単なる文字化けでは終わらず、動作の乗っ取り に発展しうるわけです。
この手のバグは、仕組みを聞くと地味に見えるのに、実害はかなり派手です。そこが怖いし、同時に面白くもあるところだと思います。
README の説明では、攻撃はかなり技巧的です。
単純に「壊す」だけではなく、cross-request heap feng shui を使ってメモリ配置を誘導するとしています。
つまり、攻撃者は複数回のアクセスを使って、
「このメモリの隣にこのデータを置きたい」
という状況を作り出すわけです。かなり職人芸です。
README では、近くにある ngx_pool_t の cleanup pointer を壊すと説明されています。
これはメモリ解放時に「後片付けで何を実行するか」を指すポインタのようなものです。
ここを乗っ取られると、終了処理のタイミングで system() を呼ばせる 方向に持ち込める、としています。
ここでのポイントは、URI に null byte を入れられないため、POST body を spray に使う と書かれていることです。
攻撃対象の制約に合わせて、別の入力経路を使い分けるあたり、いかにも本格的な exploit です。
正直、これは「ただのバグ報告」の雰囲気ではありません。
かなり実戦的な悪用コード に見えます。そこが一番の注目点だと思います。
README では、影響と修正版が次のように整理されています。
0.6.27 – 1.30.01.31.0, 1.30.1R32 – R36R36 P4, R35 P2, R32 P6また、F5 の vendor advisory へのリンクも案内されています。
元記事の情報だけを見る限り、かなり広いバージョン帯が影響 しています。
長年使われてきたソフトウェアほど、こういう「昔からある前提のズレ」が後になって深刻化するのが厄介です。
NGINX は Web サーバやリバースプロキシとして、インターネットに面した場所で動いていることが多いです。
つまり、脆弱性があると 外部から触られやすい。
これは本当に重要なポイントです。
クラッシュで済むならまだマシですが、RCE になると話が変わります。
攻撃者はサーバ上でコマンドを実行できる可能性があり、
など、被害が一気に広がります。
今回の本質は、長さ計算と実際の書き込みで前提がズレたことです。
こういうバグは、ぱっと見では「ちょっとした内部不整合」に見えても、実際にはメモリ安全性の崩壊につながります。
ソフトウェアの怖さがよく出ている事例だと思います。
このリポジトリには、README.md、poc.py、setup.sh、env/ が含まれているようです。
README の内容からすると、環境構築から再現までを比較的手早く行える形 になっているように見えます。
GitHub 上では星もかなり付いていて、注目度の高さがうかがえます。
もちろん、星の数がそのまま危険度を示すわけではありませんが、セキュリティ界隈で「まず話題になるタイプのリポジトリ」 なのは間違いなさそうです。
個人的には、こういう PoC が出るときは
「修正済みだから安心」ではなく、**“実際にどの程度の条件で成立するのか” を運用側が見直すタイミング** だと思っています。
パッチ適用だけで終わらず、設定ファイルの確認や公開範囲の点検までやるべき場面です。
この記事の情報だけでも、運用者は少なくとも次を確認したほうがよさそうです。
rewrite や set ディレクティブを使っていないか特に、「うちは単純な静的配信だから関係ない」 と決めつけるのは危ないです。
設定次第で ngx_http_rewrite_module に触れている可能性はありますし、何よりインフラは思わぬところで機能がつながっています。
この手の話は、後から「そんな設定入ってたっけ？」が本当に起きるんですよね。
Nginx-Rift は、CVE-2026-42945 を対象にした exploit / PoC です。
元記事の説明をまとめると、NGINX の rewrite 処理における 長さ計算と実際のコピーの不一致 が、heap buffer overflow を引き起こし、最悪の場合は unauthenticated RCE につながる可能性があります。
技術的にはかなり高度ですが、要するに
「サイズ見積もりをミスった結果、メモリを壊され、サーバを乗っ取られうる」
という、かなりシンプルで怖い話です。
個人的には、この手の脆弱性は「難しい内部実装のズレ」が外から見える形で爆発する典型例だと思います。
そして、PoC が出た段階で注目すべきなのは、攻撃の細部だけでなく、自分の環境がその前提条件に当てはまっていないか を早めに確認することです。
参考: GitHub - DepthFirstDisclosures/Nginx-Rift: exploit for CVE-2026-42945