NGINX (pronounced “engine X”) is arguably the most used web server on the internet as it accounts for nearly 30% of all tracked websites globally and serves over 5 million active sites. Beyond being a web server, it also runs as a reverse proxy, load balancer and API gateway which makes it sit directly in the path of almost every inbound request your infrastructure receives.When a critical vulnerability emerges in software with that footprint, it is not a niche security bulletin. It is a systemic threat.

On May 13, 2026, security researchers disclosed a remote code execution vulnerability (RCE) in NGINX that had been sitting in the codebase for 18 years. Named NGINX Rift and tracked as CVE-2026-42945, it carries a CVSS score of 9.2 (Critical). VulnCheck canary systems had picked up active exploitation attempts by May 16, just three days after the vulnerability and its PoC became public. If your organization runs NGINX, this requires your immediate attention.

What Is CVE-2026-42945 (NGINX Rift)?

CVE-2026-42945 is a heap buffer overflow in the ngx_http_rewrite_module, affecting NGINX Open Source versions 0.6.27 through 1.30.0 and NGINX Plus R32 through R36. F5 products built on NGINX are also in scope, this includes NGINX Ingress Controller, NGINX App Protect WAF, and F5 WAF for NGINX, among others. The full list is in the official F5 advisory.

The bug was introduced in 2008 and went undetected for nearly two decades. An unauthenticated attacker can crash your NGINX worker processes or, under certain conditions, execute arbitrary code using nothing but a crafted HTTP request.URL rewriting is one of the most common NGINX configuration patterns, which is exactly why this flaw has broad reach across real-world deployments.

The Technical Root Cause: A Two-Pass Contract Violation

The flaw is in NGINX's rewrite engine. The engine processes each rewrite directive in two passes: the first calculates how much memory to allocate, the second writes the output. Both passes have to agree on the same length. CVE-2026-42945 breaks that agreement.

When a rewrite directive uses an unnamed regex capture ($1, $2), includes a question mark in the replacement string, and is followed by another rewrite, if, or set directive, NGINX calculates the buffer size under one set of assumptions but writes data under another. The write goes past the allocated buffer. The result is a deterministic heap buffer overflow which can be triggered by sending a single crafted HTTP request, no authentication needed. A working proof-of-concept is already public.

The Vulnerable Configuration Pattern

Your NGINX deployment is only vulnerable if it matches this specific pattern:

The three conditions that create the trigger:

• A rewrite directive using unnamed PCRE captures such as $1 or $2
• A replacement string containing a question mark (?)
• Followed by another rewrite, if, or set directive in the same scope

What Can an Attacker Actually Do?

The impact depends on how your server is configured.

Tier 1: Denial of Service (High Probability)

Where the vulnerable rewrite pattern is present, a single crafted HTTP request can trigger a heap buffer overflow which crashes your NGINX worker process. The process restarts and the next request crashes it again creating a DoS loop. That loop takes your web-facing services offline without the attacker needing to bypass any operating system defenses.

Tier 2: Remote Code Execution (Conditional)

Security researcher Kevin Beaumont noted that RCE is unlikely in most real-world environments because modern Linux distributions enable ASLR (Address Space Layout Randomization) by default. The public PoC only achieves code execution after manually disabling ASLR with the setarch -R command.

However, this conditional is not a reason for you to be complacent.Misconfigured servers and legacy systems often run with ASLR disabled or weakened. On those systems, a compromised NGINX worker leaks TLS private keys for the lifetime of the process and exposes every proxied request and response body passing through it. If that worker sits in front of sensitive internal services, the exposure goes further.

How to Detect Your Exposure

Step 1: Inventory Your NGINX Versions

Run the following on your NGINX hosts to confirm the installed version:

Any version from 0.6.27 to 1.30.0 is in the vulnerable range.

Step 2: Audit Your Rewrite Configuration

Search your nginx.conf and all included configuration files for the trigger pattern:

Look for rewrite blocks that use unnamed captures ($1, $2) and a question mark (?) in the replacement string, followed by rewrite, if, or set in the same scope.

Step 3: Check Your ASLR Status

A return value of 2 means ASLR is on. A value of 0 or 1 significantly elevates the risk of remote code execution if the rewrite pattern is also present.

Step 4: Check Ingress and Proxy Exposure (Where Applicable)

If your environment runs NGINX as an ingress controller or edge proxy, check which routing rules use rewrite-target annotations or equivalent rewrite logic as these commonly generate the trigger pattern. Any NGINX instance sitting directly at the network perimeter should be your first patching target, regardless of the underlying infrastructure.

Remediation: Patching and Mitigation Steps

Primary Remediation: Upgrade NGINX

The patched versions are NGINX 1.30.1+ and 1.31.0+. For NGINX Plus, upgrade to R37 or later.

Additional Hardening Measures

• Confirm ASLR is enabled on all NGINX hosts (randomize_va_space = 2).
• Restrict HTTP access at the perimeter to reduce unauthenticated exposure.
• Enable request logging and flag unusual URI patterns — heavily encoded or malformed query strings targeting rewrite-heavy endpoints are worth investigating.
• Patch internet-facing instances first: reverse proxies, API gateways, and edge load balancers.
• Watch for unexpected NGINX worker restarts, which is a signal of active DoS attempts.

Why You Need to Act Now

This is not just a patching task. Regulatory frameworks including ISO 27001, NDPA, GDPR, and PCI DSS require timely remediation of known critical vulnerabilities and documented evidence that it happened. A breach traced back to an unpatched CVE-2026-42945 instance which was disclosed publicly weeks or months prior is a compliance failure with a paper trail.

Your incident response plan should include detection rules for this specific exploit pattern as active exploitation was confirmed three days after disclosure. The window between a CVE going public and attacks showing up in the wild is getting shorter, and NGINX Rift makes that point clearly.

How A&DForensics Can Help You

At A&DForensics, our Vulnerability Assessment and Penetration Testing (VAPT) services are built to find configuration-dependent flaws like this one before attackers do. Whether you need a focused assessment of your web infrastructure, incident response support after an exploitation attempt, or a broader audit of your web infrastructure controls, reach out to A&DForensics today.

Conclusion

With a CVSS score of 9.2, confirmed exploitation in the wild, and a public proof-of-concept already circulating, CVE-2026-42945 does not afford deliberate inaction. Audit your NGINX version inventory, check your rewrite configurations for the trigger pattern, and patch to 1.30.1 or 1.31.0. The organizations most at risk from NGINX Rift are not the ones who haven't heard of it. They are the ones who have, and filed it as a routine ticket.

Contributor: Galadinma Danladi