On July 15, F5 patched a critical vulnerability in Nginx, the web server behind a large share of the internet, that had been sitting in the code since 2011. It is rated 9.2 on the newer CVSS v4 scale, it needs no authentication, and a crafted HTTP request can crash a worker process or, in the wrong conditions, run code. That sounds like every Nginx server on the planet is a target. It is not, and the gap between those two things is the whole story.
What the Bug Is
CVE-2026-42533 is a heap buffer overflow in Nginx’s script engine, the part that evaluates string expressions and variables. It is reached through the map directive, a common tool for turning one value into another, but only in a specific pattern: a regex-based map whose output variable is referenced in a string expression after a capture from an earlier regex match. Under that arrangement, shared capture state can be overwritten between two evaluation passes, the buffer sizing goes wrong, and the worker process overflows its heap. F5 describes the result as a remote, unauthenticated attacker triggering the overflow with crafted HTTP requests. The realistic impact is a crash or restart of the worker, which is a denial of service. Remote code execution is on the table only where address space layout randomization is disabled or can be bypassed, so treat RCE as the worse case rather than the default. F5 scores it 9.2 on CVSS v4 and 8.1 on the older v3.1 scale, and notes the attack complexity is high.
Who Is Actually Exposed
This is where the panic and the reality diverge. Every Nginx release from 0.9.6 to 1.31.2 contains the vulnerable code, a range that reaches back to 2011, when the map directive first gained regex support. But containing the code is not the same as being exploitable. The flaw only surfaces if your configuration uses that particular regex-map-then-string-expression pattern. Plenty of Nginx installs never touch it. Plenty do, because regex maps are a normal way to handle routing, rewrites, and header logic, and a config copied from a tutorial years ago may use the pattern without anyone remembering. The honest summary: the severity is real and the trigger is narrow, so the first job is not to panic but to check whether your configuration sits in the blast radius.
The Patch, and the Clock
The fixes shipped on July 15: Nginx 1.30.4 on the stable branch, 1.31.3 on mainline, and NGINX Plus 37.0.3.1 and R36 P7. If you run an older NGINX Plus, R33 and earlier have no fix, which means a version upgrade rather than a patch. As of now there is no known public exploit. That is the part with an expiry date: a security researcher, Stan Shaw, has said he will publish proof-of-concept code 21 days after the patch, which puts a working exploit in the open in early August. The vulnerability was reported independently by more than a dozen researchers and credited to Mufeed VH of Winfunc Research and Nginx maintainer Maxim Dounin, so the details are well understood and the window to patch quietly is short.
What to Do
Two steps. First, update Nginx to a fixed version, or NGINX Plus to 37.0.3.1 or R36 P7. That closes the issue regardless of your configuration and is the only complete fix. Second, if you cannot update immediately, look at your config: search for map blocks that use regular expressions and feed a capture into a later string expression, and consider whether you can remove or restructure that pattern until you patch. A web application firewall may catch some of the crafted requests, but that is mitigation, not a fix, and against a heap overflow it is not something to lean on. With a public exploit expected in early August, the sensible order is to patch first and audit the config second, not the other way around.
