A single crafted HTTP request, without any authentication, is all that is needed to run a CVE-2026-42945 exploit – now dubbed “NGINX Rift” – past researchers. The vulnerability carries a CVSS v4 score of 9.2.
NGINX Rift is a critical heap buffer overflow that sat undetected in NGINX's URL rewriting engine since 2008. Within days of publishing proof-of-concept code, exploitation attempts in the wild were spotted. And as of May 18, 2026, active exploitation has been confirmed.
Organizations running NGINX, which is about one in three websites globally, plus any organization running a substantial share of enterprise reverse proxies, API gateways, and Kubernetes ingress controllers, are at significant risk until they mitigate the vulnerability in their environments.
Eric Parizo, founder and chief analyst at Cernivera Research, noted in Cernivera’s NewsWire that researchers initially debated the real-world exploitability of NGINX Rift, stating that it required specific conditions to work. “But it’s clear the Nginx vulnerability situation is now much more serious,” Parizo said. “The 48-hour window from PoC to exploitation is consistent with the collapsing patch timelines Cernivera has been documenting throughout 2026.”
“Organizations should inventory all Nginx deployments — including those bundled inside other products — and patch to 1.31.0 or 1.30.1. For environments where the specific rewrite configuration is not in use, the risk is lower, but patching remains the right call given the severity and the pace of exploitation,” he continued.
What the Flaw Is and Where It Lives
NGINX's architecture includes a single master process that manages multiple worker processes, and each worker handles thousands of simultaneous connections in a single thread. When a worker process crashes, the master restarts the worker without service interruption, but repeated crashes constitute a persistent denial-of-service condition. Under the right circumstances, specifically, systems running with ASLR (Address Space Layout Randomization) disabled, that same memory corruption can yield a full remote code execution.
The vulnerability lives in the “ngx_http_rewrite_module,” the component responsible for URL rewriting, query string manipulation, and variable assignment through the “rewrite,” “if,” and “set” directives. It was introduced in version 0.6.27 in 2008 and affected every subsequent open-source release through 1.30.0. When an unauthenticated remote attacker sends a malformed HTTP request, the overflow is triggered. The module does not validate the input before writing to the heap, and the rest is not good.
Security research firm depthfirst discovered the vulnerability in mid-April 2026 using an AI-assisted autonomous source code analysis system. A researcher onboarded the NGINX GitHub repository, initiated the analysis, and six hours later, the system had flagged five memory corruption issues. Depthfirst reported all findings via GitHub Security Advisory on April 21. By April 28, the firm had a working proof-of-concept for remote code execution and informed NGINX. The full PoC and a demonstration video went to NGINX on May 5. F5 released patches on May 13; depthfirst published its complete technical write-up the same day. The PoC (proof-of-concept) code became publicly available on GitHub on May 15.
Forty-six days from discovery to public exploit code is a tight window. With exploitation confirmed two days after the PoC dropped, it contracted further.
Best Practices That Narrow the Window
The organizations best positioned to weather a vulnerability like this are those that complete the unglamorous work of building defensible-by-default infrastructures.
Ideally, a vulnerability and patch management program with enforced service-level agreements (SLAs) should be in place, but the data on this actually happening is not encouraging. Dark Reading's 2026 Application Security Survey found that 65% of organizations justify security spending primarily in response to audit findings. A reactive program will produce reactive mitigation cycles.
Network segmentation and defense-in-depth limit the scope of a successful exploit. NGINX commonly sits at the perimeter, such as within a reverse proxy, load balancer, or ingress controller. Any compromised worker process is likely next to the backend infrastructure. Organizations that have enforced strict egress controls, micro-segmentation between the proxy tier and application tier, and robust monitoring have materially better identification and response.
Web application Firewalls (WAFs) provide a third layer of protection. The same Dark Reading survey found that 52% of respondents use WAFs as part of layered defense, while 27% deploy them as a temporary virtual patch while underlying flaws are remediated. For NGINX Rift, a WAF capable of detecting malformed HTTP requests targeting known overflow patterns can reduce exposure during patching. Fourteen percent of respondents told Dark Reading they rely heavily on WAFs in place of patching application flaws. Let’s hope that’s used as a bridge to actual patch deployment whenever reasonably possible.
Disabling ASLR on production systems is a misconfiguration transforms a DoS vulnerability into an (remote-code execution) RCE vulnerability. Any organization that has not audited its NGINX instances to determine their ASLR status should consider doing so.
The Risks Ahead
The same AI-assisted analysis capability that found this flaw is certainly available to threat actors. The same technology is also available to application security teams. If depthfirst's system surfaced five memory corruption issues in a single pass (four confirmed by NGINX), adversarial systems running similar analyses across a target's software stack can be expected to surface comparable findings. Their disclosure won’t be publicly coordinated.
Related:
George V. Hulme
Robert Hansen
This asymmetry favors the attacker until defenders close it through faster patching cycles, more aggressive security monitoring instrumentation of edge components, and the kind of proactive investment that Dark Reading's survey data shows is still the minority position in most organizations.
“AI assisted code auditing is clearly a baseline now, but I also think major OSS projects have had one. Perhaps not orchestrated by themselves, but they’re definitely being looked at. AI assistants make it much easier and vastly more scalable, and of course, there is unfortunately ample incentive to find CVEs,” John Morello, co-founder and CTO at container security firm Minimus, said.
However, when it comes to the benefits of AI-driven code audits, not everyone is convinced that it’s all positive for organizations. “I wouldn’t recommend AI security audit as a professional baseline,” Jeff Williams, founder of OWASP and founder and CTO at application security platform provider Contrast Security, said. “There are several problems. First, it’s very expensive. With a sophisticated harness and a frontier model, even medium-sized applications could cost tens of thousands of dollars,” he said.
“Second, they’re way too slow to be part of a build pipeline. Third, they’re non-deterministic,” he added.
“We found that successive runs of the same model only identify about 20% of the same issues. And different models overlap only 6%. Finally, they’re inaccurate. We ran several models against the OWASP Benchmark, and the accuracy rate is under 5%. So maybe if you’ve done everything else you can possibly think of and fixed all your vulnerabilities and libraries, then maybe you should try AI. But not before,” he said.
Still, vulnerabilities are being uncovered at an unprecedented rate, and NGINX Rift is a discrete problem with a discrete fix. The conditions that allowed it to persist for eighteen years are not.
