An AI Found an 18-Year-Old NGINX RCE in Six Hours — CVE-2026-42945 'NGINX Rift'
An autonomous AI was pointed at the NGINX source code and found a critical RCE that survived 18 years of human review — plus three more CVEs in the same six-hour session. NGINX runs a third of the internet's top sites. The discovery method is the bigger story.
An autonomous AI system was pointed at the NGINX source code and, in roughly six hours, found a critical remote-code-execution flaw that had survived 18 years of human review — plus three more CVEs in the same session. NGINX runs about a third of the internet's top sites. The patch is out. The bigger story is the discovery method.
SEATTLE, WA — F5 disclosed on May 13, 2026 a critical heap buffer overflow in NGINX's ngx_http_rewrite_module, tracked as CVE-2026-42945 and codenamed "NGINX Rift," scored CVSS v4 9.2 (Critical) and CVSS v3.1 8.1 (High). The flaw has been present in the codebase since NGINX 0.6.27 in 2008 — 18 years of releases, through version 1.30.0. It allows an unauthenticated attacker to achieve remote code execution or denial-of-service by sending crafted HTTP requests, and a public proof-of-concept exploit is already available on GitHub. NGINX powers roughly one-third of all top-ranked websites globally, and is used across cloud providers, SaaS companies, banks, media platforms, e-commerce sites, and Kubernetes clusters.
The vulnerability was discovered by DepthFirst AI's autonomous vulnerability analysis system — pointed at the NGINX source code, it flagged the heap overflow in approximately six hours of code auditing. Three additional memory-corruption CVEs were found in that same six-hour session: CVE-2026-42946, CVE-2026-42934, and CVE-2026-40701. F5 has released patches: NGINX Open Source 1.31.0 and 1.30.1, and NGINX Plus R36 P4 and R32 P6. The flaw is only reachable when a configuration contains a specific pattern — a rewrite directive with an unnamed PCRE capture and a ? in the replacement string, followed immediately by another rewrite, if, or set directive — and security researcher Kevin Beaumont has noted the published RCE proof-of-concept was tested with ASLR disabled.
Patch Now, or Convert Your Unnamed Captures
The remediation path is straightforward and should be the first action of the week for any organization running NGINX. Upgrade to NGINX Open Source 1.31.0 or 1.30.1, or NGINX Plus R36 P4 or R32 P6. If immediate patching is not possible, F5's documented workaround is to replace unnamed PCRE captures — $1, $2, and so on — with named captures in every affected rewrite directive, because named captures do not pass through the vulnerable URI-escaping logic. The affected product surface is broad: NGINX Open Source, NGINX Plus, NGINX Instance Manager, NGINX App Protect WAF, and the NGINX Ingress Controller. Kubernetes operators running the NGINX Ingress Controller should treat this as an immediate-priority patch, since ingress is a particularly high-value target reachable from the public internet.
Kevin Beaumont's pushback is worth carrying alongside the severity rating, because it bounds the panic appropriately. Exploitation requires a vulnerable NGINX configuration with the particular rewrite pattern; an attacker must know or discover an affected endpoint; and the published RCE proof-of-concept was tested with ASLR disabled, meaning reliable code execution against a hardened, ASLR-enabled target is meaningfully harder than the CVSS 9.2 alone suggests. The denial-of-service path, however, is possible regardless of ASLR. The honest framing for defenders: patch urgently, but audit your configurations for the actual vulnerable pattern rather than assuming every NGINX instance is one HTTP request from RCE. Most are not — but the ones with the matching rewrite pattern, common in API gateway routing, are.
Six Hours, Four CVEs, 18 Years — The Discovery Method Is the Story
The NGINX Rift discovery is the clearest case to date of an autonomous AI system finding a critical, long-dormant vulnerability that thousands of human engineers, security researchers, and open-source contributors had not. DepthFirst's system was pointed at the NGINX source code and surfaced a heap overflow that had evaded detection for 18 years — in roughly six hours, and it found three more memory-corruption bugs in the same session. NGINX is known for a clean codebase and a strong security track record. As DepthFirst's own write-up frames it, if NGINX is not safe from this class of bug, no C codebase is.
This is the empirical companion to the AI-vulnerability-discovery trend defenders have been tracking from the offensive side. Google's disclosure of the first AI-generated zero-day in the wild, Germany's warning about a Chinese AI 'superhacker', and Kaspersky's finding of apparently LLM-developed code in a North Korean backdoor all describe AI's role in offense. NGINX Rift shows the same capability applied to defense — and the same capability cuts both ways. The strategic line DepthFirst draws is the one CISOs should internalize: the AI era of vulnerability discovery is just beginning, and we should expect more revelations like this, not fewer.
What the AI Discovery Era Means for Vulnerability Management
The operational consequence of six-hour audits finding 18-year-old critical bugs is that vulnerability management programs need to plan for a higher discovery velocity. Patch SLAs for critical-CVSS bugs were calibrated for a world where flaws in well-audited C codebases surfaced rarely. Mass AI auditing of open-source dependencies changes that cadence — DepthFirst's six-hour NGINX audit produced four CVEs, and DepthFirst is one organization. The same technique applied across Apache, OpenSSL, the Linux kernel, and the rest of the open-source C ecosystem should be assumed to be generating a backlog of disclosures that will land over the coming months. The defensive posture is to assume there are more undiscovered bugs in your dependencies — the ones found so far are simply what the current generation of AI tooling has found.
That is the same dynamic visible in the broader 2026 zero-day landscape, including the Dirty Frag Linux kernel local privilege escalation — long-lived bugs in foundational software, surfacing with public proof-of-concept code attached. For CISOs, the practical steps are to pre-script the "AI-discovered critical CVE in our stack" scenario, inventory C-based infrastructure for similar long-dormant exposure, and update patch-SLA assumptions so the vulnerability management program is not perpetually behind the discovery curve. DevOps and platform teams should adopt named PCRE captures by default in NGINX configurations going forward as defense-in-depth, and implement automated vulnerability monitoring for NGINX-class infrastructure so the next disclosure in this pattern is caught at machine speed.
The CyberSignal Analysis
Signal 01 — Patch NGINX Now, but Audit for the Actual Vulnerable Pattern Rather Than Panicking Blindly
CVE-2026-42945 is a real critical RCE with a public proof-of-concept, and every internet-facing NGINX instance should be patched to 1.31.0 / 1.30.1 (or NGINX Plus R36 P4 / R32 P6) this week. But Kevin Beaumont's caveats matter for triage: exploitation requires the specific rewrite-plus-question-mark configuration pattern, the attacker must find an affected endpoint, and the RCE proof-of-concept was tested with ASLR disabled. Audit your configurations for the vulnerable pattern — common in API gateway routing — and prioritize those instances. Where you cannot patch immediately, convert unnamed PCRE captures to named captures, which bypass the vulnerable escaping logic entirely. Kubernetes NGINX Ingress Controller deployments are the highest-priority patch target.
Signal 02 — AI Vulnerability Discovery Is Now Operational Reality, and Patch SLAs Were Calibrated for a Slower World
NGINX Rift is the clearest evidence yet that autonomous AI systems can find critical, decades-old vulnerabilities in the most-audited C codebases in hours. DepthFirst's single six-hour audit produced four CVEs; the same technique applied across the open-source C ecosystem will generate a sustained wave of disclosures. Update vulnerability management assumptions accordingly: patch SLAs for critical bugs now have to account for an "discovered by AI in hours" discovery cadence, not the slower pace the program was likely designed around. Inventory your C-based infrastructure — Apache, OpenSSL, Linux kernel, and dependencies — for similar long-dormant exposure, pre-script the AI-discovered-CVE scenario, and assume the bugs found so far are just what the current tooling generation has surfaced.
What to Do This Week
- Identify every NGINX instance in your environment, prioritizing public-internet-facing ones, and patch to NGINX Open Source 1.31.0 or 1.30.1, or NGINX Plus R36 P4 or R32 P6. Treat NGINX Ingress Controller deployments in Kubernetes as immediate-priority — audit Helm charts for affected versions across all clusters.
- Where immediate patching is not possible, replace unnamed PCRE captures ($1, $2, etc.) with named captures in every affected rewrite directive — named captures bypass the vulnerable URI-escaping logic. Adopt named captures by default going forward as defense-in-depth.
- Audit configurations for the vulnerable pattern: a rewrite directive with an unnamed PCRE capture and a question mark in the replacement string, followed immediately by another rewrite, if, or set directive. This pattern is common in API gateway routing. Implement WAF rules to block crafted requests matching the exploit signature.
- For SOC teams: add CVE-2026-42945 detection signatures, monitor for unusual HTTP request patterns matching the exploit, and watch for NGINX worker process crashes above baseline — the denial-of-service path is reachable regardless of ASLR.
- Update your vulnerability management program for the AI discovery era. Recalibrate patch SLAs for critical-CVSS bugs, inventory C-based infrastructure (Apache, OpenSSL, Linux kernel, dependencies) for similar long-dormant exposure, and pre-script the "AI-discovered critical CVE in our stack" scenario. Assume more disclosures in this pattern are coming.
