NGINX CVE-2026-42533: Heap Buffer Overflow from Capture-Variable Ordering in map/regex — Patch Mandatory for Kubernetes Ingress

TL;DR — 90 Seconds

Affected?

Only configurations that use a map directive with regex matching AND, in a string expression, reference the map's numbered capture variables ($1, $2 …) before referencing the map's own output variable. Not every NGINX instance is automatically affected — it depends on the specific configuration pattern.

Risk?

Heap buffer overflow (CWE-122), CVSSv4 9.2 Critical / CVSSv3.1 8.1 High. Denial of service via worker crash is confirmed as reliably reproducible. Remote code execution via ASLR bypass is plausible but not yet publicly demonstrated — as of July 22, 2026 there is no public PoC and no CISA KEV entry.

Immediate action?

Check configurations for regex map blocks with numbered captures. Where an upgrade isn't immediately possible, switch numbered captures to named captures ((?<name>...)) — these are not affected by the ordering bug.

Recommendation?

Patch to NGINX 1.31.3 (mainline), 1.30.4 (stable), or NGINX Plus 37.0.3.1. For Kubernetes ingress: check the patch status of the core engine, Ingress Controller, Gateway Fabric, App Protect, and Instance Manager separately — patching the controller alone doesn't help if the embedded NGINX engine itself stays unpatched.

Criticality?

High. The CVSS rating is Critical, the attack surface across Kubernetes ingress deployments is large, and the DoS path is reliably reproducible — that justifies high priority in the current patch cycle. We do not classify this as "Critical with active exploitation," because RCE remains unproven and no public exploit code is circulating; that distinction matters for clean prioritization.

 

What's the Problem?

To understand the bug, you need to know how NGINX evaluates map blocks with regex matching internally. A map directive using regular expressions isn't evaluated in a single pass, but in two: in the first pass, NGINX determines which regex entry in the map matches, and derives the resulting capture variables ($1, $2, …) as well as the length of the output buffer it needs to allocate. In a second pass, the output value is actually written into that previously allocated buffer.

The problem arises when a string expression — in a log_format directive, a proxy_set_header, or another map, for example — references the map's numbered capture variables before referencing the map's own output variable. In that case, NGINX internally re-evaluates the map's regular expression between the two passes in order to make the capture variables available for use in the string expression. That re-evaluation overwrites the very same capture state the first pass already used to determine the buffer length — potentially with different values, if the request is crafted so the internal re-match produces a longer or differently structured result. The consequence: the buffer allocated in the first pass is too small for what actually gets written in the second pass — and both the length and the content of the overflow are under the requesting client's control, because both depend on the values in the HTTP request against which the regex is matched.

F5 classifies the vulnerability in its accompanying advisory (K000162097) under CWE-122 (Heap-based Buffer Overflow) and rates it CVSSv4 9.2 (Critical) / CVSSv3.1 8.1 (High); the same finding was registered in parallel in the official CVE record (cve.org/CVE-2026-42533). Notably, the underlying map evaluation mechanism has existed unchanged since NGINX 0.9.6 — at its core, this is a roughly 15-year-old race condition between two evaluation passes that has only now been systematically demonstrated.

Who's Affected?

The critical caveat first: CVE-2026-42533 does not automatically affect every NGINX instance on the planet. The flaw is only exploitable where (a) an unpatched NGINX version is in use AND (b) the configuration actually contains a map directive with regex matching whose output is used in a string expression that references the numbered capture variables before the map's own output variable. If you run NGINX purely as a static-file server or reverse proxy with no regex-map constructs, you are not directly affected by this specific CVE — but you should patch anyway, because regex-map constructs are frequently introduced later by ops teams, Helm charts, or third-party modules without everyone involved being aware of it.

Important for Kubernetes operators: NGINX Ingress Controller, Gateway Fabric, App Protect WAF, and Instance Manager are separate products with their own release cycles, but they all embed the same NGINX engine under the hood. A patched Ingress Controller release doesn't help if the bundled NGINX binary itself hasn't been updated to 1.31.3/1.30.4 — so the patch status has to be verified per component, not assumed from the surrounding product's version number.

