CVE-2026-42533: NGINX Memory Corruption via Map Directive Regex (CVSS 8.1)

Overview

A high-severity memory corruption vulnerability has been disclosed in NGINX Plus and NGINX Open Source, tracked as CVE-2026-42533 with a CVSS score of 8.1 (High). The issue is triggered when a map directive uses regex matching, and a string expression references the map's regex capture variables ($1, $2, etc.) before referencing the map output variable itself.

The same condition can also be triggered using a non-cacheable variable in a map's string expression. Under these specific configurations, NGINX enters an undefined memory state that can lead to worker process crashes or, under certain conditions, exploitation for arbitrary code execution.

Technical Details

The map directive in NGINX evaluates lazily — values are computed on demand during request processing. When a regex capture group variable is accessed in a dependent expression before the map's output variable is evaluated, the internal state machine can reference uninitialized or freed memory.

Vulnerable Configuration Example

map $uri $mapped {
    ~^/user/(?P<uid>[0-9]+)/(.*)$ "${uid}_${2}_result";
}
 
server {
    location / {
        # Referencing $uid (capture var) before $mapped triggers the bug
        add_header X-User-Info "${uid}";
        add_header X-Mapped "${mapped}";
    }
}

In the above example, $uid is derived from a regex capture inside the map block. Accessing it before $mapped forces evaluation of the capture variable outside the expected lifecycle, corrupting the memory region used by the map module.

Non-Cacheable Variable Variant

The vulnerability also manifests when a non-cacheable variable (e.g., $request_id, $time_local) appears in a map string expression:

map $request_uri $cache_key {
    ~^/api/(.*)$ "$1_${request_id}";
    default       "${request_id}_default";
}

Variables like $request_id are regenerated per-request and bypass NGINX's internal variable caching. Their inclusion in a map expression alongside regex captures creates the same unsafe evaluation order.

Impact

Successful exploitation can result in:

• NGINX worker process crash (denial of service) — the most likely outcome in typical deployments
• Memory disclosure — sensitive data from adjacent memory regions exposed in responses
• Potential code execution — in configurations where an attacker controls the map input (e.g., from a proxied Host header or URI)

Organizations running NGINX Plus as a high-availability load balancer or API gateway are at elevated risk from the DoS impact, as worker crashes disrupt active connections.

Affected Versions

F5 has not yet published the full version range at time of writing. Consult the official advisory for version-specific patch availability.

Remediation

Update NGINX

Apply the latest NGINX Plus release from the F5 customer portal, or update NGINX Open Source:

# Debian/Ubuntu
apt-get update && apt-get upgrade nginx
 
# RHEL/CentOS/Rocky
dnf update nginx
 
# Verify version
nginx -v

Configuration Workaround

Until patching is possible, restructure map directives to avoid referencing regex capture variables in dependent string expressions before the map output:

# Safe: reference $mapped before using capture variables
map $uri $mapped_prefix {
    ~^/user/([0-9]+)/(.*)$ "$1";
    default "unknown";
}
 
# Use $mapped_prefix in a separate map if needed
map $mapped_prefix $full_result {
    default "${mapped_prefix}_result";
}

Avoid embedding non-cacheable variables ($request_id, $time_local, $msec) inside map string expressions.

Detection

Search your NGINX configuration for potentially affected map blocks:

grep -rn "map " /etc/nginx/ | grep -E '\$[0-9]+|\$request_id|\$time_local|\$msec'

Monitor NGINX error logs for worker process crash signatures:

grep -i "worker process.*exited\|segfault\|signal 11" /var/log/nginx/error.log

CVSS Vector

CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:H/I:H/A:H

References

• NVD Entry: CVE-2026-42533
• NGINX Security Advisories
• F5 Security Advisory Portal
• NGINX map Module Documentation