Dateline: June 18, 2026
NGINX Rift: The 9.2 Flaw Hiding in Web Server Code Since 2008
NGINX runs roughly one in three websites on the planet. So when F5 pushed out an emergency patch for a flaw that lets a stranger crash your server with nothing more than a bad web request, that is worth dropping what you are doing for. A proof-of-concept exploit landed the same day as the fix.
What Happened?
F5, which owns NGINX, patched a set of NGINX vulnerabilities, and one stands out. It is tracked as CVE-2026-42945, nicknamed NGINX Rift, and it scored a 9.2 out of 10. The bug sits in the rewrite module, the part of NGINX that handles URL rewriting when traffic gets routed to a backend.
Here is the kicker. This flaw has been hiding in the code since 2008. Every version from 0.6.27 through 1.30.0 carries it. It was found by a vulnerability research firm that ran an AI scanner over the NGINX source, which is a sign of where bug hunting is headed.
The problem is a heap buffer overflow. When NGINX rewrites a request, it first works out how much memory to set aside. But when it expands certain special characters for safe handling, like turning a plus sign or ampersand into its encoded form, those characters eat up more space than planned. The buffer runs out. A remote attacker with no login can send a malformed HTTP request and trigger it.
That means a denial of service at minimum, knocking the worker process offline. At worst, it opens the door to remote code execution. F5 was clear that this is a data plane issue, not a control plane one, but on a public-facing web server that is still a serious exposure.
The same patch round fixed related memory bugs too, including CVE-2026-42946, where attackers can trick NGINX into trying to allocate around a terabyte of memory and crash the worker, plus a couple of use-after-free and out-of-bounds read flaws.
What’s the Impact?
The risk is not spread evenly. The bug only fires when NGINX uses rewrite and set directives together, a setup that is everywhere. Think WordPress permalinks, PHP front controllers, and API gateways that bridge public URLs to internal endpoints. Shared hosting platforms that auto-generate NGINX configs are squarely in the blast zone.
Attackers can scan the whole internet fast, checking server responses to find machines that match the vulnerable pattern. No credentials needed. Researchers noted that turning the public proof-of-concept into a working remote code execution exploit takes effort, but the denial-of-service path is far simpler, and active exploitation has already been reported.
How to Avoid This
Update now to NGINX 1.31.0 or 1.30.1, the patched releases. This is the real fix. If you cannot patch right away, edit your config so no rewrite directive matches the vulnerable pattern, a workaround F5 and AlmaLinux both point to.
- Inventory every NGINX instance you run, including the ones buried in containers and behind load balancers, so nothing slips through.
- Check whether rewrite and set directives are in use, since that combination is what makes you exploitable.
- Watch your logs for malformed requests and unexplained worker restarts, both early signs someone is probing.
