NGINX Rift: What CVE-2026-42945 Actually Means

NGINX Rift is one of those vulnerability names that sounds like marketing until you read the details.

The short version: DepthFirst used its autonomous security analysis system on NGINX and found multiple memory corruption bugs. The serious one is CVE-2026-42945, a heap buffer overflow in ngx_http_rewrite_module.

The interesting part is not only that it is old.

It was introduced in 2008. It affects NGINX Open Source versions from 0.6.27 through 1.30.0. It involves very normal config features: rewrite, if, set, PCRE captures like $1, and replacement strings containing a question mark.

That is the part that makes it uncomfortable.

Quick answer

NGINX Rift is the public name for CVE-2026-42945, a vulnerability in NGINX's rewrite module.

In the vulnerable flow, NGINX can calculate one buffer size, then later copy a larger escaped value into that buffer. That mismatch can overflow heap memory inside an NGINX worker process.

The vendor description says exploitation can restart the worker process, and that code execution is possible on systems where ASLR is disabled. DepthFirst published a technical writeup and a public proof of concept repository, so defenders should treat this as urgent even if exploitation is configuration dependent.

The X video that made the story travel is here:

What makes this different

Most vulnerability headlines compress everything into one scary sentence:

"NGINX RCE affects a third of the internet."

That is emotionally useful. It gets people to patch.

It is also not the full story.

CVE-2026-42945 is serious because NGINX is everywhere, but it is not triggered by every default install. The vulnerable shape needs the rewrite module behavior, a rewrite-like directive sequence, unnamed PCRE captures, and a replacement path that moves into query-string handling.

So the practical question is not only:

Am I running NGINX?

The better question is:

Am I running an affected NGINX version, exposed to untrusted HTTP traffic, with rewrite configurations that use captures and query-string rewrites?

That is the difference between panic and triage.

The bug in plain English

The core issue is a two-step mismatch.

NGINX's script engine first calculates how much memory it needs for a rewritten value. Then it copies the final value into that allocation.

For this bug, the length calculation can happen while one internal flag is unset. The later copy can happen after that flag is set. When the flag changes, NGINX escapes some URI characters into a longer representation.

So the allocation is based on the smaller version.

The copy writes the larger version.

That is how you get a heap buffer overflow.

DepthFirst's writeup goes deep into the allocator, request pool lifecycle, and how their proof of concept turns the primitive into code execution with ASLR disabled. I am intentionally not reproducing the exploit path here. The useful lesson for most teams is the shape of the bug, not a copy-paste recipe.

Affected versions

From the public DepthFirst and NVD details, the core affected products are:

DepthFirst also lists affected downstream NGINX products, including NGINX Instance Manager, F5 WAF for NGINX, NGINX App Protect WAF, NGINX Gateway Fabric, and NGINX Ingress Controller.

If you operate one of those products, do not rely on this article as your version matrix. Use the official F5 advisory linked from NVD:

my.f5.com/manage/s/article/K000161019

What defenders should do first

If I had to triage this in a real environment, I would do it in this order.

First, inventory exposed NGINX.

Find internet-facing NGINX Open Source, NGINX Plus, ingress controllers, gateway products, and appliances that bundle NGINX internally. The boring inventory step matters because the affected range is huge.

Second, patch the core runtime.

For NGINX Open Source, move to 1.30.1 or 1.31.0. For NGINX Plus and commercial products, follow F5's patched release guidance. Vendor packages from Linux distributions may backport the fix, so check the distro advisory too.

Third, review rewrite-heavy configs.

Prioritize configs using rewrite, if, or set with captures like $1 and replacement strings that include ?. This does not replace patching, but it helps you understand which services sit closer to the vulnerable pattern.

Fourth, check basic hardening.

The NVD description calls out code execution on systems with ASLR disabled. ASLR should be enabled. Worker crash monitoring should also be noisy enough that repeated restarts do not disappear into normal operations.

Fifth, watch the edge.

Look for unusual NGINX worker crashes, repeated malformed requests against rewrite-heavy paths, unexpected spikes in 4xx/5xx responses, and targeted probing of old API routes that pass through rewrite logic.

The AI angle is real, but do not overread it

The part I find most interesting is that DepthFirst says its system found the NGINX issues after onboarding the source code for analysis.

That matters.

Not because "AI found one bug, therefore AI owns security now".

Because low-level security research has always been bottlenecked by attention. Large C codebases are full of old assumptions. Human researchers are excellent, but there are not enough of them to continuously inspect every hot path in every internet-scale component.

Autonomous analysis systems change the economics.

They can keep reading code after humans get tired. They can connect weird state transitions across files. They can hand researchers a candidate issue with root cause context, then humans can verify exploitability, severity, and real-world impact.

That last part still matters.

The discovery is AI-assisted. The judgment is still research.

Why this one is a good case study

CVE-2026-42945 is not a shiny new protocol bug.

It is an old parser/state bug in software that sits at the edge of modern infrastructure.

That is exactly why it is useful as a case study:

• old code is not automatically boring
• "mature" does not mean "fully explored"
• config-dependent bugs can still have massive blast radius
• a crash bug can become a code execution story under the right memory conditions
• internet-edge software deserves boring, repeated, low-level review

The uncomfortable truth is that a lot of important software is old enough to vote.

And some of it still has states nobody has looked at closely in years.

FAQ

Is NGINX Rift the same as CVE-2026-42945?

Yes. NGINX Rift is the name used by DepthFirst for the CVE-2026-42945 research around the NGINX rewrite module heap buffer overflow.

Is CVE-2026-42945 remote code execution?

It can be. NVD says the issue can cause a heap buffer overflow and worker restart, and that code execution is possible when ASLR is disabled. DepthFirst published a proof of concept demonstrating RCE in its tested conditions.

Is every NGINX server vulnerable?

No. Version matters, and configuration matters. The vulnerable condition is tied to ngx_http_rewrite_module behavior involving rewrite-style directives, unnamed PCRE captures, and a replacement string containing ?. Still, the affected version range is broad enough that teams should inventory and patch quickly.

What versions fix NGINX Rift?

For NGINX Open Source, the public fixed versions are 1.30.1 and 1.31.0. For NGINX Plus, the public fixed versions listed by DepthFirst are R36 P4, R35 P2, and R32 P6.

Should I use the GitHub PoC to test my production server?

No. Do not run public exploit code against production infrastructure. Use patch status, config review, vendor advisories, and controlled lab validation.

Links

• DepthFirst technical writeup: NGINX Rift: Achieving NGINX Remote Code Execution via an 18-Year-Old Vulnerability
• NVD record: CVE-2026-42945
• F5 advisory: K000161019
• GitHub repository: DepthFirstDisclosures/Nginx-Rift
• X video/thread: International Cyber Digest on X