CVE-2026-42533
This Vulnerability has been fixed in the Never-Ending Support (NES) version offered by HeroDevs.
Overview
Ingress NGINX Controller is an ingress controller for Kubernetes that uses NGINX as a reverse proxy and load balancer. It embeds an NGINX Open Source build and generates NGINX configuration from Ingress objects and annotations, so an NGINX-layer flaw ships inside the controller image rather than being something the cluster operator compiled directly. It is one of the most widely deployed ingress controllers in production Kubernetes clusters, routing external HTTP/HTTPS traffic to Services running inside the cluster.
A heap-based buffer overflow (CVE-2026-42533) has been identified 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 ($1, $2, and so on) before referencing the map's own 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. A remote, unauthenticated attacker can trigger it with crafted HTTP requests, crashing the worker process (denial of service) and, where ASLR is absent or defeated, potentially achieving remote code execution.
Per OWASP: a buffer overflow occurs when a process writes data beyond the bounds of an allocated memory region, corrupting adjacent state in a way that can be steered into a crash or, in the worst case, arbitrary code execution.
This issue affects NGINX Open Source 0.9.6 through 1.31.2, and every downstream that compiles the affected script engine, including the upstream Ingress NGINX Controller v1.15.1. Upstream NGINX shipped the fix in 1.30.4 (stable) and 1.31.3 (mainline) on July 15, 2026. The Kubernetes ingress-nginx project retired in March 2026 at v1.15.1 and will not ship a release that absorbs the fix.
Why this matters for Ingress NGINX deployments
CVE-2026-42533 lives in the NGINX C code compiled directly into the controller binary, not in a swappable Go dependency. Remediation therefore requires patching the underlying NGINX build, not bumping a module version. The exposure is a function of configuration shape rather than a niche feature flag: any configuration that composes $variables into a value, through proxy_set_header, add_header, return, rewrite, log_format, set, or a map output, runs through the same script engine, which is why F5 stresses that configuration review matters as much as version inventory.
The exposure sits at the worst possible surface. An ingress controller terminates external TLS, sits in front of every Service in the cluster, and is directly reachable from the public internet. For teams running upstream Ingress NGINX v1.15.1, scanners begin reporting CVE-2026-42533 as an open Critical the moment NVD propagates the advisory, and no upstream release will close it. NES for Ingress NGINX rebases the controller's compiled NGINX with the patched script engine, closing the finding without a configuration change or a Gateway API migration.
Details
Module Info
- Product: NGINX (script engine, map directive); compiled-in component of Ingress NGINX Controller
- Affected components: the NGINX two-pass script engine (LEN pass and VALUE pass) and the shared per-request capture array (r->captures) used by map regex matching
- Affected versions: NGINX Open Source 0.9.6 through 1.31.2 (map regex support introduced in 0.9.6, 2011); Ingress NGINX Controller builds that compile against those versions, including upstream v1.15.1
- Upstream source repository: https://github.com/nginx/nginx
- Container image (community, affected): registry.k8s.io/ingress-nginx/controller
- Helm chart (community): https://kubernetes.github.io/ingress-nginx
- Distribution channels: container registry (registry.k8s.io), Helm, kubectl manifests
- Fixed in:
- nginx 1.30.4 (stable) and 1.31.3 (mainline), July 15, 2026 (upstream)
- NES for Ingress NGINX, merged July 22, 2026, which backports the upstream patch onto the controller's pinned NGINX baseline (see release notes)
- Advisory identifier: GHSA-fxfg-v4rj-hp95
Vulnerability Info
This Critical-severity vulnerability lives in the two-pass script engine that NGINX uses to build strings from directives at request time.
NGINX evaluates a string expression in two passes. The first, the LEN pass, walks the expression to measure how large a buffer it needs and allocates that much memory. The second, the VALUE pass, writes the actual bytes into the buffer allocated from the first pass's measurement. Both passes must compute the same length, and both 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.
CVE-2026-42533 breaks that contract through a missing save-and-restore of the 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. 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.
Threat model for Ingress NGINX clusters: exploitation requires a vulnerable build plus a running configuration in which a string expression references a regex capture variable before a map-produced output variable. Because the script engine is on the path for routine directives (proxy_set_header, add_header, rewrite, map outputs, and similar), the trigger pattern is a function of configuration shape rather than an exotic feature. No authentication is required and no user interaction is needed; the attacker needs only network reach to a vhost whose configuration exercises the pattern. The AC:H metric reflects that the specific pattern must be present and that reliable code execution additionally depends on ASLR being disabled or bypassed.
When successfully exploited, this vulnerability can lead to:
- Denial of service through worker-process crashes; for an ingress controller in front of cluster traffic, repeated crashes translate into dropped or degraded request handling for every backing service behind it
- Disclosure of adjacent worker-process memory, which can include fragments of other in-flight requests or secrets held in worker memory (the reason the vector scores VC:H)
- Remote code execution in the NGINX worker process on systems where ASLR is disabled or can be bypassed (the worst case, and the reason the CVE is rated Critical rather than merely High)
Severity and exploit conditions
F5, acting as CNA, scored CVE-2026-42533 at 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. 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 present in the running configuration, and reliable code execution additionally depends on defeating ASLR. Unauthenticated and network-reachable, but non-trivial, is the accurate framing, not "trivial one-shot RCE."
Exploitation status
As of disclosure, F5 has not confirmed in-the-wild exploitation, and there is no F5-published proof of concept for CVE-2026-42533. The CVE is not listed in CISA's Known Exploited Vulnerabilities catalog at the time of writing. The reporter, Stan Shaw, has stated that a proof-of-concept exploit exists but is being withheld to give operators time to patch, and has released a static configuration scanner that identifies vulnerable map/regex configurations without exploiting them. Memory-corruption bugs in widely deployed proxies have historically been weaponized after disclosure, so the absence of a public exploit is a reason to move promptly rather than a reason to wait.
Steps To Reproduce
- Stand up a controller running upstream Ingress NGINX v1.15.1 (or any NGINX build in the affected range).
- Apply a configuration in which a map directive uses a regex pattern and a string expression references an unnamed capture variable ($1, $2) before the map's own output variable, so the map's regex fires between the LEN and VALUE passes.
- Send a crafted HTTP request whose matched capture content differs in length between the two passes, so the VALUE pass writes more bytes than the LEN pass measured.
- Observe the worker process crash and restart in the controller logs. Note that nginx -t does not flag the trigger pattern; the configuration is syntactically valid.
Proof Of Concept
No weaponized exploit code is published. The reporter has withheld a working proof of concept to give operators time to patch, and has instead released a static configuration scanner that flags vulnerable map/regex configurations. The root-cause mechanism described above is sufficient to understand exposure and remediate.
Mitigation
OSS Users
Users of upstream NGINX and Ingress NGINX should apply one of the following mitigations:
- Upgrade NGINX Open Source to 1.30.4 (stable) or 1.31.3 (mainline) and restart workers; a single upgrade also resolves two lower-severity siblings disclosed in the same July 15 batch (CVE-2026-60005, an uninitialized-memory read in the slice module, and CVE-2026-56434, a use-after-free in the SSI module).
- Or move to a maintained controller build that ships the fixed NGINX.
- As a configuration stopgap on builds that cannot be patched immediately, apply F5's workaround: replace unnamed regex captures with named captures in map directives and reference those captures only inside the block that holds the regex match, then audit configs for string expressions that reference $1/$2 before a map-produced variable. This 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.
- For Ingress NGINX specifically, no upstream release will rebase against the patched NGINX because the project retired in March 2026. Sign up for post-EOL security support; HeroDevs customers get immediate access to a patched Ingress NGINX build.
NES Customers
HeroDevs Never-Ending Support for Ingress NGINX resolves CVE-2026-42533 by backporting the upstream patch onto the controller's pinned NGINX baseline. The release ships as a drop-in replacement for upstream ingress-nginx v1.15.1: it ships as an OCI image and Helm chart, slots into GitOps, Argo CD, and Flux workflows, and carries VEX statements so scanners that consume OpenVEX or CycloneDX VEX surface the patched status instead of leaving CVE-2026-42533 as an open finding. It replaces the upstream controller in place, leaving ingress rules and application configuration untouched. See the NES for Ingress NGINX release notes for the exact patched version and image tag.
Related CVEs
- CVE-2026-42945: a separate Critical (9.2) heap-based buffer overflow in the NGINX rewrite module ("NGINX Rift"), affecting NGINX OSS and the ingress-nginx builds that compile against it, including upstream v1.15.1.
- CVE-2026-42055: the NGINX HTTP/2 and gRPC proxy heap overflow that also lands on EOL Ingress NGINX.
- CVE-2026-48142: the NGINX charset-module buffer over-read disclosed in the June 17 batch.
All are data-plane memory-corruption flaws that leave the retired community controller with no OSS remediation path. For the full deep-dive, see the CVE-2026-42533 blog post, and browse the full vulnerability directory.
Compliance impact
CVE-2026-42533 is a Critical, unauthenticated, network-reachable flaw at the cluster edge. Several frameworks make the gap acute for teams on an EOL controller:
- The EU Cyber Resilience Act's Article 14 reporting obligations begin September 11, 2026; "the upstream project no longer ships fixes" is not a valid answer for a Critical.
- DORA's ICT third-party risk requirements have been in force since January 2025.
- PCI DSS 4.0 expects continuous evidence that components receive security patches.
- FedRAMP authorizations carry continuous monitoring obligations.
The NES release ships a documented patch trail plus VEX statements that scanners consume programmatically.
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. NES for Ingress NGINX is the patched build for clusters that cannot complete a Gateway API migration before regulatory and exploitation pressure converge. 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.
Credits
- Stan Shaw (finder; reported the flaw and released a static configuration scanner)
- F5 (CNA; advisory and CVSS scoring)
- HeroDevs NES for Ingress NGINX engineering (downstream backport and rebuild)
References
