CVE-2026-42533: Critical NGINX Heap Overflow Hits EOL Ingress-NGINX

On July 15, 2026, F5 disclosed CVE-2026-42533, a Critical, unauthenticated flaw in NGINX that a remote attacker can trigger with ordinary HTTP requests, crashing the worker process and, in the worst case, running code on it. If you run the community Kubernetes ingress-nginx controller, this sits right at your cluster edge, and the end-of-life 1.15.1 line (retired in March 2026) has no upstream fix.

The bug is a heap buffer overflow (CWE-122) in NGINX's script engine, the internal code that builds strings from directives at request time. It surfaces when a map directive using regex references a capture variable ($1, $2, …) before the map's own output variable: NGINX sizes the output buffer in one pass and writes it in another, the two passes disagree on the length, and the write runs off the end of the allocation.

F5, acting as CNA, scored it 9.2 Critical on CVSS v4.0 (CVSS:4.0/AV:N/AC:H/AT:N/PR:N/UI:N/VC:H/VI:H/VA:H/SC:N/SI:N/SA:N) and 8.1 High on CVSS v3.1; it carries GHSA-fxfg-v4rj-hp95.

TL;DR

• CVE-2026-42533 is a Critical heap buffer overflow in NGINX's script engine (9.2 CVSS v4.0 / 8.1 High CVSS v3.1), triggered through a map directive that references a regex capture variable before the map's output variable.
• It's remotely reachable and unauthenticated (PR:N) but not trivial to exploit (AC:H). It needs the specific vulnerable map/regex config present in the running configuration. Worker crash (DoS) is the reliable outcome. Memory disclosure is possible, and remote code execution is the worst case but is gated behind ASLR being disabled or bypassed. As of disclosure, F5 reports no confirmed in-the-wild exploitation and no public PoC.
• Upstream NGINX fixed it in 1.30.4 (stable) and 1.31.3 (mainline). One upgrade also clears two lower-severity siblings from the same July 15 batch.
• The exposed population is the community ingress-nginx controller: v1.15.1 reached EOL and was archived in March 2026, so there is no OSS fix for it.
• If you're on EOL 1.15.1 and can't migrate yet, a remediated drop-in build (NES for Ingress NGINX) closes it in place; otherwise upgrade to a maintained build shipping the fixed NGINX.

‍

What is CVE-2026-42533?

CVE-2026-42533 is a heap-based buffer overflow (CWE-122) in the NGINX script engine, the internal component that assembles strings from directives at request time. It is reachable through the map directive when that directive uses regular-expression matching and a string expression references the map's regex capture variables before referencing the map's output variable. F5's advisory notes the same corruption can also be reached through a non-cacheable variable used in a string expression under specific conditions.

The script engine is not exotic or rarely used code. Any configuration that composes $variables into a value, through proxy_set_header, add_header, return, rewrite, log_format, set, a map output, or similar, runs through it. That makes the exposure a function of configuration shape rather than a niche feature flag, which is why F5 stresses that configuration review matters as much as version inventory.

For Kubernetes platform teams, the relevant packaging is the community ingress-nginx controller. It embeds an NGINX Open Source build and generates NGINX configuration from Ingress objects and annotations, so a vulnerable NGINX script-engine path ships inside the controller image rather than being something the cluster operator compiled directly.

‍

Root cause: a shared capture array the two passes do not agree on

NGINX evaluates a string expression in two passes. The first, the LEN pass, walks the expression to measure how large a buffer it needs. The second, the VALUE pass, writes the actual bytes into the buffer that was allocated from the first pass's measurement. Both passes read from the same mutable, per-request capture array (internally r->captures), which holds the substrings matched by regex groups such as $1 and $2.

The bug is a missing save-and-restore of that capture state across the two passes. When a map directive with a regex pattern executes between two references to a capture group, running its own regex overwrites the shared capture array in place. So the LEN pass reads $1 holding one value (possibly stale content left over from an earlier capture), while the VALUE pass, after the map's regex has fired, reads $1 holding attacker-influenced content of a different length. If the VALUE pass produces more bytes than the LEN pass measured, the write runs past the end of the allocated heap buffer. That length disagreement, with attacker-controlled content and attacker-influenced length, is the heap overflow.

The capture-ordering path has existed since the map directive gained regex support in March 2011, which is why a bug disclosed in 2026 affects such a long tail of releases. The relevant point for this post is narrower: the community ingress-nginx controller reached end of life in March 2026 at v1.15.1, and the NGINX Open Source build inside that image sits squarely in the affected range with no upstream OSS release to move to.

‍

Severity and exploit conditions

F5 scored CVE-2026-42533 at 9.2 Critical on CVSS v4.0, and 8.1 High on CVSS v3.1. At the time of writing, NVD had not yet published its own analysis, so the CNA (F5) base scores are authoritative with that attribution.

The PR:N metric is the one to read carefully: this is an unauthenticated flaw, so no login or token is required to reach it. The AC:H metric means it is not trivially exploitable against an arbitrary server; the attacker needs the vulnerable map-plus-regex-capture pattern to be present in the running configuration, and reliable code execution additionally depends on ASLR being disabled or bypassed. Unauthenticated and network-reachable, but non-trivial, is the accurate framing, not "trivial one-shot RCE."

