If you operate any internet-facing infrastructure, there is a reasonable chance NGINX is somewhere in your stack. It sits in front of roughly a third of the public internet: as a web server, a reverse proxy, an API gateway, a load balancer, an ingress controller for Kubernetes clusters. That ubiquity is what makes the vulnerability disclosed on May 13, 2026, worth stopping everything to read about.
The vulnerability is called NGINX Rift, tracked as CVE-2026-42945, with a CVSS v4 score of 9.2. It is a heap buffer overflow in NGINX's rewrite module that has been present in the codebase since 2008. A working public proof-of-concept was published on the same day as disclosure, and active exploitation was confirmed in the wild within three days. The window for unhurried response has already closed.
How this came to light
NGINX Rift was discovered autonomously by the security research firm depthfirst during a code audit. Notably, all four memory corruption issues found in NGINX were surfaced in a single six-hour automated scanning session on April 18, 2026, a detail that speaks to both the power of the tooling and the density of latent issues in code that has never been subjected to this kind of systematic analysis.
Responsible disclosure was made to F5 on April 21, 2026. F5 confirmed, patched, and published a coordinated advisory on May 13, 2026, the same day depthfirst released its full technical write-up and a public proof-of-concept exploit. The disclosure process was orderly, and patches were available from F5 at the moment the vulnerability became public knowledge.
That orderliness did not slow down the attackers. According to VulnCheck's Canary Intelligence honeypot network, active exploitation attempts were detected in the wild by May 16, three days after disclosure, and VulnCheck issued a KEV (Known Exploited Vulnerability) alert the same day.
What is NGINX Rift?
NGINX Rift is a heap buffer overflow in ngx_http_rewrite_module, the component of NGINX responsible for URL rewriting, variable assignment, and conditional logic. This module is compiled into every standard NGINX build and is in use across virtually all non-trivial NGINX deployments.
The bug was introduced in NGINX version 0.6.27, released in 2008, and went undetected across every subsequent release up to and including 1.30.0. That's a span of 18 years.
The root cause
The flaw arises from a state mismatch between two internal passes that NGINX uses when processing rewrite directives.
NGINX's script engine computes the size of a destination buffer in a first pass, then copies data into that buffer in a second pass. The problem occurs when a rewrite directive uses an unnamed PCRE capture group (such as $1 or $2) in combination with a replacement string containing a question mark (?), followed by another rewrite, if, or set directive.
When a question mark appears in a replacement string, NGINX's script engine sets an internal flag (is_args = 1) on the main engine object. During the first (length-calculation) pass, however, the calculation runs on a freshly zeroed sub-engine where that flag is absent. As a result, the length calculation does not account for URI escaping. During the second (copy) pass, the main engine, which still carries is_args = 1, routes the data through ngx_escape_uri in NGX_ESCAPE_ARGS mode, which expands certain bytes (such as +, %, and &) from one byte to three. More data is written into the buffer than was allocated, producing a deterministic heap buffer overflow.
Critically, the overflow is controlled by the attacker: the bytes written past the allocation boundary are derived from the URI the attacker supplies. The corruption is shaped, not random.
What an attacker can do
For the majority of vulnerable servers, the immediate and reliable impact is a denial of service. An attacker can send a single crafted HTTP GET request to trigger a crash of the NGINX worker process. Repeated requests keep workers in a crash loop, degrading availability for every site served by the instance. Researchers demonstrated that a working PoC required only standard Python sockets and a crafted request roughly 2,350 bytes in length.
Remote code execution (RCE) is possible, but with an important caveat: it requires that Address Space Layout Randomization (ASLR) be disabled on the target system. ASLR is enabled by default on modern Linux distributions, so the RCE path is not achievable against the majority of internet-exposed NGINX servers in typical configurations. Legacy systems, embedded environments, or misconfigured deployments where ASLR has been explicitly disabled remain at full RCE risk.
For RCE, depthfirst's research describes the technique as cross request heap feng shui[^1]: an attacker first opens a partial connection to allocate a request pool, then opens a second connection and corrupts the pool header of that victim connection via the overflow, allowing control of execution.
[^1]: depthfirst NGINX Rift: Achieving NGINX Remote Code Execution via an 18-Year-Old Vulnerability, May 13, 2026
NGINX's multi-process architecture is a factor here that works in the attacker's favour. Worker processes inherit nearly identical memory layouts from the master process, and if an exploit attempt crashes a worker, the master process simply spawns a fresh replacement with the same memory layout. This means an attacker can retry failed attempts without the target's memory state changing between attempts, making iterative exploitation more feasible than it would be against a single-process architecture.
There is no authentication step, no prior access requirement, and no need for an existing session. Any attacker who can reach a vulnerable NGINX server over HTTP has everything they need.
The three other CVEs patched alongside NGINX Rift
The depthfirst code audit that found CVE-2026-42945 also identified three additional memory corruption flaws, all patched in the same F5 advisory release:
| CVE | CVSS v4 | Affected Module | Vulnerability Type | Impact |
|---|---|---|---|---|
| CVE-2026-42945 | 9.2 (Critical) | ngx_http_rewrite_module | Heap buffer overflow | DoS; RCE if ASLR disabled |
| CVE-2026-42946 | 8.3 (High) | ngx_http_scgi_module / ngx_http_uwsgi_module | Excessive memory allocation (~1TB) | Memory disclosure or worker restart (requires AitM position) |
| CVE-2026-40701 | 6.3 (Medium) | ngx_http_ssl_module | Use-after-free (async OCSP DNS resolution) | Limited data modification or worker restart |
| CVE-2026-42934 | 6.3 (Medium) | ngx_http_charset_module | Off-by-one UTF-8 out-of-bounds read | Memory disclosure or worker restart |
CVE-2026-42946 warrants particular attention for organisations that expose SCGI or uWSGI backends: it can allow an adversary-in-the-middle attacker controlling upstream responses to read NGINX worker process memory. The other two flaws require specific directive configurations to be reachable.
Who is affected?
The vulnerability affects a very wide range of F5 and NGINX products. The following table summarises the affected version ranges and the patched releases:
| Product | Affected Versions | Fixed In |
|---|---|---|
| NGINX Open Source | 0.6.27 – 1.30.0 | 1.30.1 (stable), 1.31.0 (mainline) |
| NGINX Open Source | 0.6.27 – 0.9.7 | No fix planned (EoTS) |
| NGINX Plus | R32 – R36 | R32 P6, R36 P4 |
| NGINX Instance Manager | 2.16.0 – 2.21.1 | 2.21.2+ |
| F5 WAF for NGINX | 5.9.0 – 5.12.1 | 5.12.2+ |
| NGINX App Protect WAF | 4.9.0 – 4.16.0 and 5.1.0 – 5.8.0 | 4.16.1+ / 5.8.1+ |
| F5 DoS for NGINX / NGINX App Protect DoS | 4.8.0 and 4.3.0 – 4.7.0 | 4.8.1+ / 4.7.1+ |
| NGINX Gateway Fabric | 1.3.0 – 1.6.2 and 2.0.0 – 2.5.1 | 1.6.3+ / 2.5.2+ |
| NGINX Ingress Controller | 3.5.0 – 3.7.2, 4.0.0 – 4.0.1, 5.0.0 – 5.4.1 | 3.7.3+ / 4.0.2+ / 5.4.2+ |
F5 Distributed Cloud, F5 Silverline, NGINX One Console, BIG-IP, BIG-IQ, F5OS, Traffix SDC, and F5 AI Gateway are not affected.
Note that NGINX Open Source versions 0.6.27 through 0.9.7 have reached End of Technical Support and F5 has no plans to issue patches for those branches. Organisations still running these very old releases should treat an upgrade as urgent.
A Censys scan surfaced approximately 5.7 million internet-exposed NGINX servers running a potentially vulnerable version. The truly exploitable subset, those running the specific rewrite configuration pattern that triggers the flaw, is smaller, but with that exposure surface, the number of at-risk deployments in absolute terms remains large.
Where the risk is concentrated
Not every NGINX deployment is equally exposed. The vulnerability is only reachable when the server configuration includes both an unnamed PCRE capture group and a replacement string containing a question mark in a rewrite directive, followed by another rewrite, if, or set directive. This is a pattern commonly found in:
API gateways. Rewrite-heavy configurations that route requests based on URL patterns and pass query parameters are the typical trigger environment. Organisations using NGINX as an API gateway should consider themselves at elevated risk until they have confirmed their configuration status.
Multi-tenant and container platforms. NGINX Ingress Controller and NGINX Gateway Fabric deployments in Kubernetes environments where the configuration is managed by templates or third-party chart authors may be running the vulnerable pattern without operators being aware.
Load balancers and reverse proxies with complex routing. Organisations that have built intricate routing logic in NGINX using rewrite chains should audit each affected directive before concluding they are safe.
Legacy systems where ASLR may have been disabled, whether intentionally for debugging or inadvertently through older default configurations, face full RCE exposure, not merely DoS.
Active exploitation: what we know
Exploitation moved faster than is typical for a newly disclosed critical vulnerability.
A public proof-of-concept was published on GitHub on May 13, 2026, the same day as the F5 advisory. By May 16, VulnCheck's honeypot network had detected real exploitation attempts in the wild, and Cloudflare issued an emergency WAF rule update on May 15 to detect heap buffer overflow and heap spray attempts associated with this flaw.
The PoC demonstrated that the DoS path requires only a minimal Python script - no exotic tooling, no compiled exploit code, no authenticated access. That low bar to entry means that opportunistic and automated scanning tools can and likely will weaponise it widely.
The RCE path is more involved, requiring a more precise tactic across multiple requests and ASLR being off, but the DoS path alone is sufficient to cause significant operational disruption for any organisation running vulnerable NGINX deployments at scale.
What should you do?
1. Determine whether your configuration is vulnerable
The vulnerability is only triggerable when your NGINX configuration contains a specific pattern. Before anything else, audit your configuration files:
grep -rn 'rewrite' /etc/nginx/ | grep -E '\$[0-9]+'
Look for rewrite directives that use unnamed capture groups (e.g., $1, $2) and where the replacement string contains a question mark (?). If this pattern exists and is followed by another rewrite, if, or set directive in the same scope, your deployment is vulnerable.
2. Patch immediately
Install one of the fixed releases. For NGINX Open Source:
# Ubuntu / Debian
sudo apt-get update && sudo apt-get install nginx
# RHEL / Rocky / AlmaLinux / Amazon Linux
sudo dnf update nginx
# SUSE / openSUSE
sudo zypper update nginx
# Arch Linux
sudo pacman -Syu nginx
Target versions: NGINX Open Source 1.30.1 (stable branch) or 1.31.0 (mainline branch). For NGINX Plus, the target releases are R32 P6 and R36 P4. Consult the F5 security advisory for the full matrix of fixed versions across Instance Manager, App Protect, Gateway Fabric, and Ingress Controller.
Restart NGINX after upgrading to ensure workers reload with the patched binary:
sudo nginx -t && sudo systemctl reload nginx
Verify the running version after patching:
nginx -v
3. If you cannot patch immediately: reconfigure affected rewrite directives
If patching is not immediately possible, the configuration change below eliminates the vulnerable code path without requiring a software update. Replace unnamed PCRE captures with named captures in every affected rewrite directive.
Vulnerable pattern:
rewrite ^/users/([0-9]+)/profile/(.*)$ /profile.php?id=$1&tab=$2 last;
Safe pattern:
rewrite ^/users/(?<user_id>[0-9]+)/profile/(?<section>.*)$ /profile.php?id=$user_id&tab=$section last;
This is the official interim mitigation recommended by F5. It changes the configuration so that the state mismatch in the script engine no longer produces a dangerous size discrepancy. The functional behaviour of the rewrite rule is preserved.
4. Apply or verify WAF coverage
Cloudflare released an emergency WAF rule update on May 15 to detect exploitation attempts targeting this vulnerability. If your NGINX deployments sit behind a WAF or CDN with a managed ruleset, verify that the ruleset has been updated and that the relevant rules are in blocking mode. This is a defence-in-depth measure, not a substitute for patching.
5. Review your NGINX Ingress and Gateway Fabric configurations
For Kubernetes environments using NGINX Ingress Controller or NGINX Gateway Fabric, the rewrite configuration is often managed through Ingress annotations or HTTPRoute resources rather than direct nginx.conf editing. Review your Ingress resources for nginx.ingress.kubernetes.io/rewrite-target annotations and any custom snippet annotations that introduce rewrite logic. Update to the patched Ingress Controller or Gateway Fabric versions as soon as they are available from your distribution channel.
Detection
Unlike page-cache write primitives such as Fragnesia or Dirty Frag, NGINX Rift leaves detectable traces. The DoS path produces NGINX worker process crashes, which generate log entries in both the NGINX error log and the system journal:
# Check NGINX error log for worker crash events
grep "worker process" /var/log/nginx/error.log | grep -E 'exited|signal'
# Check system journal for NGINX process restarts
journalctl -u nginx --since "24 hours ago" | grep -i "started\|stopped\|failed"
Repeated short-interval worker restarts with no corresponding legitimate traffic pattern are a strong indicator of exploitation attempts. The request that triggers the crash will appear in the NGINX access log immediately before the error log entry for the worker exit.
For the RCE path, monitoring for unusual child process spawning from NGINX worker processes via auditd or eBPF-based tools is appropriate on systems where ASLR may be disabled.
Detection rules and updated guidance will be published to our GitHub repository as they are developed.
A note on the scale of exposure
The fact that this vulnerability remained in the NGINX codebase for 18 years without detection should prompt a broader conversation about how critical open-source infrastructure is reviewed for security issues. NGINX is not an obscure project: it is among the most widely deployed pieces of software on the public internet, with billions of requests flowing through it daily. A flaw introduced in 2008 surviving undetected until an automated code audit found it in 2026 illustrates the gap between a project's deployment scale and the security scrutiny applied to its internals.
depthfirst's disclosure notes that this vulnerability was found autonomously by their platform during a code audit, not by a human researcher reading through ngx_http_script.c line by line. That is worth noting, as it suggests the vulnerability was accessible to anyone running a sufficiently capable automated analysis, and raises the question of whether it has been silently known to and exploited by sophisticated threat actors before its public disclosure. There is currently no evidence of pre-disclosure exploitation, but the possibility cannot be categorically excluded for a flaw of this age and severity.
Summary
| CVE | CVE-2026-42945 |
| Nickname | NGINX Rift |
| CVSS Score | 9.2 (Critical, v4) / 8.1 (High, v3.1) |
| Type | Heap Buffer Overflow |
| Discovered by | depthfirst (autonomous code audit, April 2026) |
| Disclosed | May 13, 2026 (coordinated with F5) |
| Affected | NGINX Open Source 0.6.27 – 1.30.0; NGINX Plus R32 – R36; NGINX Instance Manager, App Protect WAF/DoS, Gateway Fabric, Ingress Controller |
| Not affected | F5 Distributed Cloud, F5 Silverline, NGINX One Console, BIG-IP, BIG-IQ, F5OS, Traffix SDC, F5 AI Gateway |
| Trigger condition | Unnamed PCRE capture + ? in replacement string + subsequent rewrite/if/set directive |
| Immediate impact | Unauthenticated DoS (worker crash loop) against any vulnerable configuration |
| Full RCE? | Yes, but only when ASLR is disabled on the target |
| Public PoC? | Yes — published May 13, 2026 |
| Active exploitation? | Yes — confirmed May 16, 2026 by VulnCheck |
| Immediate mitigation | Replace unnamed PCRE captures with named captures in all affected rewrite directives |
| Full fix | Upgrade to NGINX Open Source 1.30.1 or 1.31.0; NGINX Plus R32 P6 or R36 P4 |
| WAF coverage | Cloudflare emergency rule released May 15, 2026 |
With 5.7 million potentially vulnerable NGINX instances exposed to the internet and active exploitation already confirmed, this is a patch that should not wait for the next scheduled maintenance window. The configuration mitigation is a one-line change per affected directive, it requires no restart, and it eliminates the vulnerability entirely while you prepare for a full upgrade.
If you need help auditing your NGINX configurations for the vulnerable rewrite pattern, assessing your Kubernetes ingress exposure, or deploying detection coverage across your fleet, get in touch. An 18-year-old flaw in infrastructure this widely deployed deserves to be taken seriously — and quickly.