Understanding NGINX Rift: A Decade-Old Heap Overflow Leading to RCE

A critical vulnerability, dubbed "NGINX Rift" (CVE-2026-42945), has recently come to light, affecting one of the most widely deployed web servers in the world. What makes this discovery particularly alarming is its longevity: the flaw has existed within the ngx_http_rewrite_module since version 0.6.27, dating back to 2008.

This vulnerability is a heap buffer overflow that can be leveraged to achieve unauthenticated Remote Code Execution (RCE). The discovery was made autonomously by a security analysis tool from DepthFirst, highlighting the increasing role of automated analysis in uncovering long-standing bugs in "finished" software.

The Technical Root Cause

At its core, NGINX Rift is a classic "two-pass" script engine bug. The vulnerability occurs during the processing of URL rewrites. Specifically, it triggers when a rewrite directive is used with an unnamed capture group (such as $1 or $2) and the replacement string contains a question mark (?).

When NGINX processes these directives, it performs a length calculation in the first pass and then executes the actual copy pass using ngx_escape_uri. Because the length calculation and the actual copy operation disagree on the size of the required buffer, a heap buffer overflow occurs. This overflow is then triggered when a subsequent set, if, or another rewrite directive references that corrupted memory.

The Exploit Chain

While a buffer overflow is the starting point, turning it into a reliable RCE requires a sophisticated exploit chain. The public Proof of Concept (PoC) demonstrates this using:

1. Cross-Request Heap Feng Shui: The attacker manipulates the heap layout across multiple requests to place target objects in predictable locations.
2. Pool Cleanup Pointer Corruption: By corrupting pointers within NGINX's memory pool cleanup mechanism, the attacker can redirect execution flow.

The ASLR Debate

A point of significant contention in the community discussions is the role of Address Space Layout Randomization (ASLR). The provided PoC assumes ASLR is disabled to simplify the demonstration. This has led some to claim that the risk is minimal for those with ASLR enabled.

However, security professionals warn that this is a dangerous assumption. As noted by community member @RagingCactus:

"ASLR is a defense-in-depth technique intended to make exploitation more difficult... In almost all cases it is only a matter of time and skill to also include an ASLR bypass. Both requirements continue being lowered by LLM agents every few weeks."

In short, ASLR increases the difficulty of the attack but does not fix the root cause. A fully weaponized exploit that bypasses ASLR is a realistic threat.

Mitigation and Remediation

Immediate Patching

F5 has released patches for the affected versions. Users should update to 1.31.0 or 1.30.1 for the open-source version. OpenResty has also released patches for versions 1.27 and 1.29.

Configuration Workarounds

If immediate patching is not possible, there is a critical configuration-level mitigation. The vulnerability relies on unnamed capture groups. To mitigate the risk, replace unnamed captures (e.g., $1, $2) with named captures in your rewrite definitions.

For example, instead of using $1 to reference a captured user ID, define a named capture and reference it as $user_id.

Are You Affected?

You are likely at risk if your NGINX configuration utilizes the ngx_http_rewrite_module with the following pattern:

• A rewrite directive using unnamed captures.
• A ? in the replacement string.
• A subsequent set, if, or rewrite directive that references the capture group.

If you do not use the rewrite or set directives in your configuration, you are generally not affected by this specific vulnerability.

Broader Implications

The NGINX Rift discovery sparks a wider conversation about the security of legacy C-based software. With a vulnerability persisting for nearly two decades in a core module, some developers are questioning the viability of memory-safe languages (like Go or Rust) for web server implementations. While alternatives like Caddy (Go) or Jetty (Java) exist, they are not immune to other classes of vulnerabilities, suggesting that the system-level security of a web server is a complex, multi-layered challenge.