This newly released CVE and the related exploit leave millions of NGINX instances around the world exposed. Here’s how you can check if you’re vulnerable, with detailed insight into how OX Security can find the issue for you across four different angles.
What is NGINX Rift?
The latest NGINX vulnerability family, dubbed “NGINX Rift”, was disclosed May 14, 2026. It gives unauthenticated attackers the ability to perform Remote Code Execution (RCE) and Denial of Service (DoS) attacks on vulnerable servers configured with the set and rewrite directives exposed to the internet.
The root cause is an unauthenticated heap overflow in ngx_http_rewrite_module, tracked as CVE-2026-42945 with a CVSS score of 9.2 (Critical). Because NGINX powers a huge share of the public web — from solo blogs to Fortune 500 edge fleets — the blast radius here is enormous. Anything with an exposed listener and a rewrite or set directive in scope is a potential target, and exploitation requires no credentials.
The impact
NGINX Rift allows for Remote Code Execution (RCE). In plain terms: an unauthenticated attacker can run arbitrary commands on a server running a vulnerable version of NGINX, with no prior access and no user interaction. From there, the usual post-exploitation playbook applies — credential theft, lateral movement, data exfiltration, persistence, or pivoting deeper into your cloud environment.
The same flaw is also trivially weaponizable for Denial of Service, so even attackers who don’t bother with full RCE can knock vulnerable instances offline by sending a malformed request.
Affected versions
| Product | Affected versions | Fixed version |
| NGINX Open Source | 0.6.27 – 0.9.7, 1.0.0 – 1.30.0 | 1.30.1, 1.31.0 |
| NGINX Plus | R32 – R36 | R32 P6, R36 P4 |
| NGINX Instance Manager | 2.16.0 – 2.21.1 | — |
| F5 WAF for NGINX | 5.9.0 – 5.12.1 | — |
| NGINX App Protect WAF | 4.9.0 – 4.16.0, 5.1.0 – 5.8.0 | — |
| F5 DoS for NGINX | 4.8.0 | — |
| NGINX App Protect DoS | 4.3.0 – 4.7.0 | — |
| NGINX Gateway Fabric | 1.3.0 – 1.6.2, 2.0.0 – 2.5.1 | — |
| NGINX Ingress Controller | 3.5.0 – 3.75, 4.0.0 – 4.0.1, 5.0.0 – 5.4.1 | — |
If you’re running anything in the “Affected versions” column, treat it as exposed until proven otherwise.
Worth noting – a single scanner can’t catch a vulnerability like this everywhere it hides. NGINX gets pulled in through base images, baked into Terraform modules, installed by AI coding assistants, deployed as ingress controllers, and shipped inside WAF appliances. To actually find every instance — and prove which ones are exploitable — you need to look at the problem from several angles. OX covers it across four pillars: block the new, find the existing, confirm it’s exposed, and prove the exploit.
Pillar 01 – Block new usage: OX VibeSec
The fastest fix is the one that prevents the vulnerability from entering your environment in the first place. OX VibeSec sits in front of your AI coding assistant and blocks it from suggesting or installing vulnerable NGINX versions. When a developer asks Cursor, Claude Code, or any AI assistant to “set up NGINX in this Dockerfile,” VibeSec intercepts the recommendation and steers it toward a patched version. No vulnerable code, no remediation cycle, no ticket.
This matters more than ever now that a large share of new infrastructure code is being written – or at least scaffolded — by AI. The same speed that gets a project shipped in a weekend is what propagates a vulnerable FROM nginx:1.29.2 line into hundreds of repos before anyone notices. Shifting prevention left of the IDE closes that gap.
In this OX VibeSec product screen we can see that the agent has refused to install the vulnerable library.
Pillar 02 – Find the existing instances: OX Code
For everything that’s already in your codebase, OX scans your source repositories for vulnerable NGINX versions pinned in Dockerfiles, Terraform modules, Helm charts, Kubernetes manifests, and other Infrastructure-as-Code. A line like FROM nginx:1.29.2 or a Terraform image = “nginx:1.30.0” is enough to flag the repo, point at the exact file and line, and recommend the patched version — all before the code ever ships to production.
The same scan covers container layers, so transitively pulled-in vulnerable NGINX binaries — the ones nobody explicitly wrote — get flagged with full provenance back to the base image they came from.
Pillar 03 – Confirm it’s exposed: OX Cloud with Runtime Security
Static analysis can miss things that runtime won’t tolerate: a sidecar pulled in by an operator, a binary swapped in during a hotfix, an ingress controller upgraded out-of-band, an EC2 instance someone spun up last quarter and forgot about. OX Cloud inventories your cloud workloads, fingerprints the NGINX version on each, watches what’s actually loaded in memory, and tells you which instances are not just vulnerable but internet-exposed — the precise combination of factors that translate a CVE into an incident.
This is also where the malicious-dependency angle gets validated. A vulnerable package only matters if it’s actually loaded into a running process on a reachable host. The cloud and runtime pillar confirms exactly that.
Pillar 04 – Prove the exploit: OX Agentic Pentester
Detection tells you the version is vulnerable. The OX Agentic Pentester tells you whether an attacker can actually exploit it in your environment. It performs a highly specific sequence of socket manipulations and HTTP requests against the exposed instance, attempting the real exploit chain in a controlled way. If it succeeds, you get a reproducible proof-of-exploit — which is what turns a “high severity” finding into a “drop everything and patch this” finding, and what gets a fix prioritized over the other 200 criticals in the queue.
This is also what cuts through the noise of CVSS scores. A 9.2 sitting behind three layers of network segmentation and a WAF rule may not be your top priority. A 9.2 with a working exploit demonstrated against your live endpoint is likely your top issue.
Putting it together
Each of these four pillars catches something the others miss:
- OX VibeSec stops new vulnerable installations at the source.
- OX Code finds vulnerable versions baked into your repos, IaC, and container layers.
- OX Cloud with Runtime Security confirms which of those vulnerable versions are actually running and reachable.
- OX Agentic Pentester proves the specific issues an attacker can actually exploit end-to-end.
Taken together, these platform capabilities answer the three most important questions every security team asks during a critical-severity disclosure: Do we have it? Where is it exposed? And can someone actually exploit it?
What to do right now
- Patch any NGINX deployment listed in the affected versions table – open source to 1.30.1 or 1.31.0, NGINX Plus to R32 P6 or R36 P4, and equivalent fixed versions for the F5 and NGINX product family.
- Audit your Dockerfiles, Terraform, Helm charts, and base images for pinned vulnerable versions and update them now, before the next build promotes them.
- Verify exposure: cross-reference vulnerable instances against your public ingress points. An exposed vulnerable instance is an active incident in waiting.
- Run an exploit check against high-value exposed instances to confirm whether the attack chain is reachable end-to-end in your environment.
If you’re an OX customer, all four of these checks are already running across your environment — simply head to the NGINX Rift advisory in your dashboard to see your specific findings. If you’re not sure what to do beyond that, we’re happy to run a one-time assessment to tell you what’s exposed.
Stay safe out there.
