A heap buffer overflow lurking in NGINX for 18 years has been disclosed by independent researcher depthfirst, who has codenamed the flaw NGINX Rift. Tracked as CVE-2026-42945 and carrying a CVSS v4 score of 9.2, the vulnerability allows an unauthenticated attacker to crash NGINX worker processes with a single crafted HTTP request, and on systems with address space layout randomisation disabled, it opens the door to remote code execution.
The bug sits inside the ngx_http_rewrite_module, a component used by a large share of NGINX deployments to manipulate URLs. It was introduced in version 0.6.27, which shipped in 2008, and went unnoticed across every release up to and including 1.30.0. That is a remarkable shelf life for a defect in software that fronts a sizeable portion of the public web.
depthfirst disclosed the issue to F5 on 21 April 2026, and a coordinated advisory followed on 13 May 2026. F5 has confirmed it as the most severe entry in its May 2026 patch batch, which covers more than 50 separate fixes. No active exploitation has been observed in the wild at the time of the patch release, though a working proof of concept demonstrating remote code execution with ASLR off was published on GitHub by 5 May 2026.
The trigger conditions are specific but not unusual. The flaw fires when a rewrite directive is followed by another rewrite, if, or set directive, combined with an unnamed PCRE capture group such as $1 or $2 and a replacement string containing a question mark. This combination appears in real-world reverse proxy and API gateway configurations where URL rewriting interacts with capture groups.
The root cause is a state mismatch between two passes of the NGINX script engine. The engine first calculates how much memory it needs to hold the rewritten value, then performs a second pass to copy the data into the allocated buffer. The two passes must agree on the final size. They do not.
When a rewrite directive with a question mark executes, it sets the engine flag e->is_args to 1, and that flag stays set. During the length calculation for a subsequent set directive, NGINX creates a fresh sub-engine called le using ngx_memzero, which zeroes the structure. As a result, le.is_args is zero. With that flag unset, the URL escaping logic is skipped, and the length calculation reflects only the raw, unescaped value.
The second pass then runs against the main engine, which still carries e->is_args = 1. This time URL escaping is applied, and characters such as plus signs and ampersands are expanded into their percent-encoded forms. ngx_escape_uri ends up writing the raw size plus two extra bytes for every escapable character, while the destination buffer was sized for the raw value alone. The overflow is precisely 2N bytes, where N is the count of escapable characters in the input.
NGINX's process model makes the situation worse. Worker processes are forked from a master, and the heap layout is duplicated exactly across every child. Attackers therefore face a deterministic memory layout across workers, which means a failed exploitation attempt against one worker does not change the conditions for the next.
depthfirst's proof of concept uses cross-request heap feng shui to weaponise the overflow. The technique opens an initial connection and sends partial headers to allocate a request pool, then opens a second victim connection. Completing the headers on the first connection triggers the overflow into the victim pool. Closing the victim connection then drives pool destruction through a sprayed set of fake cleanup structures pointing at libc's system function, executing an injected command. ASLR is the one significant barrier, and most modern Linux distributions enable it by default.
The vulnerable code reaches well beyond the open source server, expanding the attack surface across F5's commercial portfolio. F5's advisory lists NGINX Open Source versions 0.6.27 through 1.30.0, with fixes in 1.30.1 and 1.31.0. NGINX Plus R32 through R36 are affected, with fixes delivered in R32 P6 and R36 P4.
The commercial product family is also in scope. NGINX App Protect WAF is affected in versions 4.9.0 to 4.16.0 and 5.1.0 to 5.8.0. NGINX Ingress Controller is affected in 3.5.0 to 3.7.2, 4.0.0 to 4.0.1, and 5.0.0 to 5.4.2. NGINX Gateway Fabric is affected in 1.3.0 to 1.6.2 and 2.0.0 to 2.6.0. NGINX Instance Manager is affected in 2.16.0 to 2.21.1. Organisations running any of these in front of internet-facing services should treat the issue as urgent, particularly where the rewrite module is in active use.
The primary action is patching. Administrators of NGINX Open Source should move to 1.30.1 or 1.31.0. NGINX Plus customers should apply R32 P6 or R36 P4. Equivalent updates are available across App Protect WAF, Ingress Controller, Gateway Fabric and Instance Manager, and operators should check F5's advisory for the exact target versions matching their deployment.
Where immediate patching is not possible, configuration review offers a temporary reduction in exposure. Removing rewrite directives that combine a question mark with unnamed capture groups and a following rewrite, if, or set directive will close the specific trigger path. This is fiddly to audit at scale, and it should be treated as a holding measure rather than a fix.
System-level defences matter as well. ASLR is the difference between a denial of service and full remote code execution within the worker process, so operators should confirm it is enabled on every host running NGINX. Monitoring for repeated worker crashes is also worthwhile as one of the more reliable indicators of compromise for this flaw, since the deterministic heap layout across forked workers means an attacker probing for an exploit chain may generate a distinctive pattern of failures before succeeding.
If you run NGINX in production, the immediate next step is to grep your configuration files for rewrite directives containing a question mark followed by a set, if, or further rewrite directive, then schedule the patch window accordingly and confirm ASLR is active on each host with cat /proc/sys/kernel/randomize_va_space.
No. The flaw only fires when a rewrite directive with a question mark replacement is followed by a set or rewrite directive that uses an unnamed PCRE capture group such as $1 or $2. Installations without this specific configuration pattern are not directly at risk from the overflow, although patching is still recommended because configurations change and the underlying defective code remains in place until the upgrade is applied.
Yes, as a temporary measure. Removing the specific rewrite directive pattern that combines a question mark, an unnamed capture group, and a following rewrite, if, or set directive closes the trigger path. This is an audit-intensive holding measure rather than a substitute for patching, particularly in large estates with many vhosts or generated configurations, and it does nothing to protect against future configuration changes that reintroduce the pattern.
ASLR is the critical barrier between a worker process crash, which is a denial of service condition, and full remote code execution inside the worker. Most modern Linux distributions enable ASLR by default, but administrators should confirm it is active on every NGINX host rather than assuming. Even with ASLR enabled, the vulnerability still allows attackers to crash worker processes repeatedly, so patching remains the only complete fix.
