CVE-2026-93479

NGINX map directive and regex matching vulnerability

No known exploitation. EPSS puts it in the 45th percentile. Fixed versions are out.

CVSS 3.18.1High EPSS percentile45th0.6% chance in 30 days CISA KEVNot listedNo confirmed exploitation
No public exploit known Fix2 products4 fixed builds listed below

Published 2026-10-14Updated 2026-10-15Sources: CVE.org, NVD

NVD CVE.org

What to do

Find your product and version, then upgrade to the build on the right.

F5 NGINX PlusAffected: ≥ 37.1.0, < 37.1.0.1Upgrade to: 37.1.0.1Affected: ≥ 37.0.0, < 37.0.5.1Upgrade to: 37.0.5.1Affected: R36Upgrade to: not statedAffected: R35Upgrade to: not stated + 2 more branchesStated by: CVE record
F5 NGINX Open SourceAffected: ≥ 1.31.2, < 1.31.7Upgrade to: 1.31.7Affected: ≥ 1.30.0, < 1.30.6Upgrade to: 1.30.6Stated by: CVE record

Versions as the sources state them. Full version matrix after sign-in

Steps

Written by AI from the record

Check your NGINX config for map directives that use regex matching, and see if root or your access log format references the map's regex capture variables before the map's own output variable.
If you're not sure, ask whoever manages your server/hosting to check this for you.
Upgrade to the fixed version: nginx 1.31.7 or 1.30.6 (open source), or 1.31.0.1/37.0.5.1 and later for NGINX Plus.
If you can't upgrade right away, change any unnamed regex captures in map directives to named captures and only use them within the same block as the regex match — this removes the risk without upgrading.
After upgrading, restart NGINX and confirm the server is running your new version.

Usually a quick update

Check it yourselfA free OpenVAS check exists for this CVE. Run it against your hosts.Is your organisation exposed?Request an assessment to establish which checks fit your systems.

Coverage timeline

3 publishers

Vendor patch released
as reported · Oct 19, 2026·BleepingComputer summary

Sourced from public security reporting — each date is when it was published, not when it happened. 1 further article named this CVE in wider roundups without reporting it as a distinct event.

What it is

From the CVE record

A vulnerability exists in NGINX Plus and NGINX Open Source when a map directive uses regex matching and the root directive or access log format references the map's regex capture variables before referencing the map output variable. Alternatively, the same result could be achieved by using a non-cacheable variable in a string expression under certain conditions. An unauthenticated attacker along with conditions beyond their control can exploit this vulnerability by sending crafted HTTP requests. This may cause a heap buffer overflow in the NGINX worker process leading to a restart. Additionally, attackers can execute code on systems with Address Space Layout Randomization (ASLR) disabled or when the attacker can bypass ASLR. Impact: This vulnerability may allow remote attackers to cause a denial-of-service (DoS) on the NGINX system or to possibly trigger a code execution. There is no control plane exposure; this is a data plane issue only. Note: Software versions which have reached End of Technical Support (EoTS) are not evaluated.

In plain language

Written by AI from the record

A specific NGINX configuration pattern involving the 'map' directive with regex can let an attacker crash your web server or, in rare cases, run their own code on it — if your site uses that pattern, you should fix it now.

Heap buffer overflow (CWE-122) in NGINX/NGINX Plus triggered when a map directive uses regex matching and a root or access_log directive references the map's regex capture variables before the map output variable (or a non-cacheable variable is used in a string expression), allowing an unauthenticated remote attacker to crash the worker process or, with ASLR absent/bypassed, achieve code execution.

If you're affected

Website outage / crashes
Full server compromise (rare conditions)
Customer-facing downtime
Operational disruption

What is it

Think of NGINX as the front door and traffic director for your website. This flaw is a specific wiring mistake in how that director reads certain traffic-routing instructions (called 'map' directives) — if wired a certain way, a visitor can send a deliberately malformed request that jams the director, shutting your site down, or in rare cases lets them take over the machine entirely.

Who is affected

This matters to you if your website or application runs on NGINX or NGINX Plus. It only applies if your configuration uses a 'map' directive with regex matching combined with certain root or access-log patterns, or a specific non-cacheable variable usage — not every NGINX setup is wired this way, so check your config first.

