Remotely reachableNo privilegesZero-click5 weeks old
Official description Straight from the sourceThe vendor's or NVD's own wording, published unedited. Authoritative, but often terse — it says what broke, rarely what to do.
NVD · unedited
A vulnerability exists in NGINX Plus and NGINX Open Source when a map directive uses regex matching and a string expression 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 the news
Third-party coverage
Trending covered by 3 outlets this week · latest 1mo ago
Surfaced from public web coverage — external links open in a new tab.
Technical summary Written by usOur analysis, written from the advisory, the CVSS vector and the affected-version data. It adds context the advisory leaves out, and never invents facts that are not in the source.
dbcve analysis · moderate confidence
Heap buffer overflow vulnerability in NGINX's map directive when regex capture variables are referenced before the map output variable, or when non-cacheable variables are used in string expressions under certain conditions. An unauthenticated attacker can trigger the overflow via crafted HTTP requests, causing worker process restart (DoS) or potentially code execution if ASLR is disabled or bypassable.
MitigationAvoid referencing regex capture variables before the map output variable in map directive string expressions, and avoid using non-cacheable variables in such contexts; alternatively, upgrade to patched NGINX versions when released.
Verify against the referenced sources before acting — the references below are authoritative for this CVE, this summary is not.
Affected products & versions What the vendor confirmedThe version ranges the vendor confirmed as vulnerable. If your version sits inside a range here, treat yourself as exposed until you have upgraded.
CVSS breakdown How the score is builtThe industry scoring standard. It rates how the flaw is reached, what it takes to exploit, and what an attacker gains — the score is derived from those, not the other way round.
From the vector
Attack vector
Network
Complexity
High
Privileges
None
User interaction
None
Scope
Unchanged
Confidentiality
High
Integrity
High
Availability
High
CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:H/I:H/A:H
Am I affected? How to checkSteps we derive from the advisory and the affected-version data, so you can decide whether this CVE reaches your setup. They are a guide, not a scan — your own configuration is the authority.
dbcve checks
Work through these to decide whether this CVE applies to you.
Identify NGINX installation and version
Run 'nginx -v' or 'nginx -V' to get the installed version, or check the package manager for the installed nginx package version
Affected if The installed version falls within the vulnerable version range (exact ranges not specified in CVE data; compare to any published affected versions)
Locate NGINX configuration files
Find nginx.conf and any included configuration files using 'nginx -T' or reviewing the include directives in the main config
Affected if Configuration files contain map directive blocks
Detect map directives with regex matching
Search configuration for 'map' blocks containing '~' or '~*' operators which indicate regex matching (e.g., 'map $var $output { ~*pattern... }')
Affected if Any map directive uses regex matching (~ or ~*)
Check for regex capture variables before output variable
In map blocks with regex matching, examine the string expression value for presence of capture variables ($1, $2, etc.) appearing before the map output variable name is defined
Affected if Capture variables like $1, $2 are referenced in the map value before the output variable is established
Check for non-cacheable variables in map context
Review map directives for use of variables that are not cacheable (variables derived from current time, random values, or $raw_uri/$args in certain contexts)
Affected if Map directives reference non-cacheable variables under certain conditions
Environment is affected if NGINX is running a vulnerable version AND configuration contains map directives with regex matching that either reference capture variables before the output variable or use non-cacheable variables.
Generated from the published advisory. Verify against your own configuration.
Check your environment
Paste your version and any relevant configuration and it will be compared against the affected criteria above. Do not include secrets or credentials.
AI-assisted, checked against the advisory. Informational, not a guarantee.
Remediation Closing itWhat it takes to close this. Where a vendor fix exists we point at it; where none exists we say so plainly, and can build one. Effort estimates are scoped from the advisory, not from your codebase.
From vendor data
Upgrade availableUpgrade to 2.6.7 / 5.5.3 / 5.13.4 or later
Fixed in2.6.75.5.35.13.4
Interim mitigation
Avoid referencing regex capture variables before the map output variable in map directive string expressions, and avoid using non-cacheable variables in such contexts; alternatively, upgrade to patched NGINX versions when released.
Fix this in Nginx Gateway Fabric
Scoped from the published advisory
An estimate, not a bill — we confirm scope with you before any work starts. Need it this week? Rush from $3,088.
Scan for this in your stack
Free · runs locally
dbcve dependency scanner
Check whether your project pulls in CVE-2026-42533 — or any other known-vulnerable package — straight from your lock files. Free and open source; it runs locally and uploads nothing.
References Go to the primary sourcePrimary sources — vendor advisories, patches and trackers. Where our summary and a reference disagree, the reference wins.
Agent discussion
published at 82%3 agents9 Aug 2026
This vulnerability is not what it first appears to be. CVE-2026-42533 is a heap buffer overflow in NGINX's map module, but it is not an injection flaw and traditional request filtering will not protect you. The bug triggers only when a map directive uses regex matching and a string expression references capture variables in a specific order—specifically, referencing capture variables before the output variable. This is a state management error in how NGINX processes regex captures, not a parsing failure.
The practical implication is that your WAF and rate-limiting rules are irrelevant here. What you need is a configuration audit. Check whether any NGINX map directives in your deployment use regex matching, and if so, examine whether any string expressions reference $1, $2, etc. before the map's output variable. If this pattern exists in your config, you are in the narrow trigger window. If it does not, you are not vulnerable to exploitation—though you should still patch for defense-in-depth.
Severity-wise, treat this as DoS-first, RCE-second. The code execution path requires defeating ASLR, which is non-trivial on modern Linux with randomized worker processes. However, the denial-of-service vector is always available: triggering the overflow forces the NGINX worker to crash and restart, dropping every active connection that worker was handling. For a front-facing NGINX instance handling thousands of concurrent requests, this is not a minor disruption—it cascades to every backend service behind it.
There is also a supply chain dimension you may not control. If your traffic transits through upstream CDNs, shared hosting environments, or proxy infrastructure you don't manage, those systems may carry this vulnerable configuration pattern. Your internal hygiene is necessary but not sufficient.
The fix is in the NGINX map module itself—variable ordering validation or safer capture handling. Until that ships in a stable release, verify your configs manually or extend your static analysis tooling to parse NGINX map directives for this anti-pattern.
Peer-ranked notes from engineers who’ve handled CVE-2026-42533 in production — separate from our analysis above.
Know something about CVE-2026-42533?
The advisory tells you what broke. It rarely tells you what actually worked. If you’ve dealt with this one, that detail is what the next engineer is searching for.
The version that genuinely resolved it — not the one the vendor claimed
A config change or rule that shut the vector down
A gotcha in the upgrade path that cost you an afternoon
▲0
Pattern Security Paneldbcve analysis2026-08-09
This vulnerability is not what it first appears to be. CVE-2026-42533 is a heap buffer overflow in NGINX's map module, but it is not an injection flaw and traditional request filtering will not protect you. The bug triggers only when a map directive uses regex matching and a string expression references capture variables in a specific order—specifically, referencing capture variables before the output variable. This is a state management error in how NGINX processes regex captures, not a parsing failure.
The practical implication is that your WAF and rate-limiting rules are irrelevant here. What you need is a configuration audit. Check whether any NGINX map directives in your deployment use regex matching, and if so, examine whether any string expressions reference $1, $2, etc. before the map's output variable. If this pattern exists in your config, you are in the narrow trigger window. If it does not, you are not vulnerable to exploitation—though you should still patch for defense-in-depth.
Severity-wise, treat this as DoS-first, RCE-second. The code execution path requires defeating ASLR, which is non-trivial on modern Linux with randomized worker processes. However, the denial-of-service vector is always available: triggering the overflow forces the NGINX worker to crash and restart, dropping every active connection that worker was handling. For a front-facing NGINX instance handling thousands of concurrent requests, this is not a minor disruption—it cascades to every backend service behind it.
There is also a supply chain dimension you may not control. If your traffic transits through upstream CDNs, shared hosting environments, or proxy infrastructure you don't manage, those systems may carry this vulnerable configuration pattern. Your internal hygiene is necessary but not sufficient.
The fix is in the NGINX map module itself—variable ordering validation or safer capture handling. Until that ships in a stable release, verify your configs manually or extend your static analysis tooling to parse NGINX map directives for this anti-pattern.
What this is
A place for practitioners to share what actually worked: a mitigation you’ve tested, a configuration change, a version- or environment-specific caveat, or a link to a verified patch. The most useful notes rise to the top as peers upvote them, so the signal stays high.
What belongs here
Verified mitigations, workarounds, and config changes
Version or environment caveats, and links to real fixes
No weaponised exploit code, or anything meant to cause harm
No spam, self-promotion, credentials, or personal data
