CVE-2026-93479: NGINX map and regex heap overflow, a second one since July

What it is

A heap buffer overflow (CWE-122) in NGINX when a map directive uses regex matching and the root directive or an access log format uses the map’s regex capture variables before the map’s output variable. F5 says a non-cacheable variable in a string expression can have the same effect under certain conditions. A crafted HTTP request from an unauthenticated attacker overflows the heap in the worker process.

• Denial of service: the worker crashes and restarts.
• Code execution: possible where ASLR is disabled or the attacker can bypass it, according to F5.

F5 says this is a data plane issue only, with no control plane exposure. It scores it 9.2 in CVSS 4.0 (8.1 in CVSS 3.1), with high attack complexity. nginx.org rates it “medium”, titled “Buffer overflow in script evaluation”. F5 credits Matt Suiche (Tolmo, Inc.) and Mateusz Gierblinski.

CISA’s assessment in the CVE record rates exploitation as none. We found no public exploit code and no reports of attacks. This is the same kind of bug as CVE-2026-42533, fixed in July, and a relative of CVE-2026-42945 (NGINX Rift), which was attacked within days of its disclosure. Expect researchers to look at this one too.

Am I affected?

Yes, if both are true:

1. You run NGINX Open Source 1.30.0 to 1.30.5 or 1.31.2 to 1.31.6, or an affected NGINX Plus release (table above). Distribution packages may carry their own fixes, so check your vendor’s advisory too.
2. Your configuration has a map with regex patterns whose unnamed captures ($1, $2) are used by root or in an access log format before the map’s own variable.

Check your version:

nginx -v

Search every included file. nginx -T prints the full configuration.

Not affected: NGINX Open Source 1.30.6 and 1.31.7 or later, and NGINX Plus 37.1.0.1 and 37.0.5.1 or later. F5 lists NGINX Plus R33 to R36 as affected with no fix listed. We did not find the NGINX Open Source versions before 1.30.0 or 1.31.2 in the affected list.

What to do

1. Upgrade. NGINX Open Source to 1.30.6 (stable) or 1.31.7 (mainline) or later. NGINX Plus to 37.1.0.1 or 37.0.5.1. Move R33 to R36 to a fixed release. Remember the NGINX inside appliances, containers and ingress controllers.
2. If you can’t upgrade yet, use named captures. F5’s workaround is to avoid unnamed captures, use named captures, and limit them to the block that contains the regex match. Reload NGINX after changing the configuration.
3. Make sure ASLR is enabled on hosts running NGINX. It does not stop the crash, but it is what stands between this bug and code execution.
4. If a vulnerable server was internet-facing and shows the signs below, treat it as possibly compromised: rebuild it and rotate its TLS keys and stored credentials.

Detection

No indicators of compromise have been published.

• Worker crashes in the NGINX error log. Look for workers exiting on a signal, such as segmentation faults, and for a sudden rise in worker restarts.
• Requests that line up with the crashes, aimed at locations that use the affected map variables.
• After a crash, unexpected child processes of NGINX workers or new outbound connections from the server, which would point to code execution.