‍

Exploitation status

F5 has not confirmed in-the-wild exploitation, and there is no F5-published proof of concept for CVE-2026-42533. As of this writing the CVE is not listed in CISA's Known Exploited Vulnerabilities catalog.

The reporter, Stan Shaw, has stated that a proof-of-concept exploit exists but is being withheld to give operators time to patch, citing the risk of rapid exploitation after disclosure. Shaw also released a static configuration scanner that identifies vulnerable map/regex configurations without exploiting them, which is a defensible way to check exposure. Memory-corruption bugs in widely deployed proxies have historically been weaponized after disclosure, so the absence of a public exploit today is a reason to move now, not a reason to wait.

We do not publish weaponized exploit code. The mechanism described above is sufficient to understand exposure and remediate.

‍

What an attacker can do

The impact depends on how far an attacker can push the heap corruption, but the practical outcomes are:

• Crash or restart worker processes (denial of service). The most reliable outcome. A crafted request that trips the length mismatch corrupts the worker's heap and takes the process down. For an ingress controller sitting in front of cluster traffic, repeated crashes translate directly into dropped or degraded request handling for every backing service behind it.
• Disclose worker process memory. Because the corruption gives some control over what gets read and written around the overflow, an attacker may be able to surface adjacent heap contents, which can include fragments of other in-flight requests or secrets held in worker memory. This is why the vector scores VC:H.
• Execute code in the worker context, conditionally. F5 states that on systems where ASLR is disabled or can be bypassed, the overflow may allow remote code execution in the NGINX worker process. That is the worst case and the reason the CVE is rated Critical rather than merely High. It is gated behind defeating ASLR, which is the AC:H portion of the score, not a given.

For a Kubernetes ingress controller specifically, the blast radius is the cluster edge: the process being corrupted is the one terminating and routing external HTTP/HTTPS traffic for the workloads behind it.

‍

Who is affected?

The vulnerable script-engine path is present in NGINX Open Source from the introduction of map regex support (2011, 0.9.6-era) through 1.30.3 (stable) and 1.31.2 (mainline). Upstream NGINX fixed it in 1.30.4 (stable) and 1.31.3 (mainline). The community Kubernetes ingress-nginx controller embeds an NGINX Open Source build; v1.15.1 is the last community release, the repository was archived in March 2026, and its embedded NGINX falls inside the affected range with no further community releases to move to.

The community ingress-nginx project reached end of life in March 2026: no further releases, bugfixes, or security patches. For the full picture of what is and is not EOL and the migration options, see the Ingress NGINX end-of-life guide.

Note there are two distinct projects often both called "NGINX Ingress." This CVE and this post concern the community kubernetes/ingress-nginx controller that reached EOL in March 2026. The separately maintained F5 NGINX Ingress Controller is a different product with its own supported releases and patch path.

‍

Mitigation guidance

The configuration workaround is real risk reduction, but for an EOL controller it is a stopgap: the underlying build stays unpatched and the next NGINX-layer CVE will find it again. The clean path for a supported line is the upstream release; the clean path for EOL 1.15.1, where no OSS release exists, is a remediated build.

NES for Ingress NGINX ships as an OCI image and Helm chart and slots into GitOps, Argo CD, and Flux workflows, and every release carries VEX statements for audit and SBOM evidence. It replaces the upstream controller in place, leaving ingress rules and application configuration untouched.

‍

Related CVEs

• CVE-2026-42945: a separate Critical (9.2) heap-based buffer overflow affecting NGINX OSS and the ingress-nginx builds that compile against it, including upstream v1.15.1. Same EOL exposure, same no-OSS-fix gap for the retired community controller.
• CVE-2026-42055: the NGINX gRPC/HTTP-2 heap overflow that also lands on EOL Ingress NGINX. See the full deep-dive on CVE-2026-42055. All three are data-plane memory-corruption flaws that leave the retired community controller with no OSS remediation path.

CVE-2026-42533 was disclosed alongside two lower-severity NGINX siblings in the same July 15 batch: CVE-2026-60005 (an uninitialized-memory read in the optional slice module) and CVE-2026-56434 (a use-after-free in the SSI module, reachable only with SSI plus proxy_pass plus proxy_buffering off). The single NGINX upgrade that fixes CVE-2026-42533 also resolves those two.

‍

Taking action

If you run a maintained NGINX or ingress controller, upgrade to a build shipping NGINX 1.30.4 or 1.31.3 and you are done. The hard case is the large installed base still running the community ingress-nginx controller at v1.15.1. That project reached end of life in March 2026, the repository is archived, no OSS fix exists for it, and CVE-2026-42533 is an unauthenticated, network-reachable heap overflow sitting at the cluster edge.

That is the exact gap NES for Ingress NGINX is built to close. HeroDevs delivers a remediated, drop-in controller image and Helm chart for the EOL version you already run, so your platform team can close CVE-2026-42533 today and migrate to a Gateway API implementation or another controller on its own schedule rather than under CVE pressure.

If you are running EOL Ingress NGINX and cannot migrate on this timeline, see NES for Ingress NGINX or get in touch to scope coverage.