NGINX Has a Critical Heap Overflow That Can Become RCE

• The Mess: CVE-2026-42533 is a heap-based buffer overflow in NGINX triggered by a specific combination of the map directive, regex captures and string evaluation. An unauthenticated attacker can send crafted HTTP requests that crash the NGINX worker — and under certain conditions potentially achieve remote code execution.

This isn’t some obscure management interface.

It’s the HTTP worker.

The vulnerable configuration involves a map directive using regex matching where capture variables are referenced in a particular order inside a string expression. A similar condition can occur with certain non-cacheable variables.

The result is a heap buffer overflow.

NGINX allocates memory based on one value.

The data subsequently written can be different.

That’s where things get ugly.

At minimum, a malicious request can crash the worker process and trigger a restart. With ASLR disabled — or if an attacker can bypass ASLR — the same vulnerability can potentially be turned into code execution.

And there is a public PoC.

That matters.

A researcher published an exploit repository on July 27, demonstrating the overflow and crash and describing an RCE chain. The repository claims reliable exploitation on Ubuntu 24.04, although those researcher claims should not be treated as equivalent to a confirmed universal weaponized exploit.

• The Damage: A remote attacker who can reach a vulnerable NGINX server may be able to crash worker processes and, under favorable conditions, execute arbitrary code with the privileges of the NGINX process.

That’s potentially ugly on reverse proxies and internet-facing servers.

NGINX often sits directly on the public edge.

Millions of requests arrive there.

An attacker doesn’t need an account if the vulnerable configuration is reachable through the HTTP data plane. (NVD)

There is an important catch.

Not every NGINX installation is exploitable.

The vulnerable map/regex configuration has to actually exist and be reachable in the right way. An old NGINX version alone does not prove that an attacker can trigger the bug.

That’s why configuration auditing matters.

Still, the affected version range is enormous. NGINX lists 0.9.6 through 1.31.2 as vulnerable, with fixed versions 1.30.4+ and 1.31.3+. NGINX Plus is fixed in R36 P7 and 37.0.3.1.

Yes.

That includes versions that have been around for years.

• The Fix: Upgrade NGINX Open Source to 1.30.4 or 1.31.3 and later, or upgrade NGINX Plus to R36 P7 / 37.0.3.1 or later; also audit map directives using regex captures.

If you cannot patch immediately, review configurations containing regex-based map blocks and capture variables.

Also verify that ASLR is enabled.

That does not fix the vulnerability.

It can, however, make turning the memory corruption into reliable code execution considerably harder.

And don’t forget distro packages.

Ubuntu, Red Hat and other distributions may backport the NGINX security fix while retaining their own package versioning. Check the vendor advisory rather than comparing only the upstream NGINX version number. Ubuntu, for example, issued USN-8563-1 for CVE-2026-42533.

Bugstoday Opinion

This one deserves attention.

NGINX is the front door.

If the front door has a heap overflow reachable through HTTP, nobody should be excited about leaving it unpatched.

The interesting part isn’t just the CVSS score.

It’s the combination:

unauthenticated + network reachable + heap corruption + public PoC.

That’s a nasty cocktail.

And yes, exploitation requires specific configuration conditions. Good.

But internet-facing servers have a funny habit of accumulating configuration nobody remembers writing.

Bugstoday verdict: check your map directives, check your NGINX version, and patch. A reverse proxy that can be crashed remotely is annoying. A reverse proxy that can potentially become an RCE entry point is something else entirely.