Skip to main content
Published on August 12, 2026
CVE-2026-42533 — buffer overflow when using map and regex. Affects nginx 0.9.6 through 1.31.2. Fixed in 1.30.4 (stable) and 1.31.3 (mainline). If you patched in May for Nginx Rift, that fix does not cover this one.

​
The part most people got wrong

Two heap overflows landed in nginx’s script engine within a few months, and they look similar enough that they get confused. They are not the same bug, and — this is the part that matters — the version that fixed one still runs the other. Read the last two rows together. Rift was fixed in 1.30.1. CVE-2026-42533 affects everything up to 1.31.2. A server updated to 1.30.1 in May, ticked off as “patched”, is squarely in range. If your last nginx update was prompted by the Rift coverage, you are not done.

​
The flaw

Both bugs come from the same design. nginx evaluates script expressions in two passes: the first measures how much buffer it needs, the second writes into it. When the state the engine relies on changes between the two passes, the write outruns the size that was measured, and the overflow lands on the heap. Rift got there through a stale flag. This one gets there through PCRE capture state: there is no save-and-restore around it, so captures from one evaluation clobber another. Triggering it needs a specific shape of configuration — a regex-based map block, and a directive that references both a regex capture and the map’s output variable in the same expression. That is not exotic. It is a normal way to write a routing rule.
Note the severity gap. nginx rates this major and rates Rift medium, while several third-party trackers scored Rift at CVSS 9.2. Vendor and third-party scores are measuring different things; the version ranges above are the part to act on, not the number.

​
Sizing your exposure

That fourth row deserves emphasis. A pinned nginx:1.30.1 in a Dockerfile does not update itself, and rebuilding is the only way it changes. The public full-chain proof of concept was tuned specifically for Docker deployments — base image, package snapshot and source revision.

​
Checking and updating

Find out what you are actually running, which is not always what your package manager thinks:
Debian, Ubuntu and derivatives:
AlmaLinux, Rocky Linux and RHEL:
A reload is not enough here. nginx -s reload starts new workers but the master process keeps running the old binary. Use restart so the whole process tree picks up the patched code, then confirm with nginx -v.
For containers, rebuild rather than patch in place:

​
If you cannot update immediately

There is no configuration flag that disables the bug. What you can do is remove the trigger: if a map block built on a regex feeds a variable that is used alongside a regex capture in the same directive, rewriting that expression closes the path until you patch. Find the candidates:
Treat this as a stopgap measured in days, not a fix.

​
The wider lesson

Two bugs of the same class, in the same engine, months apart, with overlapping-but-different version ranges. The failure mode is not “we did not patch” — it is “we patched, and assumed that settled it”. When an advisory names a version, the useful question is not did we update? but did we update past the range in this advisory? They are different questions, and only the second one has an answer you can check. Our guide to auditing and hardening nginx on a VPS covers the routine that catches this class of thing before an advisory forces it. Questions about a server hosted with us? Our team is available from your client area.