Impact

Two levels of impact need to be kept separate, because they're backed by very different levels of evidence.

Denial of service (confirmed, reliably reproducible): A request that triggers the vulnerable map/regex constellation overwrites heap memory beyond the allocated buffer and crashes the affected NGINX worker process. Since NGINX worker processes are typically restarted by the master process after a crash, a single request usually causes only brief connection drops for clients that happen to be served by the same worker — but an attacker who repeatedly sends crash-triggering requests can turn that into a sustained availability outage. This path is considered practically proven and requires no special knowledge of the target instance's internal memory layout.

Remote code execution (plausible, not publicly demonstrated): According to secondary reporting, a security researcher named Stan Shaw has claimed that the same write primitive can be repurposed via a single unauthenticated GET request to leak memory addresses from the process space and thereby defeat ASLR (Address Space Layout Randomization) — a classic first step toward a full remote-code-execution chain. That claim is not technically implausible, since a controllable heap-overflow write primitive can in principle be abused for both memory leaks and control-flow manipulation. As of this article's publication (July 22, 2026), however, CVE-2026-42533 is not listed in the CISA KEV (Known Exploited Vulnerabilities) catalog, no public proof of concept exists, and researchers have announced a "delayed PoC release" to give operators time to patch. We therefore treat the RCE path as credible but unproven — a distinction that matters for prioritizing your own patch management: it justifies high urgency, but not panic messaging framed as "actively exploited RCE" while no evidence exists.

Mitigation / Immediate Actions

Upgrade to the patched version

The only complete fix is upgrading to NGINX 1.31.3 (mainline), 1.30.4 (stable), or NGINX Plus 37.0.3.1. For Debian/Ubuntu with the official nginx.org repository:

# Refresh package sources and upgrade to the patched version
sudo apt update
sudo apt install --only-upgrade nginx
# Verify the version
nginx -v

If the official nginx.org repository isn't set up yet:

sudo apt install curl gnupg2 ca-certificates lsb-release debian-archive-keyring
curl nginx.org/keys/nginx_signing.key | gpg --dearmor \
  | sudo tee /usr/share/keyrings/nginx-archive-keyring.gpg >/dev/null
echo "deb [signed-by=/usr/share/keyrings/nginx-archive-keyring.gpg] \
nginx.org/packages/debian $(lsb_release -cs) nginx" \
  | sudo tee /etc/apt/sources.list.d/nginx.list
sudo apt update && sudo apt install nginx

For RHEL/CentOS/Rocky/Alma with the official nginx.org repository:

sudo yum install yum-utils
sudo tee /etc/yum.repos.d/nginx.repo > /dev/null <<'EOF'
[nginx-stable]
name=nginx stable repo
baseurl=https://nginx.org/packages/centos/$releasever/$basearch/
gpgcheck=1
enabled=1
gpgkey=https://nginx.org/keys/nginx_signing.key
module_hotfixes=true
EOF
sudo yum update nginx

For Docker-based deployments: bump the image tag to a variant bundling 1.31.3 or 1.30.4 and rebuild the build context instead of just restarting the running container — the fix lives in the binary, not in runtime configuration:

# Example: pin an explicit tag instead of "latest"
docker pull nginx:1.30.4
# Update the image reference accordingly in your Kubernetes manifests/Helm values
# and trigger a rolling restart of the affected deployments

Stopgap: switch numbered to named captures

Where an immediate upgrade isn't organizationally possible, the specific trigger condition can be defused as a stopgap: named capture groups ((?<name>...)) are not affected by the ordering bug described above, because they don't rely on the shared numbered capture state that gets overwritten between the two evaluation passes.

# Before (potentially vulnerable pattern):
map $http_x_forwarded_for $client_zone {
    ~^(?P<ip>\d+\.\d+\.\d+\.\d+)$ zone_$1;
}
# String expression references $1 BEFORE $client_zone -> vulnerable pattern

# After (stopgap mitigation):
map $http_x_forwarded_for $client_zone {
    ~^(?P<ip>\d+\.\d+\.\d+\.\d+)$ zone_$client_zone;
}
# References the map's output variable instead of the numbered capture variable

