NGINX Rift (CVE-2026-42945): Patch Now or Get Exploited

A bug that has been sitting in NGINX since 2008 is now being actively exploited. CVE-2026-42945 — branded NGINX Rift — is a heap buffer overflow in the NGINX rewrite module that lets an unauthenticated attacker crash your web server with a single HTTP request. In the right environment, it enables remote code execution. The patch shipped May 13. Active exploitation was confirmed May 16. That three-day window has already closed, and attackers are inside it.

What NGINX Rift Actually Is

NGINX powers roughly 33% of all websites with a known web server — it is the most deployed web server on the planet, and it has had this bug in every release since version 0.6.27. The vulnerability carries a CVSS v4 score of 9.2 (Critical), and the attack surface is wide: no credentials, no existing session, no prior access required. One crafted HTTP request is all it takes to crash the worker process. If ASLR is disabled on the target — a common configuration in certain containerized environments — the same request achieves full remote code execution.

The technical root cause is a two-pass mismatch in NGINX’s script engine. During the length calculation pass, an internal is_args state flag gets set. That flag then leaks into the copy (write) pass, causing ngx_escape_uri to write past the end of the heap allocation when certain characters expand during re-escaping. The result is a deterministic 4,000-byte heap overflow triggered by a precisely crafted URL.

Does Your Config Trigger It?

Not every NGINX install is vulnerable to exploitation — the overflow only fires when three conditions are simultaneously present in a rewrite rule:

1. An unnamed PCRE capture ($1, $2, etc.) in the pattern
2. A question mark (?) in the replacement string
3. Another rewrite, if, or set directive following in the same scope

URL parameter rewrites matching this pattern are not exotic — they are extremely common in real-world configurations for redirects, API routing, and query string manipulation. If you are running NGINX as a reverse proxy or API gateway, there is a meaningful probability your config is affected. Here is what the vulnerable pattern looks like, and its safe equivalent:

# VULNERABLE — unnamed capture + ? in replacement + subsequent directive
location /api {
    rewrite ^/api/(.*)$ /v2/$1?version=2 break;
    set $upstream "backend";
}

# SAFE — replace unnamed capture with named capture
location /api {
    rewrite ^/api/(?<path>.*)$ /v2/${path}?version=2 break;
    set $upstream "backend";
}

Switching (.*) to (?<path>.*) and updating the reference from $1 to ${path} takes the configuration out of the vulnerable code path entirely. This is a viable workaround if you cannot patch immediately.

How to Patch

The fix is in NGINX Open Source 1.30.1 (stable) and 1.31.0 (mainline), both released May 13. For NGINX Plus, the patched versions are R32 P6 and R36 P4. Upgrade and restart workers:

# Ubuntu / Debian
sudo apt update && sudo apt upgrade nginx
sudo systemctl restart nginx

# RHEL / AlmaLinux / Rocky Linux
sudo dnf upgrade nginx
sudo systemctl restart nginx

# Alpine Linux
apk upgrade nginx

# Confirm the version
nginx -v

Note that Debian, Ubuntu, and RHEL-family distributions often backport security patches into stable branches, so your package version might still appear lower than 1.30.1 while already carrying the fix. The version output from nginx -v is less reliable here than checking your distro’s security advisory for confirmation that the patch has been applied.

The Kubernetes Problem Has No Easy Answer

Here is where things get uncomfortable. The ingress-nginx project — the most widely used NGINX-based Kubernetes ingress controller — was formally retired in March 2026. The last upstream build is v1.15.1. No patch will come from the Kubernetes community for CVE-2026-42945 in that project. Ever.

The Kubernetes Steering Committee was direct about this when they announced the retirement: the project’s flexibility had become a maintenance burden that could not be resolved. The planned successor, InGate, also failed to reach maturity and was retired alongside it.

If your cluster is still running ingress-nginx, you are running an actively exploited Critical vulnerability with no vendor patch path. The short-term mitigations — applying WAF rules upstream, rate-limiting at the load balancer, blocking malformed rewrite paths — reduce risk but do not eliminate it. The real answer is migrating to a maintained ingress controller. Envoy Gateway, Cilium Gateway API, Kong, and HAProxy Ingress are the realistic options depending on your cluster’s requirements.

Act on This Now

Three things to do today: first, check your NGINX version and confirm the patch is applied. Second, audit your rewrite rules for the trigger pattern — unnamed captures followed by a question mark and a subsequent directive. Third, if you are running ingress-nginx on Kubernetes, start planning the migration. The active exploitation timeline on this one — three days from PoC publication to confirmed attacks in the wild — should remove any doubt about urgency.