nginx 1.31.3: A Heap Overflow in map, and Nearly Every Version Is Affected

F5 pushed an out-of-band security release on July 15 covering eight vulnerabilities across NGINX and BIG-IP. The one that matters most is CVE-2026-42533, a heap buffer overflow in the map directive reachable by unauthenticated crafted HTTP requests, and the affected version range is the part the headlines are burying: 0.9.6 through 1.31.2. That's essentially every nginx released since 2011.

If you run nginx, you are almost certainly running an affected version. Whether you're exploitable depends on your config, and there's a specific pattern to check for. Here's what broke, how to tell if it applies to you, and the mitigation F5 recommends if you can't upgrade today.

CVE-2026-42533: The map + regex Overflow

The bug lives in how map handles regex matching. Per F5's advisory, it triggers when a map directive uses regex matching and a string expression references the map's regex capture variables before referencing the map output variable. The same result can also be reached by using a non-cacheable variable in a string expression under certain conditions.

An unauthenticated attacker sends crafted HTTP requests, and the result is a heap buffer overflow (CWE-122) in the worker process, which restarts. ⚠️ On systems where ASLR is disabled, or where an attacker can bypass it, F5 states this becomes code execution. That's the difference between an annoying DoS and a compromised web server.

The scoring reflects the ambiguity: CVSS v3.1 rates it 8.1 (High), CVSS v4.0 rates it 9.2 (Critical). Exploitation requires conditions the attacker doesn't fully control, which is why it isn't a straight 10, but "conditions beyond their control" is not the same as "unreachable." This is a data-plane issue only, with no control-plane exposure.

Credit where due: nginx credits Mufeed VH of Winfunc Research and Maxim Dounin, with F5 also acknowledging over a dozen independent researchers for the disclosure.

Affected: nginx 0.9.6 through 1.31.2. Fixed: 1.31.3+.

The Other Two in This Release

CVE-2026-60005, uninitialized memory access in ngx_http_slice_module. Triggered when unnamed regex captures are used with the slice directive, or during background cache updates. Result is worker process memory disclosure or termination. ⚠️ Lower urgency for most: the slice module isn't compiled in by default and requires the --with-http_slice_module build flag, so check whether your build even includes it. Affected: 1.15.8 through 1.31.2.

CVE-2026-56434, use-after-free in ngx_http_ssi_filter_module, triggered by processing a specially crafted proxied backend response. Affected: 0.8.11 through 1.31.2. Reported by p4p3r. If you're not using SSI, this doesn't reach you, but check rather than assume, since SSI gets enabled in more configs than people remember.

Beyond nginx OSS, the release also covers two high-severity NGINX Ingress Controller flaws (authenticated attackers injecting arbitrary nginx config directives to delete files and disable services, or manipulating Ingress/TransportServer resources for DoS), and a BIG-IP flaw letting remote unauthenticated attackers drive memory utilization up via an HTTP/2 profile on a virtual server.

Check Whether You're Exposed

Version first:

nginx -v

Anything below 1.31.3 is in the affected range for CVE-2026-42533. ⚠️ Distro packages complicate this: Debian/Ubuntu repo nginx (1.18, 1.24, 1.26) carries backported fixes under its own version numbers, so nginx -v alone won't tell you if your distro patched it. Check the changelog:

zgrep -iE 'CVE-2026-42533|CVE-2026-60005|CVE-2026-56434' /usr/share/doc/nginx*/changelog.Debian.gz 2>/dev/null | head

⚠️ If you followed my guide on upgrading from the Ubuntu repo to nginx.org mainline 1.31.0, note that 1.31.0 sits squarely inside the vulnerable range. Running mainline means you get features early and you own the upgrade cadence, which is exactly the trade-off that matters here: mainline users need to move to 1.31.3 now, not wait for a distro backport that isn't coming.

Now check whether your config hits the vulnerable pattern. Look for map blocks using regex:

grep -rn 'map ' /etc/nginx/ | grep -E '~|~\*'

Then check which build modules you have compiled in:

nginx -V 2>&1 | tr ' ' '\n' | grep -E 'slice|ssi|http_v3'

If --with-http_slice_module is absent, CVE-2026-60005 doesn't apply to your build.

The Mitigation Nobody's Mentioning

Here's the practical detail most of the coverage skipped: F5's recommended mitigation for CVE-2026-42533 is switching from unnamed to named regex captures.

If you have a map using unnamed captures like this:

map $http_user_agent $device {
    ~(Android|iPhone)    mobile;
    default              desktop;
}

and then reference $1 in a string expression before $device, that's the dangerous shape. Named captures avoid the bug:

map $http_user_agent $device {
    ~(?<platform>Android|iPhone)    mobile;
    default                          desktop;
}

⚠️ Named captures are the mitigation, not a fix. Upgrade to 1.31.3 regardless. But if you have a change-controlled environment where an nginx upgrade needs a window and you're running a config with the vulnerable pattern on an internet-facing box, converting to named captures buys you time safely, and it's a config-only change you can test and reload without a package upgrade.

Test before you reload, always:

nginx -t

sudo systemctl reload nginx

What Else Landed in 1.31.3

Worth knowing since you'll be upgrading anyway. The release caps HTTP/2 response header and trailer sizes in ngx_http_proxy_v2_module and ngx_http_grpc_module via proxy_buffer_size, which is a direct hardening response to unbounded-allocation attacks. It also disables external XML entity loading by default in XSLT (an XXE-class hardening change made in response to industry pushback), and adds ten new TCP socket buffer directives for backend tuning.

⚠️ The HTTP/2 trailer cap is worth flagging on its own: unbounded memory allocation from header/trailer handling is exactly the resource-amplification pattern behind the HTTP/2 Bomb class of attack. Capping it by default is nginx closing that door structurally rather than waiting for each variant to get a CVE.

What To Do

1. Upgrade to nginx 1.31.3 if you run mainline from nginx.org.
2. If you're on distro packages, check the changelog for the CVE IDs rather than trusting the version string, and update when your distro ships the backport.
3. Audit your configs for map with regex, particularly any that reference capture variables in string expressions. That's the exposure.
4. If you can't upgrade immediately, convert unnamed captures to named ones in affected maps as an interim, config-only mitigation.
5. Verify ASLR is enabled on your web servers, since it's what stands between DoS and code execution here:

cat /proc/sys/kernel/randomize_va_space

Should be 2. If it's 0, that's a separate hardening problem you want to fix regardless of this CVE.

F5 reports no known in-the-wild exploitation. Treat that as a patch-promptly signal rather than a drop-everything one, but don't let it slide: nginx runs a huge share of internet-facing infrastructure, and a heap overflow with a code-execution path in a directive as common as map is exactly what opportunistic scanning finds first. This lands in the same pattern as the recent nginx CVE wave and NGINX Rift: long-lived bugs in well-trodden code, found once someone finally looked hard.

References

• SecurityWeek: F5 Patches Multiple NGINX, BIG-IP Vulnerabilities (source)
• nginx Security Advisories
• nginx CHANGES: 1.31.3
• F5 Security Notification K000161837
• nginx Documentation: ngx_http_map_module
• CVE-2026-42533 Details