A critical vulnerability (CVE-2026-42945, CVSS 9.2) was disclosed affecting NGINX Open Source and NGINX Plus, allowing attackers to reliably trigger denial-of-service (DoS) conditions and potentially achieve remote code execution (RCE) via specially crafted HTTP requests. Due to the potential for widespread disruption across internet-facing applications and ingress infrastructure, immediate patching is strongly recommended.

Technical Root Cause

The issue originates from the ngx_http_rewrite_module, where improper handling of unnamed PCRE captures combined with rewrite directives and replacement strings containing a question mark (?) leads to a heap buffer overflow in the NGINX worker process. By sending crafted HTTP requests, attackers can reliably crash NGINX worker processes through heap memory corruption, resulting in denial of service, while certain environments may also be susceptible to remote code execution. No authentication is required to exploit this issue.

Affected Products and Versions

The following components are affected: NGINX Open Source versions 1.0.0 through 1.30.0, NGINX Plus R32 through R36, as well as several dependent products including NGINX Ingress Controller, NGINX Gateway Fabric, NGINX App Protect WAF, F5 WAF for NGINX, and related DoS protection offerings. The vulnerability is particularly dangerous in deployments utilizing rewrite, if, or set directives with unnamed regex captures such as $1 or $2.

Recommended Action

Users should upgrade to NGINX Open Source 1.30.1 or 1.31.0 and NGINX Plus R32 P6 or R36 P4. If immediate patching is not possible, organizations should replace unnamed captures with named captures in affected rewrite directives as a temporary mitigation.

Exploitation Risk and Threat Outlook

At the time of writing, a public GitHub proof-of-concept (PoC) exploit has already been released, significantly increasing the likelihood of opportunistic exploitation attempts and rapid weaponization by threat actors. While no confirmed in-the-wild exploitation has been publicly reported yet, the combination of public exploit availability, unauthenticated attack surface, and the ubiquity of NGINX in production environments makes this vulnerability especially dangerous for internet-facing applications and Kubernetes ingress deployments.

Potential Business Impact

Successful exploitation can reliably cause repeated worker crashes and service instability. In some environments, attackers may also be able to leverage the heap corruption for arbitrary code execution, potentially leading to service disruption, traffic manipulation, sensitive data exposure, or deeper infrastructure compromise. While some reports note that reliable RCE may be easier on systems where ASLR is disabled, attackers do not necessarily require ASLR to be turned off. Sophisticated exploitation techniques may combine heap corruption with memory disclosure vulnerabilities, heap grooming, or other environment-specific methods to bypass memory protection mechanisms and achieve code execution on hardened systems.

UPDATE May 15, 2026

Our team successfully demonstrated a Proof of Concept (PoC) for CVE-2026-42945, exploiting an 18-year-old heap buffer overflow in NGINX’s rewrite module to achieve an unauthenticated remote Denial of Service (DoS). Executing the attack against a fully patched Ubuntu instance running NGINX 1.28.3 with modern exploit mitigations enabled, we required only standard Python sockets and a single, precisely crafted HTTP GET request. By sending a payload of 349 safe padding bytes followed by 2,000 URI-escapable characters (such as +), our exploit leveraged a state mismatch in the script engine to trigger a deterministic 4,000-byte heap overflow. This successfully bypassed built-in mitigations and corrupted adjacent glibc heap metadata, forcing the targeted worker process to abort.

The execution of our PoC proved highly effective, resulting in immediate worker process crashes and demonstrating our capacity to launch a sustained DoS attack against all clients. During a single-round attack that we initiated over the public internet, just three exploit requests successfully killed multiple NGINX workers simultaneously, failing four out of five subsequent health checks. When we set our script to a continuous loop, the PoC maintained a complete service disruption by crashing worker processes faster than the NGINX master process could respawn them. The success of our exploit was fully corroborated by our target’s server-side error logs, which recorded rapid PID cycling alongside fatal glibc heap corruption alerts and immediate SIGABRT worker terminations.

How can Orca help?

Orca enables customers to quickly identify assets running vulnerable NGINX versions, understand their exposure in context — including internet accessibility, runtime reachability, and asset criticality — and prioritize remediation based on real risk rather than CVSS alone. Orca’s platform highlights affected assets directly in the newItem view, helping security teams focus on the most critical remediation paths first.