CVE-2026-42533: the NGINX map heap overflow

02How does the map overflow happen?

nginx builds string values such as log lines, document roots and proxied headers using a two-pass script engine. The length pass totals the bytes needed and allocates exactly that; the copy pass writes the data. Both passes read the request's regex capture state, which is shared and mutable.

The bug appears when a single string expression references a positional capture such as $1 and then evaluates a regex-backed map. During the length pass, $1 may be empty, so it reserves little or no space. Evaluating the map then runs its own regex over attacker-controlled input and overwrites the shared capture array with a new, larger value. The copy pass revisits $1, now finds the new long capture, and copies it into the buffer that was sized for the old short one. The surplus overflows the allocation.

A second route reaches the same sink: a non-cacheable map marked volatile that depends on its own capture. Because its value can change between the length and copy passes, the two passes again disagree on size. Winfunc's write-up confirmed the overflow on a stream listener using ssl_preread, where the attacker-controlled TLS SNI hostname was copied into a one-byte allocation.

03Who is affected?

Open source nginx 0.9.6 through 1.31.2 is listed as vulnerable, along with NGINX Plus releases built on those versions. Exposure requires the specific configuration shape, so a version match alone does not mean you are exploitable.

The vulnerable shapes come straight from the upstream fix commit. The first is a string expression that reads a capture before a regex map; the second is a self-dependent volatile map.

# A: capture read before the regex map output
map $uri $m {
    ~(?<capture>.*)  $capture;
}
set $capture "";
set $temp "$capture $m";   # $capture measured, then $m clobbers it

# B: self-dependent volatile map
map prefix:$capture $m_volatile {
    volatile;
    ~(?<capture>.*)  $capture;
}
set $capture "";
set $temp "$m_volatile";

04How do I audit my configuration?

Dump the merged configuration and look for two things: regex maps with captures, and volatile maps. Then confirm, by reading the surrounding blocks, whether a captured variable is used outside its own map block or before the map output in the same expression.

nginx -T 2>/dev/null > /tmp/nginx-full.conf

# map blocks and regex entries that define a named capture
grep -nE '^\s*map\s|^\s*~\*?\S*\(' /tmp/nginx-full.conf

# volatile maps (the self-dependent variant)
grep -nE '^\s*volatile\s*;' /tmp/nginx-full.conf

# for each captured name, see where it is used outside its map
for c in $(grep -E '^\s*~' /tmp/nginx-full.conf \
           | grep -oE '\?<[A-Za-z_][A-Za-z0-9_]*>' | tr -d '?<>' | sort -u); do
  echo "== \$$c"; grep -nE "\\$\{?$c\b" /tmp/nginx-full.conf
done

05How is it fixed?

Upgrade to nginx 1.31.3 (mainline) or 1.30.4 (stable); NGINX Plus users should move to R36 P7 or PLS.37.0.3.1 (LTS), both released on 15 July 2026. The fix records the end of the allocated buffer and routes every literal, variable and capture copy through a shared length guard. If a copy would exceed the buffer, nginx now logs "no buffer space in script copy", aborts the script and returns an internal error instead of writing out of bounds — it fails closed.

Distribution packages carry it too: Debian shipped it in nginx 1.26.3-3+deb13u8 for trixie (DSA-6496-1) and in 1.22.1-9+deb12u10 for bookworm through Debian LTS (DLA-4784-1). Match the package version your distribution publishes.

If you cannot upgrade at once, remove the trigger. Do not use unnamed captures in these expressions; use a uniquely named capture and reference it only inside the same block as the regex match. Reorder expressions so a map output is not preceded by a capture reference it depends on.

• Primary fix: upgrade to nginx 1.31.3 / 1.30.4, or the matching distro package
• Config mitigation: name captures and use them only inside their own map block
• Avoid self-referential volatile maps built from their own capture
• Restart nginx so workers reload the patched binary

06The companion bug: CVE-2026-60005 in the slice module

The same July release fixed CVE-2026-60005, an uninitialised-memory access in the slice module. It occurs when the slice directive is used with unnamed regex captures, or during a background cache update, and leads to limited memory disclosure or a worker restart. Unlike the map bug it is a read-side problem rather than a write, and F5 scores it 8.2 under CVSS 3.1.

The slice module is not compiled in by default; it needs the --with-http_slice_module build option, which is why the exposure is narrower. If you use byte-range slicing in front of a cache, patch to 1.31.3 / 1.30.4, avoid unnamed captures with slice, and disable proxy_cache_background_update if you do not need it.

07What can an edge proxy actually do here?

The honest answer mirrors the rewrite bug. CVE-2026-42533 executes inside the nginx worker that processes the request, so a filter inside that same vulnerable nginx cannot be relied on to stop it. The stream variant is worse for edge filtering, because it is driven by the TLS SNI during the handshake — before any HTTP-layer inspection runs. Understanding where TLS sits helps here: see what SSL/TLS is.

A separate, patched tier in front of an origin reduces exposure and absorbs the crash-loop denial of service, in the same way any reverse proxy shields an origin. It cannot make an unpatched nginx safe, which is the general limit of any virtual patch. Patch first; use edge protection to limit blast radius and to soak up flooding. For what that layer does more broadly, see what a WAF is.