NGINX Rift: The 18-Year-Old Vulnerability Turning the World’s Most-Used Web Server Into an Entry Point for Attackers

A flaw introduced into the NGINX codebase around 2008 went unnoticed for nearly two decades until May 13, 2026, when the depthfirst research team brought it to light. Named NGINX Rift and tracked as CVE-2026-42945, the vulnerability affects a web server present on roughly one-third of all websites in existence, requires no authentication or prior access, and can lead to remote code execution with a single HTTP request.

On May 13, 2026, the depthfirst research team published the details of a vulnerability that turns the server itself into the entry point: an attacker who can reach a vulnerable NGINX server over HTTP can send a single request that overflows the worker process’s heap memory and achieves remote code execution — with no authentication, no prior access requirement, and no need for an existing session. That combination of factors is precisely what earns CVE-2026-42945 its CVSS v4 score of 9.2. The flaw affects NGINX’s ngx_http_rewrite_module, and according to researchers it has been dormant since approximately 2008.

The finding was initially disclosed to F5, NGINX’s parent company, on April 21, 2026. Less than a month later, on May 14, F5 published corrective patches alongside an official advisory. However, alongside the disclosure, depthfirst also released a working proof-of-concept demonstrating remote code execution with ASLR disabled. This means the technical barrier to exploiting the vulnerability dropped on the very same day it was announced.

What Is NGINX and Why Does This Vulnerability Matter?

NGINX is an open-source web server that also functions as a reverse proxy, load balancer, and HTTP cache. According to Picus Security’s analysis, NGINX powers close to one-third of all websites globally and is deployed by hyperscale cloud providers, content delivery networks, e-commerce platforms, banks, government agencies, and countless small businesses.

What sets a vulnerability in NGINX apart from a flaw in any ordinary application is its position in the architecture: NGINX is typically the first piece of software to process any incoming HTTP request. Attackers do not need to bypass additional defenses to reach it; the web server itself becomes the point of entry. As Picus Security notes, a single flaw at this layer of the stack can expose countless backend systems that sit safely behind it.

The Technical Problem: When Two Memory Passes Don’t Add Up

The vulnerability resides in the ngx_http_rewrite_module, the component responsible for transforming and redirecting the URLs that users request from the server. This module is widely used in real production environments for traffic routing, application management, and proxy administration.

The technical flaw is, at its core, a heap buffer overflow. At the implementation level, the problem emerges from a discrepancy between two passes that NGINX performs when processing rewrite rules: the first calculates how much memory space is needed to store the result; the second writes the actual result. Under specific configuration conditions, these two passes handle certain characters differently, causing the first pass to underestimate the required size while the second writes more data than the reserved space can hold, corrupting adjacent memory in the worker process.

The trigger condition requires a precise combination of NGINX configuration elements: a rewrite directive using unnamed captures in regular expressions — the familiar $1, $2 — with a replacement string containing a question mark (?), followed by another rewrite, if, or set directive. This pattern is neither exotic nor unusual; as SOCRadar warns, it is common in environments that use NGINX for application routing, authentication management, or multi-tenant path handling, which considerably expands the real exposure surface.

The Exploit Chain: Six Steps From a URL to Code Execution

What makes NGINX Rift a technically sophisticated vulnerability is not just the overflow itself, but the chain of steps that depthfirst researchers documented to transform that memory corruption into arbitrary code execution.

The attacker begins by sending an HTTP request whose URI matches a vulnerable location block. Plus signs (+) and other escapable characters in the URL are expanded during the write phase — from one byte to three — while the calculation phase counted them without expansion, creating the overflow. The attacker can then direct the corruption toward the cleanup field of an adjacent ngx_pool_t structure on the heap: this field points to a linked list of entries containing function pointers that NGINX executes automatically when it destroys a request’s memory pool. By controlling that pointer, the attacker controls which function is executed and with what argument.

To overcome the obstacle that the overflow is sequential, the researchers documented a two-connection synchronization technique: a first connection triggers the overflow that corrupts the pool of a second victim connection, and the attacker immediately closes that second connection to force pool destruction before any other code can access the corrupted metadata. The end result is the execution of libc’s system() function with an arbitrary attacker-controlled command.

This level of control over exploitation, combined with NGINX’s multi-process architecture where every worker inherits the same memory layout from the master process, is precisely what justifies the critical 9.2 score and the alarm it has triggered across the security community.

Real-World Impact: Denial of Service vs. Remote Code Execution

The most frequent scenario in environments with standard protections is denial of service. In this particular case, the NGINX worker process crashes and the server restarts it automatically. If the attacker repeats the attack continuously, they can keep processes in a crash loop that affects the availability of every site served by that instance. The bytes written beyond the allocation come from the attacker’s URI, meaning the corruption is attacker-directed rather than random; even without achieving code execution, it can be used to deliberately degrade availability.

The more severe variant, remote code execution (RCE), becomes possible when the system has ASLR (Address Space Layout Randomization) disabled — the protection mechanism that randomizes memory addresses at runtime. SOCRadar emphasizes an important distinction for the risk classification process: in environments with active modern mitigations, impact tends toward denial of service; in environments without those mitigations, which include some embedded systems, legacy instances, or specialized configurations, the RCE risk becomes concrete. This distinction matters for prioritizing the response, since not all exposed systems carry the same risk profile.

