Open Nav
Sign Up

CVE-2026-42945: Actively Exploited NGINX Rewrite Module Vulnerability Enables Worker Crashes and Possible RCE

CVE-2026-42945

Filip Dimitrov

May 19, 2026

CVE-2026-42945 is a heap-based buffer overflow vulnerability affecting NGINX Plus and NGINX Open Source. The flaw exists in the ngx_http_rewrite_module and can be triggered through crafted HTTP requests when a vulnerable rewrite configuration is present. F5 assigned the vulnerability a CVSS v4.0 score of 9.2 Critical, while NVD currently lists the record as awaiting enrichment.

The vulnerability is especially important because NGINX is widely deployed as a web server, reverse proxy, load balancer, and ingress component. Exploitation can cause NGINX worker process crashes, leading to denial-of-service conditions. In more limited scenarios, remote code execution may be possible if Address Space Layout Randomization is disabled on the target system.

Public technical details and proof-of-concept exploit material have been released, and VulnCheck reported exploitation attempts shortly after disclosure. This makes the issue urgent for organizations running internet-exposed NGINX instances, even though successful exploitation depends on the presence of a specific rewrite configuration.

Technical Details

CVE-2026-42945 is triggered when an NGINX rewrite directive uses an unnamed PCRE capture group such as $1 or $2, includes a replacement string containing a question mark, and is followed by another rewrite, if, or set directive in the same scope. Under these conditions, NGINX can miscalculate the required destination buffer size and write beyond the allocated memory.

This results in deterministic memory corruption in the NGINX worker process. Attackers can send crafted URI requests to trigger the flaw remotely without authentication. Repeated exploitation attempts may be used to keep worker processes in a crash loop and degrade availability for applications served by the affected NGINX instance.

While public discussion has included the possibility of remote code execution, several sources note that reliable RCE is more constrained in practice. Systems with ASLR enabled are harder to exploit for code execution, and the target must also use the vulnerable rewrite pattern. However, denial-of-service exploitation remains a realistic concern and should be treated seriously for internet-facing deployments.

Affected Products

The vulnerability affects NGINX Open Source versions 0.6.27 through 1.30.0. Fixed upstream versions are NGINX Open Source 1.30.1 and 1.31.0.

Other affected F5/NGINX products include:

  • NGINX Plus R32 through R36
  • NGINX Instance Manager
  • F5 WAF for NGINX
  • NGINX App Protect WAF
  • F5 DoS for NGINX
  • NGINX App Protect DoS
  • NGINX Gateway Fabric, and 
  • NGINX Ingress Controller versions listed by the vendor/research disclosures.

Exploitation Status

Exploitation attempts have been reported in the wild. VulnCheck canary systems began flagging exploitation attempts on May 16, 2026, shortly after public disclosure and PoC release. 

VulnCheck noted that roughly 5.7 million internet-exposed NGINX servers appear to be running potentially vulnerable versions, but the truly exploitable population is likely smaller because the issue requires a specific rewrite configuration.

Recommended Actions

  • Immediately identify internet-facing NGINX deployments and verify both the installed version and rewrite configuration. Priority should be given to systems running affected versions with custom rewrite rules, reverse proxy functionality, ingress controller use, or externally reachable web applications.
  • Upgrade affected NGINX Open Source deployments to 1.30.1 or 1.31.0. NGINX Plus users should apply the relevant fixed releases, including R36 P4 or R32 P6, depending on their branch. F5 WAF for NGINX and F5 DoS for NGINX users should also move to fixed versions where available.
  • Where immediate patching is not possible, review NGINX configuration files for rewrite directives that use unnamed captures such as $1 or $2 with query-string replacements. Replace unnamed captures with named captures and restart/reload NGINX after making changes. This should be treated as a temporary mitigation, not a substitute for patching.

Security teams should monitor NGINX access and error logs for unusual crafted URI requests, repeated worker process crashes, segmentation faults, unexplained service restarts, or sudden spikes in 5xx errors. Because public IOCs are limited, detection should focus on behavioral indicators and exposure validation rather than relying only on static indicators.

Stay Safe. Stay Secure.

OP Innovate Research Team

Under Cyber Attack?

Fill out the form and we will contact you immediately.