How urgent is it

This is rated red because an unauthenticated attacker can trigger it over the network with no login and no user interaction, and it's drawing sustained press attention; while no confirmed real-world attacks or public exploit code exist yet, the combination of easy remote reach and potential code execution means affected configurations should be fixed without delay rather than waiting for proof of active abuse.

What to do — in detail

Audit nginx.conf (and included config files) for map blocks using regex matching; check whether root or the access_log log_format directive references the map's regex capture variables ($1, $2, etc.) before referencing the map's output variable — this is the primary trigger condition. Also check for non-cacheable variables used inside string expressions.
Upgrade: for NGINX open source, go to 1.31.7 (mainline) or 1.30.6 (stable); for NGINX Plus, go to release 37.1.0.1 or 37.0.5.1 or later (confirm your branch with your NGINX Plus subscription support). No breaking changes are reported for these patch releases.
If immediate upgrade isn't possible, apply the workaround: replace unnamed regex captures in map directives with named captures, and restrict their use to within the same block as the regex match — this neutralizes the exploit path without requiring a binary upgrade.
Not in CISA KEV and no public exploit code or confirmed in-the-wild exploitation exists as of now, so there is no mandated remediation deadline — but given the CVSS 8.1 score and no-auth/no-interaction reachability, treat this as a priority patch cycle item.
Monitor for unexpected NGINX worker process restarts/crashes in your logs after deployment, and watch vendor/NGINX advisories and threat intel sources for any shift to confirmed exploitation.

Technical context

CVSS 3.1 score 8.1 (AV:N/AC:H/PR:N/UI:N/S:U/C:H/I:H/A:H) — network-exploitable, no privileges or user interaction required, high attack complexity due to specific configuration preconditions, with high impact to confidentiality, integrity and availability. Weakness: CWE-122 (heap buffer overflow) in NGINX's map/regex capture-variable handling and non-cacheable variable evaluation, data-plane only (no control-plane exposure). Not listed in CISA KEV; no dated news reporting confirms active exploitation; no public exploit code exists. Predicted exploitation likelihood is low with a flat trend. Exploit maturity is theoretical/PoC-absent; successful code execution additionally requires ASLR to be disabled or bypassed, otherwise the likely outcome is a worker-process crash/DoS.

This is a general assessment based on public vulnerability data. It does not account for your specific infrastructure — when in doubt, consult a security specialist.

Exploitation

Where each signal puts this CVE on the scale from published to confirmed exploited.

EPSS45th

CISA KEV

Not in the catalog. CISA has not confirmed exploitation.

Public exploits

No public exploit or proof of concept found in the sources we track.

EPSS

0.6% chance of exploitation activity in the next 30 days, which ranks it in the 45th percentile of scored CVEs.

Exploit Prediction Scoring System, FIRST.org. A probability, not a confirmation.

Attention now

Sustained, driven by in-the-wild reports.

Lifecycle

10 events over 8 days, from the signal feeds we watch.

2026-10-22OpenVAS check added
2026-10-15Workaround availablerecord updated
2026-10-14Workaround availableworkaround available, published, weakness classified, att&ck mapped, record updated, record updated

Affected products

F5commercial · US
- NGINX PlusWeb AppOn-premNetworking Infrastructure / load-balancer-proxy
- NGINX Open SourceWeb AppOn-premNetworking Infrastructure / load-balancer-proxy

Technical detail

CVSS 3.1 vector

Open in the CVSS calculator

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

Scored 8.1 by NVD.

How it is reached

Attack Vector NetworkExploitable remotely over the network without any special conditions
Attack Complexity HighRequires specific conditions like a race condition or non-default configuration
Privileges Required NoneNo authentication required — anyone can exploit this
User Interaction NoneNo user interaction needed — fully automated exploitation

Scope

Scope UnchangedImpact is limited to the vulnerable component itself

Impact if exploited

Confidentiality HighTotal information disclosure — all data in the component is compromised
Integrity HighTotal loss of integrity — attacker can modify any data in the component
Availability HighTotal denial of service — the component is completely unavailable