18-Year-Old NGINX Heap Overflow Bug Enables Remote Code Execution
NGINX Security

18-Year-Old NGINX Heap Overflow Bug Enables Remote Code Execution

Mishel Shaji
Mishel Shaji

The discovery of an 18-year-old flaw in NGINX—dubbed "NGINX Rift"—highlights a critical vulnerability in one of the world's most widely deployed web servers and reverse proxies. Discovered by security firm depthfirst via an AI-powered code auditing platform, this issue impacts code written all the way back in 2008.

The Core Vulnerability: CVE-2026-42945 (CVSS 9.2)

The main flaw is an unauthenticated, remote heap buffer overflow within NGINX’s URL rewrite module (ngx_http_rewrite_module).

The Technical Root Cause

The bug occurs due to a state mismatch in NGINX's internal scripting engine during a two-pass execution process when evaluating a specific sequence of configurations (such as a rewrite directive followed by a set, if, or another rewrite).

  1. Pass 1 (Length Calculation): NGINX calculates how much heap memory it needs to allocate for a new, rewritten URL. If a rewrite rule uses unnamed regular expression captures (like $1, $2) alongside a replacement string containing a question mark (?), an internal state flag (is_args) is mismanaged. The length calculation engine erroneously sizes the buffer without accounting for URI escaping.
  2. Pass 2 (Execution & Copy): When NGINX actually writes the data into the newly allocated buffer, a different part of the main script engine recognizes that URI escaping is required. Functions like ngx_escape_uri expand characters (e.g., turning special characters into a 3-byte %XX sequence), causing significantly more data to be written than the buffer was sized to hold.

Because the overflow data is directly controlled by the attacker's requested URI, the corruption is highly structured ("shaped") rather than random.

Real-World Impact: DoS vs. RCE

The vulnerability allows a completely unauthenticated, remote attacker to send a single crafted HTTP request to compromise the NGINX worker process. The real-world severity depends on the host system's configuration:

  • Denial of Service (DoS) / Crash Loop (Highly Likely): In virtually all modern environments, triggering the heap overflow will immediately crash the NGINX worker process. Because NGINX automatically spawns a new worker when one dies, an attacker can continuously flood the server to cause a permanent crash loop, completely degrading website and API availability.
  • Remote Code Execution (RCE) (Conditional): Security researchers successfully demonstrated a working proof-of-concept (PoC) for full remote code execution by spraying the heap via malicious HTTP POST requests to overwrite internal function pointers. However, this reliable RCE mechanism relies on Address Space Layout Randomization (ASLR) being disabled. On fully hardened production systems with active ASLR, achieving reliable code execution is significantly more difficult, though not entirely impossible if chained with other memory disclosure flaws.

Affected Software

The vulnerability spans nearly two decades of NGINX releases:

  • NGINX Open Source: Versions 0.6.27 through 1.30.0 (virtually all deployments before May 2026).
  • NGINX Plus: Versions R32 through R36.
  • Dependent Products: NGINX Ingress Controllers (for Kubernetes environments), NGINX Gateway Fabric, NGINX Instance Manager, and NGINX App Protect WAF.

(Note: The audit also uncovered three other lower-severity memory flaws in the SCGI, SSL, and charset modules, tracked under separate CVEs like CVE-2026-40701).

Remediation and Mitigation

Organizations running NGINX should act quickly, as a public PoC exploit is already circulating on GitHub.

1. Upgrade Immediately

F5 and the NGINX maintainers have released official patches. Administrators should upgrade to:

  • NGINX Open Source: 1.30.1 (legacy/stable) or 1.31.0+ (mainline).
  • NGINX Plus: R36 P4+ or R32 P6+ (depending on your release track).

2. Temporary Configuration Workaround

If immediate upgrading or patching is not feasible, the vulnerability can be mitigated by auditing your nginx.conf files and replacing unnamed regex captures with named captures in all rewrite rules.

❌ Vulnerable Example (Unnamed Capture):

Nginx

rewrite ^/users/([0-9]+)$ /profile.php?id=$1 last;
  • Safe Example (Named Capture):*

Nginx

rewrite ^/users/(?<user_id>[0-9]+)$ /profile.php?id=$user_id last;

By switching to named parameters (e.g., ?<user_id>), NGINX processes the variables using a separate code path that bypasses the flawed memory calculation entirely.

You might also like