nginx patches heap overflow in worker (CVE-2026-42533)

F5 shipped nginx 1.30.4 (stable) and 1.31.3 (mainline) on July 15 to fix CVE-2026-42533, a heap buffer overflow in the worker process. NGINX Plus 37.0.3.1 carries the same fix. NVD scores it 8.1 (high); The Hacker News called it critical, and the delta between those two labels is worth understanding before you patch.

The bug lives in the interaction between the map directive and the ordering of variables inside a string expression — specifically, when the expression references the map’s regex capture variables before referencing the map output variable. A comparable outcome is reachable, per the NVD write-up, when a non-cacheable variable is used in a string expression under certain conditions. Given that shape of configuration, a crafted request against the exposed listener can overflow a heap buffer in the worker, forcing a restart, and — on systems where address-space layout randomization is disabled or can be bypassed — allow code execution. Control plane is untouched. This is a data-plane bug only.

That configuration shape is why the score sits at 8.1 rather than 9.8. Unauthenticated remote reach, yes. Trust boundary crossed, yes. But the attacker doesn’t pick the target; the target’s own config has to have already assembled the vulnerable pattern. Plenty of real deployments do — regex-driven map blocks are a common way to route by host or path in reverse-proxy setups — and CVSS’s calculator penalizes the “attack complexity” a step for it. Practically, that means you should still be treating this as a same-week patch, not a “critical, drop everything” one.

The wider reading is duller and older. nginx is not a fresh codebase. It sits in front of a large fraction of the busiest sites on the internet, has been audited by every party with a reason to audit it, and has been the object of a decade of continuous fuzzing campaigns. A heap overflow reachable through crafted HTTP in 2026 is not shocking; it’s a reminder that the underlying language is still C, the memory model is still manual, and every regex-heavy configuration surface remains a place where a subtle sequencing bug can turn into an out-of-bounds write. The same mistake, different decade.

If you can’t upgrade tonight, audit your map blocks: any string expression that touches a regex capture variable before the map’s output variable is the pattern to worry about, along with any use of non-cacheable variables inside those expressions. Restructuring the config to drop that ordering — or dropping the specific map block entirely if the routing logic can move elsewhere — closes the window until the patched build lands. End-of-technical-support branches are not covered by the advisory, so if you’re still running one of those in front of production, this CVE is the second reason today to move.