Free CVE-2026-42945 scanner to detect NGINX Rift

Technical details

CVE-2026-42945 is a critical heap buffer overflow in NGINX's ngx_http_rewrite_module, publicly disclosed on May 13, 2026. The flaw has existed in every standard NGINX build since version 0.6.27, released in 2008, which meant this issue sat undetected for the past 18 years.

The root cause is a size mismatch between two internal passes over a rewrite replacement string. When NGINX processes a rewrite rule that uses rewrite or set directives together with unnamed regex captures ($1, $2, etc.) and the replacement string contains a ? character, it calculates the required buffer size in the first pass, then writes more data than expected in the second pass - overflowing the allocated heap region.

An attacker who sends a crafted HTTP request that triggers this code path can:

• Crash the NGINX worker process (DoS), which auto-restarts - but repeated attacks create a denial-of-service loop.
• Execute arbitrary code on systems where ASLR is disabled or bypassable, achieving full remote code execution with no credentials and no user interaction.

NGINX is the world's most widely deployed web server and reverse proxy - it powers roughly a third of all websites globally and sits at the edge of countless Kubernetes ingress controllers, API gateways, CDN nodes, and load balancers.

A remotely exploitable vulnerability in NGINX does not affect one target; it potentially affects every system that NGINX fronts.

How we detect CVE-2026-42945

Version fingerprinting alone is not sufficient for this CVE.

The vulnerability is only triggered when the running NGINX configuration contains the specific rewrite / set pattern with unnamed captures. That means a version check can both:

• overstate risk when the server runs a vulnerable binary but the trigger pattern is absent.
• understate risk when an old embedded binary in a container is missed by scanners.

Our Network Vulnerability Scanner detects CVE-2026-42945 through version fingerprinting - it identifies the NGINX version running on your target and flags any instance in the vulnerable range (0.6.27-1.30.0 for Open Source) as exposed.

This means findings appear as unconfirmed in your report - consistent with how version-based detections are labelled across the platform. The vulnerability is present in the binary regardless of whether the specific rewrite pattern appears in your configuration; if you're running an unpatched version, upgrading is the right action whether or not the trigger pattern is active.

Note on NGINX Plus: Our detection covers NGINX Open Source. NGINX Plus detection has not yet been validated in our test environment - if you're running NGINX Plus R32-R36, treat this as exposure until patched.

Products affected by CVE-2026-42945

The vulnerability is present in all standard NGINX builds that include ngx_http_rewrite_module - which is compiled in by default.

As a consequence, the following versions are affected:

If you're running Kubernetes, check your ingress controller image separately - many bundle NGINX and do not update it when you update your main NGINX installation. A clean apt upgrade nginx on your servers will not patch a binary baked into a container image.

Note: for NGINX Open Source versions 0.6.27-0.9.7, no backport patch is planned. Upgrade to 1.30.1 or later.

NGINX is also embedded in third-party products including Kubernetes ingress controllers, API gateways, CDN appliances, and vendor-packaged software images. These deployments require separate inventory and patching, so upgrading your primary NGINX installation is not sufficient if embedded copies remain.

CVE-2026-42945 severity

CVE-2026-42945 carries a CVSS v4.0 base score of 9.2 (Critical) and a CVSS v3.1 base score of 9.8 (Critical).

The high scores reflect three factors coming together:

• No authentication required: any unauthenticated remote attacker can trigger the flaw with a single HTTP request.
• No user interaction required: the victim does not need to click anything or take any action.
• Broad attack surface: the vulnerable module is included in every standard NGINX build and the trigger pattern, unnamed captures in rewrite rules, is common in real-world configurations.

Put together: any unpatched, internet-exposed NGINX instance is vulnerable to denial-of-service by anyone with an HTTP client. That's the practical summary to bring to leadership.

How attackers exploit CVE-2026-42945

Exploitation is straightforward:

• No credentials required - unauthenticated exploitation.
• No user interaction required - the attacker does not need to trick anyone into clicking a link.
• Remotely exploitable - any internet-exposed NGINX instance running the vulnerable configuration is at risk. Active exploitation is confirmed in the wild.
• Public PoC available - DepthFirst published a detailed technical writeup and proof-of-concept on the day of disclosure.

The real-world impact of a successful exploit depends on ASLR status:

• ASLR enabled: the attacker can reliably crash the NGINX worker process (DoS). The worker auto-restarts, but repeated crashes create a sustained denial-of-service loop, making the service unreliable and causing requests to fail.
• ASLR disabled: the heap overflow becomes a remote code execution primitive. The attacker can execute arbitrary code as the NGINX worker user, potentially pivot to other services, read secrets from memory, or establish persistence on the host. No public exploit currently demonstrates an ASLR bypass - RCE requires ASLR to be explicitly disabled, which is non-default on modern Linux installations.

Because NGINX typically fronts many services, a compromised NGINX instance can expose every upstream application it proxies, not just the server itself.

CVE-2026-42945 disclosure timeline

How to mitigate CVE-2026-42945

The only complete remediation is upgrading NGINX to a patched version. Vendor advisories are available from F5 / NGINX and NVD. Given indicators of active exploitation are confirmed and a public PoC exists, you may want to treat this as an emergency patch based on your infrastructure and business context.

Upgrade path:

• NGINX Open Source: upgrade to 1.30.1 (stable) or 1.31.0 (mainline).
• NGINX Plus: upgrade to R36 P1.
• Audit container images, Kubernetes ingress controllers, and vendor-packaged appliances separately - embedded NGINX versions require independent patching.

If you cannot update immediately, apply these temporary controls - but understand they are not fixes:

• Rewrite your NGINX config to replace unnamed captures ($1, $2) with named captures ((?<name>...)) in all affected rewrite and set directives. F5 documents this workaround in their security advisory. This eliminates the vulnerable code path without upgrading.
• Restrict access to NGINX instances from untrusted networks using firewall rules, where operationally feasible.
• Monitor NGINX error logs and worker process restart frequency for unexpected crash patterns that may indicate active exploitation attempts.

Note: The named-capture workaround is config-specific. You must audit every rewrite rule in every server block and every included config file. If you have large or inherited NGINX configurations, the upgrade path is safer and faster than a manual config audit.

CVE-2026-42945 references

• Pentest-Tools.com Vulnerability & Exploit Database - CVE-2026-42945
• F5 / NGINX security advisory
• DepthFirst - technical analysis and PoC (depthfirst.com/nginx-rift)
• NVD - CVE-2026-42945
• The Hacker News - active exploitation confirmed

Our Network Vulnerability Scanner is a well-rounded tool for all your network security assessments.

It combines multiple engines and fine-tuned scan settings that surface more than 17,000 vulnerabilities, misconfigurations, and outdated services.

Each scan automatically updates your attack surface and provides an up-to-date map for planning targeted attacks or strategic lateral movements.

Explore a sample report which includes a vulnerability summary, automatically confirmed findings, evidence, and more.

In a transparent benchmark, our tool outperformed the 6 most popular network scanners on the market - both open-source and commercial.