CVE-2026-42945: the bug, where it lives, and why it matters
CVE-2026-42945 is a heap buffer overflow in the ngx_http_rewrite_module that has been present in NGINX’s code for roughly 18 years and affects NGINX Open Source versions 0.6.27 through 1.30.0. The flaw received a critical severity rating of 9.2 under the Common Vulnerability Scoring System (CVSS). NGINX — owned and maintained by American tech firm F5 — is widely used as a web server and reverse proxy, powering roughly a third of the top ranked websites and operating in environments from cloud providers and SaaS companies to banks, media platforms, e-commerce sites, and Kubernetes clusters.
How the vulnerability works in technical terms
The root cause is inconsistent state handling in NGINX’s internal script engine, which processes rewrites in two passes: one pass calculates how much memory to allocate, and a second pass copies the actual data. When a rewrite contains a '?' the internal 'is_args' flag remains set. That causes NGINX to calculate a buffer size using unescaped URI lengths but later write escaped data — characters like '+' and '&' — which can be larger, producing a heap buffer overflow.
DepthFirst’s researchers say the overflow can be triggered when configurations use both the 'rewrite' and 'set' directives — a combination they describe as common in API gateways and reverse proxy setups.
DepthFirst AI’s discovery and the demonstrated exploit
Researchers at AI-native security company DepthFirst AI discovered CVE-2026-42945 during a roughly six-hour autonomous code scanning session on April 18, 2026, and reported it to the vendor on April 21. In their proof-of-concept, they demonstrated unauthenticated code execution via specially crafted HTTP requests that corrupt adjacent NGINX memory pool structures, overwrite cleanup handler pointers, spray fake structures into memory via POST request bodies, and force NGINX to execute system() during pool cleanup.
DepthFirst also highlighted that NGINX’s multi-process architecture makes exploitation easier because worker processes inherit nearly identical memory layouts from the master process. That inheritance, the researchers said, permits reliable heap manipulation and repeated attempts — if a worker crashes, the master spawns a new worker with the same layout, allowing attackers to try again until they succeed. The researchers further noted a theoretical path to leaking ASLR by progressively overwriting pointers byte by byte.
F5’s advisory: affected builds, fixes, and temporary mitigations
F5 published a security advisory released yesterday identifying affected builds beyond NGINX Open Source: NGINX Plus R32 through R36; NGINX Instance Manager 2.16.0 through 2.21.1; F5 WAF for NGINX 5.9.0 through 5.12.1; NGINX App Protect WAF 4.9.0 through 4.16.0 and 5.1.0 through 5.8.0; F5 DoS for NGINX 4.8.0; NGINX App Protect DoS 4.3.0 through 4.7.0; NGINX Gateway Fabric 1.3.0 through 1.6.2 and 2.0.0 through 2.5.1; and NGINX Ingress Controller 3.5.0 through 3.7.2, 4.0.0 through 4.0.1, and 5.0.0 through 5.4.1.
Fixes were made available in NGINX Open Source 1.31.0 and 1.30.1, NGINX Plus R36 P4, and NGINX Plus R32 P6. For environments that cannot upgrade immediately, F5 recommends replacing unnamed PCRE capture groups ($1, $2, etc.) in vulnerable 'rewrite' rules with named captures, a change F5 says eliminates the main exploitation prerequisite.
Expert pushback: Kevin Beaumont and AlmaLinux on real-world exploitability
Not every researcher accepts that DepthFirst’s demonstration implies broad real-world remote code execution (RCE). Security researcher Kevin Beaumont emphasized that exploitation requires a vulnerable NGINX configuration using particular rewrite patterns, that an attacker must find the affected endpoint, and that the published RCE proof-of-concept was tested with Address Space Layout Randomization (ASLR) turned off. Beaumont said the exploit was built against a deliberately vulnerable setup and “does not demonstrate reliable code execution against hardened real-world systems.”
AlmaLinux maintainers, after independently reproducing the flaw, reached similar conclusions. They confirmed that crashing NGINX worker processes via a crafted request is trivial and reliable, making denial-of-service attacks realistic. Turning the heap overflow into dependable RCE on systems with ASLR enabled, they wrote, “is not trivial,” and they do not expect a generic, reliable exploit to emerge from depthfirst’s work — though they cautioned that “not easy” does not mean impossible and stressed the urgency of the DoS vector on its own.
What this means for cloud providers, open-source maintainers, and enterprise security teams
- Cloud providers and SaaS vendors running vulnerable NGINX builds should prioritize testing and deploying the fixes announced by F5 and consider replacing unnamed PCRE capture groups where upgrades are delayed.
- Open-source maintainers and operators of API gateways and reverse proxies should audit configurations for combined use of 'rewrite' and 'set' directives and review any rewrite rules that use unnamed captures.
- Enterprise security teams should treat the DoS vector as urgent — AlmaLinux labels worker crashes via crafted requests as trivial — while also evaluating threat models where ASLR is disabled in performance-tuned embedded systems or analysis VMs.
Even if reliable RCE appears tied to unusual, performance-tuned environments or specific rewrite patterns, the flaw’s 18-year lifespan, the breadth of affected F5 and NGINX products, and the triviality of crashing workers make this a vulnerability that network operators and administrators should address now. The fixes are available; the remaining question is how quickly administrators across cloud, enterprise, and embedded deployments will apply them.
