A 15-Year-Old NGINX Bug Just Became a Critical Code-Execution Risk

F5 has patched a critical flaw in NGINX, the web server and reverse proxy software that quietly sits in front of a huge share of the internet — and the bug itself is older than most of the sites it protects. Tracked as CVE-2026-42533, it's been sitting unnoticed in NGINX's code since 2011, when the map directive first gained support for regular-expression captures. More than a dozen researchers independently found and reported it before F5 shipped a fix on 15 July.

The root cause is a timing mistake inside NGINX's own script engine. NGINX processes certain configuration expressions in two passes: the first pass measures how much buffer space a value will need, the second pass writes the value into that buffer. If a regex-based map is evaluated between those two passes, in a configuration where its output is used later in a string expression that has an earlier regex capture, it silently overwrites the capture data the first pass relied on. The buffer ends up sized for one value but filled with a different, attacker-controlled one — a classic heap buffer overflow, triggered with nothing more than a crafted HTTP request and no login of any kind.

At minimum, that overflow can crash or restart NGINX worker processes on demand — a straightforward denial-of-service. F5's advisory notes remote code execution is possible where address-space layout randomisation (ASLR) is disabled or can be bypassed; independent researcher Stan Shaw has gone further, arguing the bug leaks enough heap-pointer information to defeat ASLR on its own, and says he got it working against a stock Ubuntu 24.04 box without any extra help. No public exploit code or confirmed real-world attack has surfaced yet, but Shaw has said he intends to publish a proof of concept roughly three weeks after the patch — which puts a rough, self-imposed deadline on how long "patch when convenient" stays a safe posture.

What this means for your business

• Find out if you're behind NGINX at all. It's not just a "we run our own servers" question — a great many managed hosts, CDNs, and reverse-proxy layers use NGINX under the hood even when a client-facing site looks like it's built on something else entirely. Ask your host or developer directly.
• Confirm the version is patched. Fixed releases are NGINX open source 1.30.4 (stable) and 1.31.3 (mainline), and NGINX Plus R36 P7 / 37.0.3.1. Every version back to 0.9.6 is affected if unpatched.
• The exposure isn't universal, but don't assume you're safe. The overflow needs a specific configuration pattern — a regex map feeding into a later string expression with its own regex capture — which not every site uses. If your team can't quickly confirm whether your configuration matches, treat the patch as mandatory rather than spending time investigating the nuance.
• Get this done before early August. With a public proof of concept expected roughly three weeks after the 15 July patch, this has a real window before it likely gets much easier for an attacker to weaponise.

NGINX is infrastructure most business owners never think about, which is exactly why it's worth a direct question to whoever manages your hosting this week: are we patched, and can you show me the version number?