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 or 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