By ByteBot
A heap buffer overflow hiding in nginx’s URL rewriting code since 2008 just went fully public — exploit included. CVE-2026-42945, codenamed nginx Rift, lets an unauthenticated attacker fire a single HTTP request and achieve remote code execution on any nginx server running version 0.6.27 through 1.30.0. That’s every production nginx deployment for the past 18 years. The proof-of-concept is already on GitHub. Patches are available. Close this article and go check your servers.
A Three-Condition Bug That Slept for 18 Years
The vulnerability lives in ngx_http_rewrite_module, the piece of nginx that handles URL rewriting rules. It activates when three specific conditions appear together in a configuration block: an unnamed PCRE capture group (the $1, $2 syntax), a question mark in the replacement string, and another rewrite, if, or set directive following it. That specific combination is common in real-world configurations — API routing, legacy URL migration, and multi-stage rewrites all use this pattern regularly.
When the trigger fires, nginx enters a two-pass processing loop where the passes disagree on memory size. The first pass calculates length using unescaped characters. The second applies URI escaping, where a single + or & expands from one byte to three. An attacker who loads the URI with enough plus signs gets more bytes written than the buffer holds — overflowing into adjacent heap structures that nginx then executes when cleaning up the request. As the DepthFirst researchers who found the bug put it: “The bytes written past the allocation are derived from the attacker’s URI, so the corruption is shaped by the attacker rather than random.”
That three-way trigger combination is exactly why this went undetected for nearly two decades. Standard fuzzing tests rewrite directives in isolation. No fuzzing corpus targeted this specific interaction. Meanwhile, the module worked perfectly for every normal input, so there was no visible signal anything was wrong.
Containerized Environments Face the Highest CVE-2026-42945 Risk
The CVE carries a CVSS 9.2 and enables reliable, unauthenticated RCE — but there’s an important nuance about where “reliable” means “certain.” On systems with ASLR disabled, RCE is fully deterministic: nginx forks worker processes that share a predictable memory layout, so the attacker does not need to guess addresses. The public PoC exploit chain is built around this exact condition.
Here’s the uncomfortable reality: Docker containers and Kubernetes pods routinely run with ASLR disabled for performance reasons. Most cloud-native nginx deployments fall into this category. Even with ASLR enabled, the overflow guarantees a worker process crash on every request — a reliable denial-of-service until the server is killed and restarted. nginx powers somewhere between 33% and 42% of all websites, depending on which measurement methodology you trust. That’s hundreds of millions of servers, and most of them run a version in the affected range.
Furthermore, the impact extends beyond vanilla nginx. The vulnerability also affects nginx Plus R32–R36, nginx Ingress Controller, nginx App Protect WAF, and nginx Gateway Fabric across multiple version ranges. If your stack touches any of these products, assume you’re in scope.
What to Do Right Now
The fix is straightforward. For nginx Open Source, upgrade to 1.30.1 or 1.31.0. For nginx Plus, apply R36 P4 (R36 users) or R32 P6 (R32 users). On AlmaLinux, Fedora, or similar dnf-based systems, patched packages landed in production repositories on May 14:
sudo dnf upgrade nginx
sudo systemctl restart nginxIf you cannot patch immediately, replace unnamed captures with named captures in your rewrite rules. Named captures use the (?<name>pattern) syntax and bypass the vulnerable code path entirely — no downtime required:
# Vulnerable — unnamed capture with ? in replacement
rewrite ^/users/([0-9]+)$ /profile.php?id=$1 last;
# Safe — named capture eliminates the vulnerable code path
rewrite ^/users/(?<user_id>[0-9]+)$ /profile.php?id=$user_id last;Older versions in the 0.6.27–0.9.7 range will not receive patches. The configuration workaround is the only option short of upgrading nginx itself. Ubuntu’s CVE tracker is tracking distro-specific patch availability if you’re on a Debian-based system.
The Lesson Mature Code Keeps Teaching
This follows a pattern that the industry keeps relearning. Heartbleed sat in OpenSSL for two years. Log4Shell lived in Log4j for eight. nginx Rift lasted eighteen — in the most widely deployed web server on the internet. Security audits chase new code. Mature infrastructure that “just works” gets assumed correct. The rewrite module had been stable for years, so nobody looked closely at what happened when three specific directives combined in one particular order. This is the same dynamic that made Next.js’s recent security meltdown possible — complexity accumulates in places nobody thinks to look.
DepthFirst researchers coordinated disclosure with F5 on April 21, giving the nginx team more than three weeks before the public PoC dropped on May 13. That window is now closed. Active scanning for vulnerable configurations will start within hours of this writing, if it hasn’t already. Treat this the same way the industry treated Log4Shell: assume you’re affected until you’ve verified otherwise. The patch exists, the workaround exists, and the exploit is public.
