A critical memory corruption vulnerability in NGINX, designated CVE-2026-42945, has moved from disclosure to active exploitation in just days. Security researchers from VulnCheck reported detecting exploitation attempts on May 16, 2026, barely three days after the vulnerability and a proof-of-concept (PoC) exploit were made public. The flaw, dubbed NGINX Rift, poses a severe threat to the vast infrastructure relying on the popular web server, load balancer, and reverse proxy.

Understanding the NGINX Ecosystem

NGINX has become the most widely deployed web server globally, powering millions of websites and applications. Its efficiency in handling concurrent connections makes it a cornerstone of modern web architecture. Beyond serving static and dynamic content, NGINX functions as a load balancer, reverse proxy, and HTTP cache, often sitting at the edge of corporate networks. The software is developed and maintained by F5 Networks, which offers both the open-source NGINX Open Source and the commercial NGINX Plus versions. Additionally, F5 integrates NGINX into various application delivery and security solutions, including the NGINX Ingress Controller for Kubernetes and F5 WAF for NGINX. This widespread adoption means that a critical vulnerability in NGINX can have far-reaching consequences.

Details of CVE-2026-42945

CVE-2026-42945 is a memory corruption vulnerability residing in the ngx_http_rewrite_module. The flaw allows a remote, unauthenticated attacker to corrupt the heap of an NGINX worker process by sending a crafted URI. The vulnerability is triggered by a specific configuration pattern: when a rewrite directive uses an unnamed regex capture (such as $1 or $2) and the replacement string contains a question mark, followed by another rewrite, if, or set directive. In such configurations, NGINX miscalculates the destination buffer size, leading to a write that exceeds the allocated memory. The bytes written past the allocation are directly derived from the attacker's URI, making the corruption attacker-controlled rather than random.

The vulnerability affects NGINX Open Source versions 0.6.27 through 1.30.0 and NGINX Plus versions R32 through R36. It also impacts several F5 products, including NGINX Ingress Controller, F5 WAF for NGINX, and F5 DoS for NGINX. As noted by the researchers who discovered the flaw at Depthfirst, the issue was found using an AI-native vulnerability detection platform. The bug is reliably exploitable to cause a denial-of-service (DoS) condition by repeatedly triggering worker crashes. Under certain circumstances, it can also lead to unauthenticated remote code execution (RCE), though this depends on the target's configuration and security mitigations.

Exploitation in the Wild

According to VulnCheck's Patrick Garrity, canary systems flagged exploitation attempts on May 16, indicating that attackers are actively scanning for vulnerable instances. The effectiveness of these attempts varies. While achieving a DoS is straightforward on default NGINX configurations, achieving code execution is more challenging. Security researcher Kevin Beaumont noted that attackers could potentially achieve RCE if they manage to disable address space layout randomization (ASLR) on the target server. This is not a trivial task, but it remains a possibility in environments with misconfigured or outdated security controls. The initial access team at VulnCheck used Censys to estimate roughly 5.7 million internet-exposed NGINX servers running a potentially vulnerable version. However, they emphasize that the truly exploitable population is much smaller, as the vulnerability requires a specific rewrite configuration to be present. Nonetheless, the large attack surface means that many organizations could be at risk.

Mitigation and Patches

F5 has responded by releasing patches for all affected versions. The fixed versions are: NGINX Open Source 1.31.0 and 1.30.1, NGINX Plus R36 P4 and R32 P6, F5 WAF for NGINX v5.13.0, and F5 DoS for NGINX v4.9.0. Additionally, F5 provided a mitigation recommendation: replacing unnamed captures with named captures in rewrite directives. This simple change prevents the buffer miscalculation from occurring. Linux distributions have also started releasing patched packages. AlmaLinux, Ubuntu, and Debian developers have issued updates for their respective nginx packages. System administrators are urged to apply these patches immediately or implement the recommended mitigation if patching is not immediately possible.

The vulnerability underscores the importance of timely patching, especially for core infrastructure components like NGINX. With a PoC publicly available and active exploitation underway, the window for proactive defense is closing. Organizations should audit their NGINX configurations for the vulnerable rewrite patterns, update to the latest versions, and monitor for any signs of compromise. Given NGINX's role in serving web traffic, a successful DoS attack could disrupt operations for all sites hosted on an affected instance. For those with the potential for RCE, the consequences could be even more severe, allowing attackers to gain a foothold in the network.

Historical Context and Broader Implications

NGINX has a relatively strong security track record, but vulnerabilities in the rewrite module have been rare. This particular bug is notable for its deterministic nature and the ease of triggering a DoS. The exploitation timeline—from disclosure to active attacks in three days—is a reminder of the speed at which attackers move once technical details are available. The use of AI in discovering the vulnerability also highlights the evolving landscape of vulnerability research. As tools become more powerful, the pace of discovery and exploitation is likely to accelerate. For defenders, this means that proactive measures such as vulnerability scanning, configuration reviews, and network segmentation are more critical than ever.

In addition to patching, organizations should consider implementing Web Application Firewall (WAF) rules to block malicious URI patterns that attempt to trigger the vulnerability. However, because the vulnerability is in the server itself rather than an application, WAF rules may not be fully effective. The best defense remains updating the NGINX software. The affected versions span many years, meaning that outdated installations with unpatched vulnerabilities are likely widespread. This incident serves as a case study in supply chain security, where a single component can introduce risk across countless systems. The response from the community and vendors will be watched closely as a model for handling future critical vulnerabilities in foundational internet infrastructure.

Source: Help Net Security News