Nginx patches a critical heap overflow dating back to 2011: CVE-2026-42533 and the exploit countdown

Fifteen years in the code

Some patches close a bug from the latest release, and some close a bug that's been sitting there for fifteen years. This one is the second kind: the buffer overflow tracked as CVE-2026-42533 is present in every Nginx version since 0.9.6, released in 2011. In other words: if you run Nginx in production, it barely matters when you installed it — it was affected.

On July 15th F5 published the versions that fix it: 1.30.4 (stable), 1.31.3 (mainline) and NGINX Plus 37.0.3.1. And it doesn't travel alone: the same batch closes two more vulnerabilities worth knowing about.

In one sentence

A crafted HTTP request can trigger a heap buffer overflow in the Nginx worker process. In the attacker's second-best scenario it crashes the worker and causes denial of service; in their best one — on systems without ASLR, or where it can be bypassed — it may escalate to remote code execution. CVSS 9.2 on the v4 scale (8.1 on v3.1, reflecting the high attack complexity).

What we know about the flaw

The overflow happens in Nginx's expression-evaluation engine when processing specially constructed HTTP requests. The fine details are deliberately unpublished: the researcher who reported it, Stan Shaw, has announced he will release his proof of concept 21 days after the patch — that is, in early August.

That "you get three weeks" model is increasingly common, and you should read it for what it is: a countdown. Today there's no public exploit and no evidence of active exploitation (it's not in CISA's KEV catalog as of this article). But the day the PoC drops, automated scanners take hours to pick it up, not weeks. The comfortable window to update is now, not August.

What ships in the same batch

Versions 1.30.4 and 1.31.3 also fix:

• CVE-2026-60005 — memory disclosure in ngx_http_slice_module. If you use the slice module (typical in caching setups for video or large chunked files), a crafted response can leak worker memory contents.
• A use-after-free in ngx_http_ssi_module, the Server Side Includes module. Fewer people use it these days, but if some inherited config still has ssi on;, this one's for you too.

Three flaws, one package. All the more reason not to let it slide.

Who's affected

• Affected versions: 0.9.6 through 1.31.2. In practice, every Nginx without the July 15th patch.
• Highest exposure: any internet-facing Nginx — which is exactly where Nginx tends to live. The attack complexity is high, but the attack surface is universal.
• NGINX Plus: equally affected; the fix is in 37.0.3.1.

If you applied May's batch of seven CVEs and figured you were up to date: you were. Until now. That's how this works.

What you need to do today

The usual routine — no drama, and no leaving it for later.

1. Check what version you're running

nginx -v

• Stable branch: the target is 1.30.4 or higher.
• Mainline branch: the target is 1.31.3 or higher.

2. Update and reload (zero downtime)

# Debian / Ubuntu
sudo apt update && sudo apt install --only-upgrade nginx
sudo nginx -t && sudo systemctl reload nginx

# RHEL / AlmaLinux / Rocky
sudo dnf update nginx
sudo nginx -t && sudo systemctl reload nginx

The nginx -t before the reload validates your configuration and spares you the scare of a service down over a typo. The reload swaps in the new binary without dropping in-flight connections.

Remember the distro-repository caveat: they sometimes backport the fix while keeping the old version number. If your nginx -v doesn't reach 1.30.4 but the package was built after July 15th, check your distro's security changelog before panicking — and the other way round: don't assume you're covered just because you ran apt upgrade last week.

3. If you use slice or SSI

Take the chance to confirm it:

nginx -T 2>/dev/null | grep -E "slice|ssi on"

If anything shows up, those two secondary flaws applied to you as well — and the patch closes them in one go.

What we did

On the 15th itself we updated the internet-facing Nginx instances we manage, starting with the exposed reverse proxies. Without waiting for the PoC, without waiting for it to show up in CISA's KEV: when a flaw has spent fifteen years in the code, affects every version and has an announced public-exploit date, the cost/benefit math on updating is already done.

And after the reload, the gesture that separates "I think it's done" from "it's done": running nginx -v again and checking. Memory verifies nothing.

If your Nginx hasn't seen a patch in months — or you don't even know what version it runs — let's talk.

References

• nginx security advisories — nginx.org
• Critical NGINX Vulnerability Can Crash Workers and May Allow Remote Code Execution — The Hacker News
• NGINX vulnerability CVE-2026-42533 — F5 (K000161019)
• Releases — NGINX Documentation