This change is explicitly a stopgap, not a substitute for the version patch — it only closes the specific trigger pattern, not the underlying code weakness in the map evaluation mechanism itself.

Kubernetes ingress checklist

• Cross-check the core engine, NGINX Plus, Ingress Controller, Gateway Fabric, App Protect WAF, and Instance Manager individually against their respective patched build levels — patching the Ingress Controller alone only helps if the bundled NGINX engine itself is also patched.
• Grep all ingress/gateway configurations (including annotations that internally generate map blocks) for regex-map patterns with numbered captures.
• As an immediate mitigation, switch numbered captures to named captures, then upgrade properly afterward.
• Prioritize internet-facing Ingress controllers and shared Gateways first — that's where the attack surface is largest and the blast radius highest, since a single ingress often terminates traffic for many namespaces/tenants.
• If you're still running the community project kubernetes/ingress-nginx (EOL since March 2026, last release 1.15.1): no official OSS patch should be expected — plan a migration to an actively maintained fork or a commercially maintained drop-in image alongside the short-term config mitigation.

Detection / Checking

Check the running NGINX version

# Show the compiled version and build flags
nginx -V
# Short-form version number
nginx -v

Check whether the reported version is below 1.30.4 (stable branch) or below 1.31.3 (mainline branch), or for NGINX Plus, below 37.0.3.1.

Grep configuration for the vulnerable pattern

# List all map blocks with regex matching
grep -rn "map \$" /etc/nginx/ | grep -E "~"
# Specifically look for numbered capture references
# that appear alongside a regex map in the same config area
grep -rn '\$[0-9]' /etc/nginx/

The grep search surfaces candidates but doesn't replace manual review: what matters is whether a string expression references $1/$2before referencing that same map's output variable — that ordering can't be reliably detected automatically and requires reviewing each match in context. According to secondary reports, several vendors have since released static config scanners that detect exactly this ordering pattern; for your own inventory, it's worth running such a tool in addition to manual review once a trustworthy one is available.

Kubernetes: check ingress component image versions

# List image references for all pods in the ingress-nginx namespace
kubectl get pods -n ingress-nginx -o jsonpath='{range .items[*]}{.metadata.name}{"\t"}{.spec.containers[*].image}{"\n"}{end}'

# Query the actual NGINX version inside a running controller pod
kubectl exec -n ingress-nginx <pod-name> -- nginx -V

# Filter all deployment image tags in the cluster for nginx-related images
kubectl get deployments -A -o jsonpath='{range .items[*]}{.metadata.namespace}{"/"}{.metadata.name}{"\t"}{.spec.template.spec.containers[*].image}{"\n"}{end}' | grep -i nginx

These commands follow the standard kubectl pattern for image and version lookup; the exact output depends on your specific Ingress Controller deployment (namespace and container names may differ), so treat them as a starting point rather than a copy-paste guarantee for every installation.

Operator Recommendation

Operational decision guide:

