A memory corruption flaw in NGINX's source code, hidden since 2008, now has a working exploit. An unauthenticated attacker anywhere on the internet can send a single crafted HTTP request to crash NGINX worker processes — or, under the right conditions, achieve full remote code execution on the server.
Researchers at depthfirst, an autonomous vulnerability analysis platform, discovered the flaw — now tracked as CVE-2026-42945 — while scanning the NGINX codebase in April. Their automated system flagged it within six hours. It was introduced in 2008 and has been quietly sitting in every standard NGINX build for nearly two decades. F5, which maintains NGINX, confirmed the issue on April 24 and published a coordinated advisory today.
NGINX powers approximately one-third of all websites globally. If your configuration uses rewrite directives with unnamed regex captures ($1, $2) alongside a replacement string containing a question mark, followed by another rewrite, if, or set directive — you are exposed. No authentication is required to trigger it.
Four CVEs, One Critical Hit
Depthfirst's scan returned five findings total. Four were confirmed by NGINX. The critical one dominates:
- CVE-2026-42945 - (9.2 Critical)
- CVE-2026-42946 - (8.3 High)
- CVE-2026-40701 - (6.3 Medium)
- CVE-2026-42934 - (6.3 Medium)
CVE-2026-42946 is also noteworthy: a state mismatch in the SCGI and uWSGI modules results in a cross-buffer pointer subtraction that yields a ~1 TB key length, causing a crash in the worker. The remaining two are a use-after-free in the SSL module and an out-of-bounds read in the charset module.
What Breaks and Why
The vulnerability lives in src/http/ngx_http_script.c, inside ngx_http_rewrite_module — a module present in every standard NGINX build. NGINX's script engine processes rewrite directives in two passes: first, it calculates how much memory to allocate, then it writes the actual data. The flaw breaks the contract between those two passes.
When a rewrite replacement string contains a question mark, a function called ngx_http_script_start_args_code sets an internal flag (e->is_args = 1) on the main script engine and never clears it.
A later set directive computes the buffer length using a freshly zeroed sub-engine — so it measures the capture as raw bytes, with no escaping. But when the actual write happens, the main engine still has is_args = 1, so it re-escapes the data through ngx_escape_uri in NGX_ESCAPE_ARGS mode. Every +, %, or & character in an attacker's URI expands from one byte to three. The buffer was sized for the smaller value. The write runs past the allocation.
"The bytes written past the allocation are derived from the attacker's URI, so the corruption is shaped by the attacker rather than random." — depthfirst advisory
The researchers developed a working proof-of-concept demonstrating unauthenticated RCE with ASLR disabled. They also detail a theoretical technique — progressively overwriting pointer bytes across repeated requests — that could be used to defeat ASLR. NGINX's multi-process architecture actually aids exploitation: if a worker crashes, the master spawns a new one with an identical heap layout, giving attackers unlimited retries at no cost.
Who Is Affected
The scope is wide. Affected products span most of the NGINX ecosystem:
| Product | Vulnerable Range | Fixed In |
|---|---|---|
| NGINX Open Source | 0.6.27 – 1.30.0 | 1.31.0 / 1.30.1 |
| NGINX Plus | R32 – R36 | R36 P4 / R32 P6 |
| NGINX Instance Manager | 2.16.0 – 2.21.1 | Move to fixed branch |
| NGINX App Protect WAF | 4.9.0–4.16.0, 5.1.0–5.8.0 | Move to fixed branch |
| NGINX Gateway Fabric | 1.3.0–1.6.2, 2.0.0–2.5.1 | Move to fixed branch |
| NGINX Ingress Controller | 3.5.0–5.4.1 (multiple) | Move to fixed branch |
F5 BIG-IP, BIG-IQ, Distributed Cloud, and Silverline are not affected.
What You Should Do Right Now
Upgrade first. For NGINX Open Source, upgrade to 1.31.0 or 1.30.1 and restart to reload workers with the patched binary. NGINX Plus users should apply R36 P4 or R32 P6.
If you can't patch immediately, convert unnamed regex captures to named captures in every affected rewrite directive:
# Vulnerable — unnamed captures with ? in replacement rewrite ^/users/([0-9]+)/profile/(.*)$ /profile.php?id=$1&tab=$2 last; # Mitigated — named captures bypass the vulnerable code path rewrite ^/users/(?
Named captures ((?<name>...)) do not pass through the vulnerable escaping logic. This configuration change removes the attack surface without a binary upgrade.
The broader implication here is harder to ignore than the patch itself. A bug this old, in software this widely deployed, was found not by a human auditor poring over diffs, but by an automated system running for six hours. That says something uncomfortable about the gap between how long critical infrastructure has been accumulating risk and how fast the tools to find it are now moving.