NGINX Rift: An 18-Year-Old Web Server Flaw Now Has a Working RCE Exploit

nginx runs in front of a large share of the world's websites and applications, which is exactly why a flaw that sat untouched inside it for 18 years deserves attention this week. CVE-2026-42945, now named NGINX Rift, began life as a heap overflow that could crash a worker process. A public proof-of-concept has since turned it into unauthenticated remote code execution triggered by a single HTTP request.

What Happened

Researchers at depthfirst found a heap buffer overflow in ngx_http_rewrite_module, the nginx component that handles URL rewriting. The flaw carries a CVSS v4 score of 9.2 and affects nginx Open Source from version 0.6.27 through 1.30.0, NGINX Plus R32 to R36, and a long list of related F5 products including the NGINX Ingress Controller and Gateway Fabric. It triggers when a rewrite directive is followed by a rewrite, if, or set directive that uses an unnamed regular-expression capture such as $1 and a replacement string containing a question mark. F5 issued patches on 14 May after responsible disclosure on 21 April, and a working exploit chain that defeats Address Space Layout Randomisation has since been published.

Why It Matters

An attacker needs no credentials, no existing session, and no prior foothold, only the ability to reach the server over HTTP. For Australian organisations that covers a great deal of public-facing infrastructure: load balancers, API gateways, Kubernetes ingress controllers, and the web servers sitting in front of customer portals and government services. A single crafted request can corrupt the worker heap, and repeated requests can keep every site on that instance in a crash loop.

An attacker who can reach a vulnerable NGINX server over HTTP can send a single request that overflows the heap in the worker process and achieves remote code execution. There is no authentication step, no prior access requirement, and no need for an existing session.

What Security Teams Should Do Now

• Upgrade nginx Open Source to 1.30.1 or 1.31.0, and NGINX Plus to R32 P6 or R36 P4. Versions 0.6.27 to 0.9.7 will not be fixed and should be retired.

• If you cannot patch straight away, rewrite the affected rules to use named captures in place of unnamed ones such as $1 and $2.

• Inventory every place nginx runs, including hardware appliances and container images where it ships as a dependency. NGINX Ingress Controller, Gateway Fabric and App Protect are all on the affected list.

• Keep ASLR enabled on hosts running nginx. The public exploit works around it, but turning it off makes code execution far easier.

• Watch web server and WAF logs for malformed URIs and repeated worker restarts, both of which can signal exploitation attempts.

• Confirm the fix actually reached every instance with a focused security assessment rather than trusting the deployment pipeline alone.

Aurian's Take

NGINX Rift is a reminder that age is no guarantee of safety. Code that has shipped for 18 years gets trusted by reputation rather than re-examined, and that quiet trust is where the deepest bugs survive. The window between disclosure and a weaponised exploit is closing too. This flaw went from a routine patch to a public remote code execution chain in under a fortnight, which is quicker than many organisations can approve a maintenance window.

Patching closes the hole. It does not tell you where that hole was exposed in the first place. Regular penetration testing answers the questions NGINX Rift turns against you: which of your services actually face the internet, how they are configured, and what an attacker can reach with no credentials at all. At Aurian we treat web-facing infrastructure as a live attack surface rather than a fixed asset, because configuration drift and forgotten, unpatched instances are usually what an exploit like this finds first. A security assessment that measures real exposure, not just version numbers, is what separates a patched estate from a protected one.

---

Flaws like NGINX Rift rarely announce themselves. They sit in plain sight until someone writes the exploit, and the organisations that come through comfortably are the ones that already knew what their internet-facing services were exposing.

To find out how Aurian can help your organisation assess its exposure, get in touch.