• Act today if: An internet-facing NGINX ingress terminates traffic for production systems AND the configuration contains regex-map constructs with numbered captures (or you can't confidently verify their absence).
• Handle in the next regular patch cycle if: The running NGINX version is unpatched, but a configuration review found no vulnerable regex-map patterns in the request path — patch soon regardless, because configurations change.
• Just verify if: You're already patched to 1.31.3/1.30.4/Plus 37.0.3.1 — here, a stocktake is enough to confirm that every instance (including Ingress Controller, Gateway Fabric, App Protect, Instance Manager) has actually reached that patch level.

For SMB operators

If you run NGINX as a classic reverse proxy or load balancer in front of a manageable number of applications, your configuration base is usually small and easy to survey — which makes a manual review for regex-map patterns feasible in an hour or two. The pragmatic order of operations: patch first (the upgrade is the complete fix and, in most cases, lower-risk than a manual configuration change), then calmly review the configuration for the pattern to understand whether you were even exposed. I'd explicitly advise against playing the upgrade and the configuration review off against each other — both belong in the same maintenance window.

For enterprise environments

Larger environments with many NGINX instances spread across different teams, different deployment pipelines, and sometimes legacy configs nobody fully understands anymore should treat this CVE as a trigger to build or refresh a central inventory of all NGINX-based components — including NGINX Plus, App Protect WAF, and Instance Manager, not just open-source instances. Without that inventory, "are we affected?" stays a question that takes weeks instead of hours to answer. Prioritize by internet exposure and by the business criticality of the systems behind each instance, not by alphabetical hostname order.

For Kubernetes operators

Here the urgency is structurally higher, because a single Ingress Controller often terminates traffic for many namespaces and tenants — a successful DoS against the ingress doesn't just affect one application, it can hit cluster-wide traffic. If you're still running the EOL community project kubernetes/ingress-nginx at version 1.15.1, treat the lack of an official patch as an additional urgency factor, and plan a medium-term migration decision (a maintained fork, a commercially supported drop-in image, or a switch to a different ingress/gateway implementation) alongside the short-term config mitigation. In my own FrankenPHP/Kubernetes deployments for TYPO3 hosting, I've deliberately leaned toward leaner, well-maintained ingress alternatives with a smaller attack surface for some time now — this CVE is one more data point for why that decision keeps paying off, in my view.

What I Actually Did

Even though NGINX has largely been replaced by FrankenPHP/Caddy in my own production stack for TYPO3 hosting, I still support existing customers and legacy setups where NGINX sits in the request path — so CVE-2026-42533 wasn't a purely theoretical advisory for me. After it became public, I first pulled an image-digest inventory of every NGINX-based container image across my own operational footprint — fixed tags alone don't tell you enough, because "nginx:stable" can point at something different today than it did two weeks ago, and with a CVE like this I want to know exactly which binary is actually running in which environment. In parallel, I ran a targeted grep sweep across my own and my customers' managed NGINX configurations looking for regex-map blocks — with the expected result that most configurations don't use a regex-matching map directive at all, but two legacy configs with a WAF-bypass workaround from 2023 fell squarely into the vulnerable pattern. Those were switched to named captures as a priority, while the regular version patch was scheduled for the next planned maintenance slot. On top of that, I scanned my own internet-facing address inventory (externally reachable IPs/domains) against the fingerprint "NGINX server header without a current patch level," just to make sure no forgotten instance slips through — a discipline that has paid off with practically every major advisory in recent years, because "forgotten" instances are almost always the ones that stay unpatched the longest.

Conclusion

CVE-2026-42533 is a case study in how a two-pass evaluation quirk sitting untouched in the code for 15 years can, under the right combination of configuration pattern and attacker-controlled input, become a Critical-CVSS advisory. The good news: the vulnerability is configuration-dependent, not universal — if you don't use a regex map with numbered captures referenced ahead of the output variable, you're not exploitable through this specific path. The bad news: that exact pattern shows up surprisingly often in grown WAF workarounds, header normalization logic, and multi-tenant routing rules — and you won't stumble on it by accident; you have to go looking. For Kubernetes operators, the affected engine is embedded deep inside multiple ingress and gateway products, so a complete picture only emerges from checking each component's version individually. DoS is confirmed and reproducible, RCE is plausible but (as of July 22, 2026) unproven — communicating that distinction cleanly matters just as much as patching itself, because panic framing here costs credibility the next time a vulnerability actually is being actively exploited.

Sources

• CVE-2026-42533 — official CVE record (cve.org) — primary source for CVE assignment, description, and references.
• F5 Knowledge Base article K000162097 — official advisory with CVSS ratings, affected and patched versions.
• nginx.org Security Advisories — official overview of NGINX version status for CVE-2026-42533 (affected 0.9.6–1.31.2, fixed from 1.31.3/1.30.4).
• HeroDevs: CVE-2026-42533 and EOL Ingress-NGINX — analysis of the impact on the EOL community project kubernetes/ingress-nginx.
• The Hacker News: Critical NGINX Vulnerability Can Crash Workers and May Allow Remote Code Execution — secondary reporting on the RCE assessment and the ASLR-bypass claim.