NGINX Quietly Hosted the Same Heap Overflow for 18 Years—An Autonomous AI Found It in a 6 Hour Scan on April 18

Six Hours That Closed an 18 Year Gap

On April 18, an autonomous code analysis system run by AI native security firm DepthFirst AI was pointed at the NGINX source tree. Six hours later, the system flagged a heap buffer overflow in ngx_http_rewrite_module that had been in shipping releases since 0.6.27. That version is from 2007. Three days later, on April 21, DepthFirst submitted the finding to F5, which inherited NGINX in 2019 and ships both the open source build and the commercial NGINX Plus distribution.

F5 released patches on May 13. CVE-2026-42945 carries a CVSS v4 score of 9.2 (Critical). An unauthenticated remote attacker who can send a single HTTP request to a vulnerable server can overflow the heap in the worker process. On systems where ASLR is disabled, that overflow has been demonstrated to produce remote code execution. On systems where ASLR is enabled, the same payload reliably crashes the worker—which, in a high request volume environment, is its own denial of service problem.

The Configuration That Triggers It

The overflow only triggers on a specific configuration shape. The flaw fires when the rewrite directive is followed by a rewrite, if, or set directive and uses an unnamed Perl-Compatible Regular Expression capture (the familiar $1, $2 style references) with a replacement string that contains a question mark.

That sounds narrow. It is not. The rewrite plus set pattern with unnamed captures is the most common idiom in reverse proxy and API gateway configurations on the planet. Every Kubernetes Ingress controller built on NGINX includes templates that emit this pattern. Most WordPress, Laravel, and Rails sites running behind NGINX ship default rewrite rules that match. Every NGINX based WAF, NGINX Gateway Fabric, and NGINX App Protect deployment is affected.

Why the Buffer Math Is Off

NGINX rewrites a URI in two passes. The first pass walks the configured rewrite and calculates how much memory the rewritten URI will need. The second pass actually writes the bytes into the allocated buffer. The flaw lives in an internal flag called is_args. When the rewrite contains a question mark, that flag remains set after the first pass completes.

The first pass measures buffer length using the unescaped URI string. The second pass writes the escaped form—which is longer because characters like +, &, and any byte that requires percent encoding take three bytes once escaped. The size mismatch is small. It is also exactly large enough to write past the end of the heap allocation that was sized for the shorter measurement, and an attacker who controls the request URI controls the bytes that get written past the boundary.

The trigger is one carefully shaped HTTP request. There is no authentication. There is no chain. The server processes the request as it would any other, and the rewrite logic overruns the buffer during normal request handling.

Why It Survived Eighteen Years

DepthFirst's writeup contains the most pointed sentence in the whole disclosure: "If our exploit fails and crashes a worker, the master process simply spawns a new one with the exact same memory layout." NGINX's master/worker architecture, which is the same architecture that makes the server fast and survive overload, is also the thing that absorbed eighteen years of accidental triggers.

Every time someone deployed a configuration in 2009, 2014, or 2022 that hit the right corner of the rewrite module with the right input, the worker crashed, the master restarted it, and the trace ended up in /var/log/nginx/error.log as a generic SIGSEGV. Operators read those logs as transient. Nobody chased them upstream. The behavior was indistinguishable from a hardware glitch, an OOM kill, or a flaky upstream connection. The fault profile that should have produced a thousand bug reports produced exactly zero, because the architecture made each individual crash invisible.

This is the second high profile story in two weeks where an AI tool found a memory safety bug in software old enough to vote. Last week Google's research team disclosed a use after free in Exim—the mail server behind more than half the public internet—and the trigger was a single stray byte at the wrong moment. Microsoft's MDASH system just shipped 16 Windows vulnerabilities into May 2026 Patch Tuesday with autonomous agents doing most of the discovery work. The pattern is now real. Static analysis with sufficient compute budget finds bugs that humans, fuzzers, and code review missed for decades, and the disclosure cadence is going to accelerate.

What You Need to Patch

F5's advisory covers a large list of affected products. The shortlist:

• NGINX Open Source 1.0.0 through 1.30.0 — patched in 1.30.1 and 1.31.0
• NGINX Plus R32 through R36 — patched in R32 P6 and R36 P4
• NGINX Open Source 0.6.27 through 0.9.7 — vulnerable, no fix planned
• NGINX App Protect, Gateway Fabric, Ingress Controller, and WAF — all downstream, all require their own updates

If a fleet update is not on the immediate roadmap, F5's interim mitigation is structural rather than environmental: replace every unnamed PCRE capture in affected rewrite directives with a named capture. Named captures route through a different code path that does not hit the is_args flag bug. The change is mechanical—$1 becomes $capture_name—but it has to be applied across every config file, every Kubernetes Ingress template, every helm chart, every Ansible playbook, and every base image. The painful part is that organizations running thousands of NGINX instances rarely know how many of them use the rewrite plus set pattern at all.

Exposure

NGINX powers somewhere between a third and a half of the public web. Cloudflare, Microsoft Azure, and Akamai have variations of it sitting in front of customer traffic. Most container ingress in production Kubernetes runs through it. The configuration patterns the bug requires are not exotic—they are the default rewrite shape recommended in NGINX's own documentation. The realistic exposure is somewhere on the order of millions of public facing endpoints, and the public exploit will arrive as soon as the patch differential is reverse engineered.

The story to file alongside CVE-2026-42945 is not the bug itself. It is the discovery economics. DepthFirst spent six hours of compute on April 18, found a flaw that escaped human review for eighteen years, and the disclosure is already patched. The defensive cost to apply that patch across an organization's NGINX estate is several orders of magnitude higher than the offensive cost to find more bugs of the same shape in adjacent open source projects. That asymmetry favors whoever runs the next autonomous scan first.