Critical NGINX Flaw Lets Attackers Crash Web Servers From Afar
F5 has patched CVE-2026-42533, a memory bug in nginx that a remote attacker can trigger with a single crafted request.
Key points
- F5 patched a critical flaw in nginx, tracked as CVE-2026-42533, on July 15.
- The bug lets a remote attacker crash the web server with a specially crafted HTTP request, no login needed.
- Fixes are in nginx 1.30.4 (stable), 1.31.3 (mainline), and NGINX Plus 37.0.3.1.
- Anyone running an older build should upgrade now.
- The vendor rates the flaw critical; public exploitation has not been confirmed at time of writing.
F5 has released fixes for a serious flaw in nginx, one of the most widely used web server programs on the internet. The bug lets an attacker send a crafted web request from anywhere and knock the server over, no credentials required. We first covered this CVE on 16 July, the day after the patch shipped, as part of a broader F5 advisory covering nginx and BIG-IP.
The flaw is CVE-2026-42533, sitting in the part of nginx that handles incoming HTTP requests, the everyday messages your browser sends when it asks a site for a page.
What does this actually let attackers do?
They can crash the server on demand. It's a heap buffer overflow: the program writes more data into a chunk of memory than that chunk was built to hold, and the worker process, the part of nginx that answers requests, falls over or restarts.
A site behind an unpatched nginx can be pushed into a denial of service, where visitors get errors or timeouts instead of pages. F5 says the flaw could in theory also allow remote code execution, meaning an attacker running their own commands on the server. That upper-end scenario is harder to pull off, and no working exploit has been made public.
The first reporting on the patch came from The Hacker News.
Who needs to patch?
Anyone running nginx on the open internet. The fixed versions are nginx 1.30.4 (stable branch), 1.31.3 (mainline branch), and NGINX Plus 37.0.3.1, the commercial build. F5 shipped those on July 15. There's no configuration workaround from the vendor, so upgrading is the only fix.
For most organisations this isn't a fire drill on the scale of a Log4j, but it's a serious one. Nginx runs on a very large slice of the world's web servers, from small blogs to major streaming platforms and corporate front doors. A remotely triggerable crash reachable with a single request is exactly what denial-of-service crews look for. This is also the second nginx crash-from-a-distance story we've run in a week: the OpenSSL HollowByte flaw reported on 17 July shows how much attention this class of bug is getting right now.
Should you worry?
If you're an ordinary user, nothing changes on your device. This is a server-side flaw, not something that touches your phone or laptop. If a site you use goes briefly offline in coming weeks, that could be unrelated maintenance or an admin patching in a hurry. No password changes or software installs needed.
If you run a website, check with your hosting provider that they've moved to a patched build. Managed hosts usually handle this quietly. Self-managed servers don't.
No named group is tied to this bug yet, and no in-the-wild exploitation has been reported. That can change quickly once proof-of-concept code surfaces. Given how attractive nginx is as a target, assume scanning for unpatched instances will accelerate within days of any public write-up.
