Dateline: May 14, 2026
One Third of the Web Runs NGINX. A New Critical Bug Affects All of It.
NGINX, the web server that quietly runs roughly a third of all websites on the internet, has been shipping a critical remote code execution flaw since 2008. The vulnerability, now tracked as CVE-2026-42945 and nicknamed “NGINX Rift,” was disclosed jointly by F5 and depthfirst on May 13, 2026.
It carries a CVSS score of 9.2 and affects every NGINX version from 0.6.27 through 1.30.0. What makes this disclosure unusual is not the bug itself, but the fact that human researchers missed it for 18 years. An AI-driven vulnerability analysis system flagged it in roughly six hours.
What Happened?
The flaw lives inside the ngx_http_rewrite_module, a piece of NGINX used for handling URL rewrites. When a request triggers a specific sequence involving rewrite and set directives, an internal flag fails to propagate properly. The result is an undersized memory buffer, and when attacker-controlled URI data gets copied into that buffer, it overruns the heap. Once the heap is corrupted, code execution follows.
Researchers at depthfirst built a working proof-of-concept showing unauthenticated remote code execution against vulnerable servers. They note that NGINX spawns identical replacement workers after each crash, which gives attackers unlimited retry attempts to defeat ASLR without needing a separate information leak.
Alongside the headline bug, NGINX patched three more issues in the same release: a memory exhaustion flaw in the SCGI and uWSGI modules (CVE-2026-42946), a use-after-free in the SSL module (CVE-2026-40701), and an out-of-bounds read in the charset module (CVE-2026-42934). Fixed versions are 1.31.0 and 1.30.1.
What’s the Impact?
NGINX powers a massive share of the public web, sitting in front of everything from Fortune 500 customer portals to small developer projects. The blast radius for this one is huge. Any server running an unpatched NGINX version with a rewrite directive in its configuration is potentially exposed to unauthenticated remote code execution from anywhere on the internet.
The deeper story is harder to ignore. NGINX has a reputation for a clean codebase and a strong security track record. If a critical bug can hide there for 18 years, the assumption that any C-based infrastructure has been thoroughly audited deserves a second look. AI-assisted vulnerability discovery is going to keep surfacing finds like this, which means the next critical CVE in a piece of trusted infrastructure is closer than most teams think.
How to Avoid This
Upgrade to NGINX 1.31.0 (mainline) or 1.30.1 (stable) without waiting for a scheduled maintenance window. If a full upgrade is not immediately possible, audit your configuration files for the vulnerable pattern, specifically any combination of rewrite followed by set directives with the $args variable. Removing or restructuring that pattern blocks the trigger condition.
Once patched, scan access logs for unusual rewrite traffic and repeated worker crashes, which are likely indicators of an exploit attempt. Public PoC code already exists, so opportunistic scanning will follow quickly.
The Quiet Servers in Your Stack Are the Loudest Risk
Every infrastructure team has NGINX running somewhere, often forgotten about because it works. That is precisely what makes long-lived bugs in core infrastructure so dangerous.
Secure.com gives security teams continuous visibility into the components their environment depends on, so vulnerabilities in foundational software don’t sit unpatched for weeks.
- Maps every NGINX instance in your environment, including the ones outside your asset inventory
- Correlates new CVE disclosures against your actual deployed versions automatically
- Flags vulnerable configuration patterns inside your NGINX setup, not just outdated binaries
- Keeps incident cases open across the 90-day window where related signals tend to surface
- Generates audit-ready evidence trails for regulators and customers asking “what did you patch and when”
