NGINX’s 2026 has been rough. May brought NGINX Rift, an 18-year-old heap overflow in the rewrite module. June brought a matched pair of HTTP/3 and HTTP/2 unauthenticated memory-corruption bugs. On July 15, F5 disclosed a third: CVE-2026-42533, a CVSS v4.0 9.2 (CVSS v3.1 8.1) heap buffer overflow in NGINX’s script engine, reachable through the ordinary map directive that a huge share of production configs already use. It shipped alongside two lower-severity siblings in the same batch. None are known to be exploited yet, but a public scanner for CVE-2026-42533 is already circulating and a full weaponized exploit is expected by August.

What’s broken

NGINX’s script engine is the internal component that assembles strings from directive values at request time — it’s what lets you write things like map $http_referer $blocked { ... } and then interpolate the result elsewhere in your config. CVE-2026-42533 lives in how that engine handles regex capture groups inside map blocks: when a regex-based map directive’s output variable is referenced in a string expression that comes after an unnamed capture ($1, $2, …) from an earlier regex match, the buffer-size calculation and the actual write disagree, and NGINX writes past the end of a heap allocation (CWE-122).

The trigger is entirely attacker-controlled — an unauthenticated remote party sends crafted HTTP requests, and if the fields NGINX runs through the vulnerable map/capture pattern land in the request (headers, URI, query string, anything commonly mapped), the overflow fires in the worker process. The reliable outcome is a worker crash and restart — a straightforward denial-of-service loop against whatever sits behind that NGINX instance. Where ASLR is disabled or bypassable, F5 says the same primitive can be pushed to remote code execution in the worker.

Two lower-severity bugs landed in the same July 15 release:

  • CVE-2026-60005 (CVSS v4.0 8.8) — an uninitialized-memory read in the optional ngx_http_slice_module that can leak worker process memory back to the client.
  • CVE-2026-56434 (CVSS v4.0 8.3) — a use-after-free in ngx_http_ssi_module, reachable only when Server Side Includes is combined with proxy_pass and proxy_buffering off.

Affected versions and impact

CVE-2026-42533 affects NGINX Open Source from 0.9.6 through 1.30.3 stable and mainline through 1.31.2 — effectively every build in circulation until the July 15 fix. That includes NGINX Plus. The vulnerable code path doesn’t stop at the core web server: it extends into every F5 product that embeds NGINX as its data plane, including NGINX Ingress Controller and NGINX Gateway Fabric — meaning it sits directly in the request path for a large slice of Kubernetes clusters — plus NGINX App Protect WAF and NGINX Instance Manager.

Given how commonly map is used for things like referrer-based routing, geo/IP allow-lists, header rewriting, and A/B logic, a large number of real-world configs plausibly satisfy the trigger conditions without anyone having audited for this specific capture-ordering pattern. Combined with the fact that the vulnerable component fronts internet-facing Kubernetes ingress traffic in a huge number of clusters, this is a wide blast radius for a bug that requires nothing more than an HTTP request to reach.

Mitigation

  • Upgrade NGINX Open Source to 1.30.4 (stable) or 1.31.3 (mainline); upgrade NGINX Plus to 37.0.3.1 or R36 P7.
  • Downstream products: update to NGINX Ingress Controller 5.5.3 (or the 2026-lts-r4 track) and NGINX Gateway Fabric 2.6.7 or later.
  • If you can’t patch immediately, F5’s stopgap is a config change: replace unnamed regex captures ($1, $2) with named captures, and only reference them inside the block that holds the regex match. That single change blunts both CVE-2026-42533 and the slice-module bug.
  • If you run SSI, drop proxy_buffering off from any location block that also uses proxy_pass with SSI enabled, or disable SSI where it isn’t needed, until you’ve patched CVE-2026-56434.
  • Audit whether ngx_http_slice_module is compiled in and actually used; if not, remove it from the build to shrink attack surface.
  • Check both your edge NGINX fleet and any embedded copies — Ingress Controller, Gateway Fabric, App Protect WAF, Instance Manager — separately; they patch on their own release cadence and lag the core NGINX fix.

References