A critical security vulnerability in NGINX, the web server software underpinning more than 30% of all websites globally, has been confirmed as actively exploited in the wild, less than a week after its public disclosure.
The flaw, tracked as CVE-2026-42945 and dubbed ‘NGINX Rift’, carries a severity score of 9.8 out of 10. It affects virtually every standard NGINX build released between 2008 and May 2026, an exposure window spanning 18 years.
NGINX’s developer, F5, issued an emergency patch on 13 May 2026, the same day the vulnerability was made public. A working proof-of-concept exploit was also published that day by security research group DepthFirst, and exploitation in the wild was confirmed within hours.
What the vulnerability does
The flaw lies in a component called ngx_http_rewrite_module, which handles URL rewriting, a standard feature used by virtually every NGINX installation. The bug was discovered through an AI-powered automated analysis of the NGINX source code conducted in April 2026.
In practical terms, the vulnerability allows an attacker to crash a target server with a single unauthenticated web request: no password, no login, no prior access required. In certain circumstances, it can allow an attacker to take full control of an affected system remotely.
Daniel Benechea, security manager at Pentest-Tools.com, said, “NGINX processes rewrite rules in two passes. The first calculates how much memory to allocate; the second does the actual writing. Under specific conditions, the second pass writes more data than the first reserved space. On a typical modern server, this causes a crash and restart loop, effectively a denial of service. On a system with a particular security feature disabled, it can hand an attacker control of the server.”
Because NGINX sits at the perimeter of so many internet-facing systems, handling web traffic for enterprise applications, API gateways, content delivery networks, and cloud services, a vulnerability at this layer has the potential to affect not just one organisation but every system behind it.
Patching is more complicated than it looks
F5 has released fixes across its product range. Affected organisations should upgrade to NGINX Open Source 1.30.1 (stable branch) or 1.31.0 (mainline), or NGINX Plus R36 P1. No backport patch is planned for older versions.
Security teams are, however, being warned that upgrading a primary NGINX installation may not be sufficient. Organisations running containerised applications, common across modern cloud infrastructure, may have copies of NGINX baked into container images that will not be updated automatically. Kubernetes ingress controllers, which frequently embed NGINX, require separate attention.
Benechea added, “Upgrade first. Then check your container images and Kubernetes ingress controllers separately. Upgrading your main NGINX install doesn’t automatically update those. For most teams, just upgrading is the simpler and safer path.”
For organisations that cannot patch immediately, F5 has documented a configuration-level workaround, but security teams note it requires manually auditing every rewrite rule across all configuration files, which is a significant undertaking for large or inherited deployments.
Free scanner released
Cybersecurity company Pentest-Tools.com has added detection for CVE-2026-42945 to its Network Vulnerability Scanner and is making it freely available with no account required. The scanner checks which version of NGINX is running on a given system and flags any instance within the vulnerable range.
The tool is available here: https://pentest-tools.com/network-vulnerability-scanning/cve-2026-42945-scanner-nginx-rift. Findings are labelled as unconfirmed, consistent with version-based detection, meaning a flagged result indicates a vulnerable version is present but does not confirm whether the specific trigger conditions are active in that system’s configuration.
A signal about the future of vulnerability research
The discovery of NGINX Rift carries a notable footnote: the flaw was found not by a human researcher but by an automated, AI-powered analysis of the NGINX source code. DepthFirst ran the analysis in April 2026 and disclosed the finding responsibly before publishing its technical write-up on the day F5 issued its patch.
“An 18-year-old flaw hiding in a module that ships by default in every NGINX build is exactly the kind of exposure that’s hard to find without automated analysis. That says something meaningful about where vulnerability research is heading; systematic coverage of codebases that have been running in production for years without close scrutiny,” Benechea concludes.
The finding raises questions about how many similar long-standing flaws may remain undiscovered in widely deployed open-source software, and whether automated tooling will increasingly be the means by which they surface.
What organisations should do now.
- Patch immediately. Upgrade to NGINX Open Source 1.30.1 / 1.31.0 or NGINX Plus R36 P1.
- Audit container images. Check for NGINX binaries embedded in container images separately from your primary installation.
- Check Kubernetes ingress controllers. These frequently embed NGINX and require independent patching.
- Use the free scanner. Pentest-Tools.com’s no-login scanner can confirm whether exposed versions are present on your external attack surface.
