Critical 18-Year-Old RCE Vulnerability in NGINX aka “NGINX Rift” (CVE-2026-42945)

Executive Summary

On May 13th, 2026, F5 released an advisory regarding a flaw that under specific non-default conditions, could allow unauthenticated remote code execution (RCE) in NGINX Open Source and NGINX Plus. Tracked as CVE-2026-42945 and nicknamed “NGINX Rift”, the vulnerability stems from a heap buffer overflow in the ‘ngx_http_rewrite_module’ that has been present in the codebase since 2008.

Beyond potential for remote code execution, the flaw can also be exploited to cause a Denial of Service (DoS) condition and is easily weaponized due to its lower complexity to trigger. A public proof of concept (POC) exploit was released with the disclosure.

Due to the widespread usage of NGINX across the internet and the lower effort DoS attack vector, the vulnerability is likely to be targeted by opportunistic threat actors. Beazley Security recommends patching to a fixed version of NGINX to reduce risk of service disruption or exploitation.

Affected Systems and Products

 Product

 Affected Version

 Fixed Version 

 NGINX Open Source

 0.6.27 through 1.30.0

 1.30.1 / 1.31.0

 NGINX Plus

 R32 through R36  R36 P1 / R37

 NGINX Instance Manager

 2.16.0 through 2.21.1  2.21.2 

 F5 WAF for NGINX

 5.9.0 through 5.12.1  5.12.2

 NGINX App Protect WAF

 4.9.0 through 4.16.0 & 5.1.0 through 5.8.0  4.16.1 & 5.8.1

 NGINX App Protect DoS

 4.3.0 through 4.7.0  4.7.1

 NGINX Gateway Fabric

 1.3.0 through 1.6.2 & 2.0.0 through 2.5.1  1.6.3 & 2.5.2

 NGINX Ingress Controller

 3.5.0 through 3.7.2 & 4.0.0 through 4.0.1 & 5.0.0 through 5.4.1  3.7.3 & 4.0.2 & 5.4.2 

Patches

Fixes have been made available by F5, and additional information on upgrade paths can be found in the official F5 advisory and on the NGINX downloads page.

Technical Details

The flaw is a heap buffer overflow in NGINX’s internal scripts engine, which processes the ‘rewrite’, ‘if’ and ‘set’ directives. According to researchers at depthfirst who discovered and reported the vulnerability, the engine uses a two-pass procedure to handle rewrite logic, the first pass calculates the required destination buffer size, and the second pass copies the rewritten data into the allocated buffer.

The potential RCE attack path is driven by a state mismatch between these two passes. When a ‘rewrite’ replacement contains a question mark, an internal ‘is_args’ flag is set on the main script engine, but the length-calculation pass runs against a zeroed sub-engine where the flag is unset. The result is that the copy pass, which performs URI escaping that can expand each escapable byte from one to three bytes, writes substantially more data into the buffer than was allocated. Because the overflowing bytes are attacker-controlled, overflow bytes can be carefully crafted to potentially lead to RCE.

At the time of writing, there is no evidence of RCE exploitation in the wild, and F5’s advisory notes that reliable code execution requires that the target system has Address Space Layout Randomizations (ASLR) disabled. This configuration is uncommon on modern general purpose Linux distributions but more plausible on embedded devices, appliances, and legacy systems. A lesser complexity DoS attack path exists regardless of ASLR status, whereby a single crafted request reliably crashes a NGINX workers process, and repeated requests can force a crash loop that degrades availability for every site served by the instance.

NGINX is one of the most widely deployed web servers and reverse proxies on the internet, and the vulnerable rewrite pattern is common in the real-world configuration including API gateway, PHP front controllers, and WordPress permalink handling.

While full exploitation leading to RCE is more complex, the widespread use of NGINX widens the attack surface and makes the lower-effort denial of service attack a valid target for opportunistic threat actors. Beazley Security recommends patching to a fixed version of NGINX to remediate the vulnerability and reduce risk of service disruption.

How Beazley Security is Responding

Beazley Security is monitoring client perimeter devices through our Exposure Management Platform to identify impacted devices and support organizations in remediation of any issues found.

We are also conducting threat hunts across our MDR environment to detect potential exploitation attempts against our clients.

If you believe your organization may have been impacted by this attack campaign and need support, please contact our Incident Response team.

Sources

Vous êtes au courant d'un incident qui a un impact sur votre secteur d'activité ? Faites-nous savoir :

Report an incident