Affected Products: Beyond the NGINX Everyone Knows

The vulnerability is not limited to basic NGINX installations. F5 documented in its official advisory an extensive list of affected products including NGINX Plus (versions R32 through R36), NGINX Open Source (versions 1.0.0 through 1.30.0, with older versions such as 0.6.27 through 0.9.7 receiving no planned patch), NGINX Instance Manager, F5 WAF for NGINX, NGINX App Protect WAF, NGINX App Protect DoS, NGINX Gateway Fabric, and the NGINX Ingress Controller. The fixed versions for the main branches are NGINX Open Source 1.30.1 and 1.31.0, and NGINX Plus R32 P6 and R36 P4.

Alongside CVE-2026-42945, the same patch round addressed three additional vulnerabilities: CVE-2026-42946 (CVSS 8.3), excessive memory allocation in the SCGI and uWSGI modules that may allow an attacker with man-in-the-middle capabilities to read worker process memory; CVE-2026-40701 (CVSS 6.3), a use-after-free vulnerability in the SSL module that may cause limited data modification or process restart; and CVE-2026-42934 (CVSS 6.3), an out-of-bounds read in the charset module that may disclose memory contents. The accumulation of four flaws in a single audit suggests that deep security review of the NGINX codebase had been significantly overdue.

Defensive Perspective: What Security Teams Should Do Now

The first step is to inventory NGINX instances in production and determine which ones use rewrite directives with the documented trigger pattern — unnamed captures combined with question marks in the replacement string, followed by rewrite, if, or set directives. Not every NGINX installation is equally exposed, and this distinction defines the real urgency of patching each system.

For those unable to apply the update immediately, F5 documented a temporary mitigation: replacing unnamed captures ($1, $2) with named captures in all affected rewrite directives across the configuration. This change does not eliminate the vulnerability from the binary, but it deactivates the known trigger path while the formal update cycle is completed. It is an emergency measure, not a substitute for the patch.

At the monitoring level, SOCRadar recommends watching for unusual increases in NGINX worker process restarts, particularly following traffic spikes with anomalous URIs or elevated densities of special characters such as plus signs, ampersands, or escape sequences. A worker that crashes repeatedly against a specific traffic pattern is a signal of active exploitation even before a successful intrusion is logged.

On Linux systems, confirming that ASLR is fully enabled is a mandatory step in the triage process:

cat /proc/sys/kernel/randomize_va_space

A value of 2 indicates that protection is active. Any lower value — especially on long-running servers that have not been recently reviewed — should be treated as urgent.

Analysis: What This Flaw Reveals About Technical Debt in Critical Infrastructure

The NGINX Rift case is not simply the story of one more vulnerability. It is an indicator of how infrastructure software ecosystems can conceal subtle flaws for years, going unpatched under a false sense of trust.

The problem of age as a security guarantee. NGINX has been in mass deployment for over two decades and has been audited by thousands of engineers over that time. Yet the flaw just revealed was 18 years old. The trigger mechanism is specific enough — requiring a precise combination of configuration — that it never raised alarms in everyday use, yet exploitable enough to represent a critical risk once the vector is known. The longevity of an open-source project is not a guarantee of exhaustive security coverage; it is simply accumulated time during which the flaw could have been found by actors less inclined toward responsible disclosure.

The window between disclosure and mass exploitation has closed. Years ago, the publication of a critical vulnerability gave defensive teams weeks or even months before malicious actors developed functional exploitation tools. Today, depthfirst published the proof-of-concept on the same day as disclosure. The window between public knowledge of a flaw and the appearance of active exploitation attempts in the threat ecosystem has shrunk to hours or days. This is not an isolated case; it is the pattern that defines how security teams must operate in 2026.

NGINX’s weight as a high-value target. Ransomware groups and advanced persistent threat actors have spent years targeting the infrastructure layers that are common to multiple organizations simultaneously: VPNs, firewalls, web servers. A vulnerability that works against any NGINX installation with the right configuration pattern is not an attack on a specific organization; it is a weapon that scales horizontally. The value for a criminal actor lies not in compromising a single server, but in identifying through mass scanning how many of the millions of NGINX servers in production carry the vulnerable pattern.

The question this case leaves on the table is not whether NGINX Rift will be actively exploited in the coming days. The question is how many organizations will have completed their patching cycle before that happens.

References

F5. (2026, May 14). K000161019: NGINX ngx_http_rewrite_module vulnerability CVE-2026-42945. F5 Support. https://my.f5.com/manage/s/article/K000161019

Lin, Z. (2026, May 13). NGINX Rift: Achieving NGINX Remote Code Execution via an 18-Year-Old Vulnerability. depthfirst. https://depthfirst.com/research/nginx-rift-achieving-nginx-rce-via-an-18-year-old-vulnerability

SOCRadar. (2026, May 14). CVE-2026-42945: NGINX Rewrite Heap Overflow Enables Remote DoS & Potential RCE. SOCRadar Cyber Intelligence Inc. https://socradar.io/blog/cve-2026-42945-nginx-rewrite-heap-overflow-dos-rce/

Yuceel, H. C. (2026, May 14). NGINX Rift: CVE-2026-42945 Critical Heap Buffer Overflow Vulnerability Explained. Picus Security. https://www.picussecurity.com/resource/blog/nginx-rift-cve-2026-42945-critical-heap-buffer-overflow-vulnerability-explained