CVE-2026-42533 — nginx map/regex capture clobbering

This tracker is no longer updated. Every tracked distribution has shipped a fixed nginx for each release it still supports. The two rows left vulnerable will not flip: Debian 11 (bullseye) left Debian LTS on 2026-08-31 without a DLA, and pkgsrc-2026Q2 never received the mainline www/nginx-devel update — a host on either needs to move to a supported release or build from pkgsrc-current.

Summary

An unauthenticated remote attacker can corrupt the nginx worker’s heap by sending crafted HTTP requests, provided the running configuration uses a map with regex matching and includes that map’s variable in a string expression after a capture the map’s own match affects. Upstream reports a similar issue for a non-cacheable variable used in a string expression.

nginx evaluates a compiled expression in two passes: a LEN pass that measures the result, and a VALUE pass that writes it into the buffer the LEN pass sized. Evaluating the map runs its regex, which overwrites the request’s PCRE capture state. A capture referenced earlier in the same expression therefore resolves to different bytes in the two passes, and when the second resolution is longer than the first, the VALUE pass writes past the buffer the LEN pass sized — with contents and length drawn from request data.

Per the CNA record, the primary impact is a heap buffer overflow leading to a worker-process restart, and code execution “on systems with Address Space Layout Randomization (ASLR) disabled or when the attacker can bypass ASLR”. Both NGINX Open Source and NGINX Plus are affected; F5 classes it a data-plane issue with no control-plane exposure.

Regex support in map landed in nginx 0.9.6 (March 2011), so the bug has been reachable in shipped configurations for roughly fifteen years.

On the third-party research

This bug was found many times over: F5’s acknowledgements name eighteen reporters, and nginx’s changelog credits two of them. Two have since published material that goes well beyond the advisories, and both are on F5’s list — so these are coordinated reporters, not bystanders:

• Stan Shaw (cyberstan) — a detailed write-up describing a second primitive in which an undersized clobbered capture leaves uninitialised heap in the output, an ASLR bypass built on it (recovering a libc and a heap pointer from uninitialised pool metadata), end-to-end pre-authentication code execution, and thirteen affected call sites spanning both the HTTP and stream script engines.
• depthfirst — a report and proof of concept placing the overflow in the stream module’s script engine, reached by sending a long TLS SNI to a listener with ssl_preread on, and therefore firing “before TLS termination or authentication”. The report carries no byline; F5 acknowledges Zhenpeng (Leo) Lin of depthfirst as a reporter.

F5’s guidance has since moved toward one of cyberstan’s points without adopting it. Its mitigation now warns against reusing a named capture “in different directives. For example, in both a map directive and in a location block” — text F5 added quietly after the research went public (see the verification log). That is a rule about matching the same capture in two places, which is not quite cyberstan’s claim that the capture reference and the map variable need not share a directive. Read it as the vendor treating cross-directive use as hazardous rather than as confirmation of the trigger mechanic — enough to act on, not enough to call the mechanic vendor-stated.

The rest is unacknowledged by any vendor — which is no longer the same as unevidenced. The information leak, the ASLR bypass, and the stream trigger surface are all implemented in depthfirst’s published exploit, which leaks addresses from a stream listener and computes libc and heap bases from them. Demonstrated in running code, then, but absent from every vendor source: F5 names “the map directive with regex matching” as the vulnerable feature, the CNA record describes only the map and non-cacheable-variable paths and frames delivery as “crafted HTTP requests”, and nginx.org’s advisories name neither ngx_stream_script.c nor ssl_preread. F5 also still conditions code execution on ASLR being disabled or separately bypassed — a condition the public exploit sets out to satisfy. Treat these as researcher findings that the vendors have not yet caught up with, rather than as speculation.

That gap matters because it makes exposure wider than a version check or a reading of the advisories suggests: configuration shape decides reachability, and a stream {} block is a place many readers would never think to audit — so Detection covers both. The configuration scanner is covered there too.

Affected versions

Per the upstream advisory, which rates the issue major and gives the range as 0.9.6 through 1.31.2.

F5 additionally lists products that embed nginx — NGINX Instance Manager, F5 WAF for NGINX, NGINX App Protect WAF, NGINX Gateway Fabric, and NGINX Ingress Controller. They are outside this tracker’s scope, but worth naming because several of their branches have no fix available at all: App Protect WAF 4.x and 5.x, Gateway Fabric 1.x, and Ingress Controller 3.x and 4.x each show no fixed release, leaving an upgrade to a fixed branch as the only route. Check the F5 advisory directly if you run any of them.

The same 1.31.3 / 1.30.4 release also fixed CVE-2026-60005 (memory disclosure in ngx_http_slice_module) and CVE-2026-56434 (use-after-free in ngx_http_ssi_module), so a distribution’s update for this CVE will usually close all three at once.

Distribution status

Fix status depends on the package version and on whether the maintainer backported the upstream patch. A distribution can carry the fix as a -N Debian packaging revision, a patches/patch-* file (with a PKGREVISION bump) in pkgsrc, or an extraPatches entry in nixpkgs — so an older version string does not by itself mean vulnerable.

nginx ships two upstream tracks, and a distribution usually packages one, the other, or both as separate packages. Each track has its own fixed release, so each gets its own table below.

Stable track

Fixed at nginx 1.30.4 or later. This is the track Debian packages — Debian ships no mainline nginx, so it appears only here.

Debian versions are the apt-installable value: the <suite>-security archive where it exists, since that is what hosts run and where a DSA or DLA fix lands first.

Mainline track

Fixed at nginx 1.31.3 or later.

Debian

The Debian security tracker is the authoritative source for per-suite status. The trixie and bookworm packages behind DSA-6496-1 and DLA-4784-1 carry a backport of the patch onto older bases (1.26.3 and 1.22.1), so their version numbers sit below the fixed 1.30.4.

No fix is coming for bullseye — a host still on it needs to upgrade to a supported release.

pkgsrc

The pkgsrc tree (NetBSD’s package collection, also used on SmartOS, macOS via pkgin, and elsewhere) ships nginx in two packages, both built from an nginx-<version> distfile:

• www/nginx follows the stable track; an installed build reports as nginx-<version>.
• www/nginx-devel follows the mainline track and renames the package itself, so it reports as nginx-devel-<version>.

pkgsrc-current is the rolling tip; the quarterly stable branches inherit fixes by cherry-pick, and pkgsrc-2026Q2 was the current one when this tracker was archived (2026-09-18).

www/nginx-devel was never pulled up to pkgsrc-2026Q2. A host that runs the mainline package from that branch needs to build it from pkgsrc-current instead.

An nbN suffix means only that the package’s PKGREVISION is set. It bumps for many reasons besides security patches — recursive bumps for shared-library ABI changes, dependency and build-system tweaks — so on its own it says nothing about this CVE.

The fixed nginx-1.30.4nb1 on pkgsrc-current took its nb1 from such an unrelated recursive bump that predates the update. The pullup to pkgsrc-2026Q2 carried the version bump but not that earlier revision bump, so the same fix reports there as plain nginx-1.30.4.

NixOS

nixpkgs ships nginx as two attributes, nginxStable and nginxMainline, so a single channel appears in both tables above. A channel is fixed once its pinned version reaches the fixed upstream release or it carries the fix as an extraPatches backport on an older base. The 26.05 channels took the version bump, backported to the release-26.05 branch a day after it landed on master.

A channel row’s Fixed since is the date that channel first published the fix; for the master and release-26.05 branch rows it is the date of the fixing commit, since nothing publishes a branch.

Flake users

A flake input like github:NixOS/nixpkgs/nixos-unstable resolves to the git branch of that name, not to the channel — but the channel bot advances the branch to exactly the revision the channel publishes. All five branch tips matched their channel pointers when this tracker was archived (2026-09-18), so if your input follows a channel name, the matching channel row above answers for you.

Two branches have no channel gating them, and both carried the fix earlier — they are listed above as master and release-26.05:

• github:NixOS/nixpkgs/master — the fix’s first appearance anywhere in nixpkgs, the moment it is merged.
• github:NixOS/nixpkgs/release-26.05 — the ungated 26.05 branch, ahead of the nixos-26.05 channel by however long Hydra takes.

Detection

To check whether a running nginx is on a fixed build:

nginx -v 2>&1 | awk '{print $NF}' | sed 's,^nginx/,,'

• stable >= 1.30.4 ⇒ fixed.
• mainline >= 1.31.3 ⇒ fixed.
• Anything older ⇒ vulnerable, unless the distribution packager has backported the upstream patch (see the per-distribution notes above).

Configuration exposure

The binary version is only half the answer: the bug needs a map that does regex matching, with that map’s variable used in a string expression after a capture the map’s match affects. A configuration with no regex-matching map is not exposed even on a vulnerable binary — which is also why the CVSS attack complexity is rated high.

Audit for the ordering, not for a single directive. Look for regex captures from location, server_name, or rewrite being referenced ahead of a regex map variable in the same evaluation — and note that the two need not sit in the same directive, so reading directives in isolation can miss it. F5 points the same way, warning against reusing a named capture in “different directives. For example, in both a map directive and in a location block”.

Audit stream {} as well as http {}. Both researchers place a second, independent implementation of the same two-pass engine in the stream module — cyberstan enumerates ngx_stream_complex_value among its call sites, and depthfirst reaches it by sending a long TLS SNI to a listener with ssl_preread on, which fires before TLS termination. If that holds, a regex map feeding a complex value such as return or proxy_pass inside a stream block needs exactly the same ordering audit as an HTTP one, and a config reviewed only under http {} can still be exposed. No vendor advisory mentions the stream module, and F5’s description frames delivery as “crafted HTTP requests” — so this rests on the researchers and on depthfirst’s published exploit, which targets a stream listener, rather than on vendor confirmation.

Stan Shaw published a read-only configuration scanner that follows include directives, handles cross-directive triggering, and distinguishes exploitable ordering from safe ordering:

git clone https://github.com/0xCyberstan/CVE-2026-42533-Config-Scanner

Treat its verdict as a prioritisation aid, not a clean bill of health — a configuration change can re-expose the bug at any time on an unpatched binary.

Debian

A Debian-side backport keeps the upstream version and bumps the packaging revision instead (the -N suffix on unstable, +debXuY on the stable suites). Query the installed package version:

dpkg-query -W -f='${Version}\n' nginx

Cross-reference the version against the Debian rows in Distribution status → Stable track and, ultimately, against the Debian security tracker page.

pkgsrc

Query the installed stable-track package:

pkg_info -e nginx

For the mainline-track package:

pkg_info -e nginx-devel

The output is <pkgname>-<version> plus, if the Makefile sets PKGREVISION, the suffix nb<PKGREVISION> — for example nginx-1.30.4 or nginx-1.30.4nb1. Cross-reference against the pkgsrc rows in the two tables above.

NixOS

The nginx version in the system closure is the version = field in pkgs/servers/http/nginx/{stable,mainline}.nix at the channel revision the system was built from; there is no separate packaging-revision concept. Query the running build:

nginx -v 2>&1 | awk '{print $NF}' | sed 's,^nginx/,,'

…and cross-reference against the per-channel rows in the table for whichever attribute the host uses.

Mitigation

If you cannot update immediately:

• F5’s own guidance, quoted in full because the qualifiers carry the weight: “do not use unnamed captures. Use unique named captures instead and only use them in the same block with the regex match. Do not reuse unique named captures in regex match in different directives. For example, in both a map directive and in a location block.” Named captures ((?<name>…), referenced as $name) are not carried in the positional capture state the map match overwrites, so converting $1/$2 references removes the clobbering — but only if each name is unique and not reused in a regex match in another directive. A rename that reuses one name across directives is not a mitigation.
• Equivalently, remove the ordering: in any expression that uses a regex map variable, make sure no positional capture affected by that map is referenced before it — resolve such captures into an intermediate variable first, or drop the regex from the map where a literal or hostname match will do. Check across directives in the same evaluation, not just within one, and check stream {} blocks as well as http {}.
• Operational: keep ASLR enabled. On Linux /proc/sys/kernel/randomize_va_space should read 2; on NetBSD, sysctl -n security.pax.aslr.enabled should read 1. Both default to on across the tracked Debian, pkgsrc, and NixOS builds. It raises the cost of turning the overflow into execution, but do not count on it to hold the outcome down to a worker restart: NCSC-FI states the published exploit works on systems with ASLR enabled, and cyberstan claims a bypass from a single unauthenticated request. Keep it on as one layer, not as the answer.
• Defence in depth: put a WAF or rate limiter in front of the workers to slow the repeated requests an attacker needs in order to probe the heap and land the overflow.

Mitigation is not a fix — the missing capture-state save/restore is still there, and a later configuration change can re-expose it. Upgrade to a fixed nginx as soon as your distribution carries one.

Working exploit code is public, and it is not a crash demonstration: depthfirst’s proof of concept leaks heap and libc addresses from a stream listener, computes both base addresses to defeat ASLR, sprays forged pool-cleanup records, and executes a supplied command against a normally built nginx. CISA-ADP raised the NVD record’s exploitation status to poc on 2026-07-29. NCSC-FI reports no widespread exploitation so far, while assessing the risk as materially raised by the release. cyberstan’s own proof of concept followed on 2026-08-05, three weeks after the patch, alongside the full exploitation write-up: it offers a crash mode, an information-leak mode that recovers libc and heap pointers from a single request, and two code-execution modes — a general one the author rates at roughly two attempts in three, and a deterministic single-shot one against configurations the attacker controls.

Verification log

Upstream

• CVE-2026-42533 (via the nginx security advisories page):
  • Published 2026-07-15 by F5 (the CNA), alongside the fixed releases nginx 1.31.3 (mainline) and 1.30.4 (stable).
  • The advisories page lists the issue as “Buffer overflow when using map and regex”, severity major.
  • Not vulnerable: 1.31.3+ / 1.30.4+. Vulnerable: 0.9.6-1.31.2.
• nginx changelog (via CHANGES, and CHANGES-1.30):
  • The 1.31.3 entry (15 Jul 2026) is identical to the 1.30.4 entry in CHANGES-1.30.
  • It describes the heap buffer overflow in the worker process “when using the map directive with regex matching if the map variable was included in a string expression after a capture affected by this map”.
  • It notes the similar issue with a non-cacheable variable in a string expression.
  • It credits “Mufeed VH of Winfunc Research and Maxim Dounin”. This tracker follows that credit; the third-party write-up’s own claim of authorship is not corroborated upstream.
• Both fixed releases are dated 15 Jul 2026 and each carries three security fixes: this CVE plus CVE-2026-60005 and CVE-2026-56434. The two preceding nginx CVEs (CVE-2026-42055, CVE-2026-48142) were fixed one release earlier, in 1.31.2 / 1.30.3.
• NVD record (via NVD):
  • CVSS 3.1 8.1 (high) and CVSS 4.0 9.2 (critical), CWE-122.
  • Its description conditions code execution on ASLR being disabled or bypassed, and calls the issue data-plane only.
  • Last modified 2026-07-29 by CISA-ADP, which raised the SSVC exploitation decision point from none to poc.
  • The description is otherwise unchanged — no stream context, no information leak.
  • F5’s advisory remains its only reference, with nothing tagged Exploit and no link to either researcher.
• Not listed in CISA’s KEV catalogue; the poc value above is an SSVC decision point, which is a separate thing from KEV inclusion. EPSS scored 0.0083 (53.5th percentile), dated 2026-07-20, via the FIRST API — predating the exploit release, so it does not reflect it.
• NCSC-FI (National Cyber Security Centre Finland, part of Traficom; via advisory 19/2026):
  • Published 2026-07-29.
  • Reports that researchers have published proof-of-concept exploit code, and states in its own voice that the code works on systems with ASLR enabled.
  • Records that widespread exploitation has not been observed (“laajamittaista hyväksikäyttöä ei ole vielä havaittu”) while assessing the risk as materially raised.
  • Its NGINX Plus fixed versions (R36 P7, 37.0.3.1) and its affected-product list agree with the F5 advisory.
  • It links F5 K000162097, the cyberstan write-up, and depthfirst’s report and PoC.
• F5 advisory K000162097 (via PDF captures — the page is a JS-rendered SPA that returns nothing to a headless fetch):
  • Published 2026-07-15, last updated 2026-07-21, tracked by F5 as NPS-72 (NGINX).
  • Its description matches the changelog: the map’s regex capture variables referenced before the map output variable, or a non-cacheable variable in a string expression.
  • Impact is stated as denial of service or possible code execution, data plane only, no control plane exposure.
  • For NGINX Open Source it lists 1.31.2 and 1.30.0-1.30.3 vulnerable, fixed in 1.31.3 and 1.30.4 — narrower than nginx.org’s 0.9.6-1.31.2 because F5 enumerates only supported branches.
  • It names “the map directive with regex matching” as the vulnerable feature, and mentions neither the stream module nor an information leak.
  • Fixed products beyond nginx itself: NGINX Instance Manager (fixed 2.22.2), F5 WAF for NGINX (5.13.4), NGINX Gateway Fabric 2.x (2.6.7) and NGINX Ingress Controller 5.x (2026-lts-r4 / 5.5.3).
  • No fix available for App Protect WAF 4.x and 5.x, Gateway Fabric 1.x, and Ingress Controller 3.x and 4.x.
  • Its mitigation reads in full: “do not use unnamed captures. Use unique named captures instead and only use them in the same block with the regex match. Do not reuse unique named captures in regex match in different directives. For example, in both a map directive and in a location block.”
• F5 expanded that mitigation silently (via two PDF captures of the article):
  • A capture taken 2026-07-21 carries only the first two sentences — “Use named captures instead and only use them in the same block with the regex match” — with no “unique” and no cross-directive sentence.
  • Both captures show the same “Updated Date: Jul 21, 2026”, and the rest of the article, acknowledgements included, is identical.
  • So F5 broadened its guidance after the third-party research went public without bumping the revision date, and the article’s Updated Date cannot be used to detect changes — diff the text against a stored capture instead.
• Credit (via F5’s acknowledgements, counted from the capture):
  • Eighteen reporters, thanked for “independently bringing this issue to our attention”.
  • Collapsing the four AntAISecurityLab researchers into a single party gives fifteen.
  • Among them are Mufeed VH of Winfunc Research (whom the nginx changelog also credits, alongside Maxim Dounin), Stan Shaw of cyberstan, and Zhenpeng (Leo) Lin of depthfirst.
  • Shaw and Lin are the authors of the write-up and the report and PoC referenced above, so both are coordinated reporters rather than unrelated third parties.
• Cross-directive use is discouraged by F5 but the trigger mechanic is not vendor-stated. F5’s added sentence forbids reusing a named capture in regex matches in two directives; cyberstan’s claim is that the capture reference and the map variable need not share a directive. Adjacent, not the same proposition — the tracker keeps them distinct.
• Unacknowledged by any vendor source, but implemented in published exploit code (checked against the upstream advisories page, CHANGES, the CNA record, and both F5 captures):
  • The information-leak primitive, the ASLR bypass, and the stream-module trigger surface.
  • cyberstan reaches the stream engine by listing ngx_stream_complex_value among thirteen call sites.
  • depthfirst reaches it by way of ssl_preread, arriving independently.
  • depthfirst’s poc.py implements the leak-to-ASLR-defeat-to-RCE chain against a stream listener, with hardcoded libc and pool offsets and a forged pool-cleanup handler.
  • cyberstan’s own proof of concept, published 2026-08-05 with the full write-up the author had withheld for three weeks after the patch, implements the same leak-to-RCE chain in crash, leak, and two RCE modes.
  • Its README repeats the thirteen-call-site count and names both the HTTP and stream engines.
  • None of the vendor sources names the stream module, ngx_stream_script.c, or ssl_preread, and none mentions a memory disclosure or an ASLR bypass.
  • F5 and the CNA both frame delivery as “crafted HTTP requests”.
  • The thirteen-call-site count remains cyberstan’s alone.

Distributions

• Debian sid and forky: Debian security tracker lists both suites against a single nginx 1.30.4-3 upload, fixed. Upload first seen on snapshot.debian.org 2026-08-01, in sid; it migrated to forky on 2026-08-15, per snapshot.debian.org’s dists/testing source index.
• Debian 13 (trixie): Debian security tracker lists trixie-security against nginx 1.26.3-3+deb13u8, fixed via DSA-6496-1. Upload first seen on snapshot.debian.org 2026-09-12.
• Debian 12 (bookworm): Debian security tracker lists bookworm-security against nginx 1.22.1-9+deb12u10, fixed via DLA-4784-1. Upload first seen on snapshot.debian.org 2026-09-18.
• Debian 11 (bullseye) (via the Debian LTS schedule and the Debian security tracker):
  • apt-installable version 1.18.0-6.1+deb11u8 (bullseye-security), vulnerable, frozen at that verdict.
  • The LTS schedule gives bullseye’s LTS window as 2024-08-15 to 2026-08-31.
  • The security tracker no longer lists the suite at all, so no DLA is coming.
• pkgsrc-current (via the pkgsrc git clone):
  • www/nginx/Makefile was updated to DISTNAME=nginx-1.30.4 on 2026-07-21, keeping the pre-existing PKGREVISION=1, so the package reports as nginx-1.30.4nb1.
  • That update was first confirmed from the pkgsrc-changes commit mail while the pkgsrc git conversion was down for hardware reasons; the git clone agrees.
  • www/nginx-devel/Makefile was updated to DISTNAME=nginx-1.31.3 on 2026-08-13, dropping the prior PKGREVISION, so the package reports as nginx-devel-1.31.3 — fixed.
• pkgsrc-2026Q2 (via the pkgsrc git clone):
  • www/nginx/Makefile received the 1.30.4 update on 2026-08-01 as pullup ticket #7207, so the package reports as nginx-1.30.4 — fixed.
  • The pullup added the new DISTNAME line below the old one instead of replacing it; make keeps the last assignment, and distinfo carries the 1.30.4 checksums, so the branch builds 1.30.4 despite the leftover line.
  • www/nginx-devel stays at nginx-1.29.6 with neither a PKGREVISION nor a CVE patch — vulnerable, with no pullup requested.
• NixOS nixos-unstable: fixed since 2026-07-18, the date the channel first published a release containing the nixpkgs bump (release nixos-26.11pre1036777.61b7c44c4073); stable.nix pins 1.30.4 and mainline.nix pins 1.31.3.
• NixOS nixos-unstable-small: fixed since 2026-07-16 (release nixos-26.11pre1035822.e8d924d50a46); same pinned versions. The -small channel has a lighter test gate and led the other channels by up to two days.
• NixOS nixos-26.05: fixed since 2026-07-17 (release nixos-26.05.5449.293d6abedf04); the 1.30.4 / 1.31.3 bump was backported to the release-26.05 branch on 2026-07-16 rather than applied as an extraPatches entry.
• NixOS nixos-26.05-small: fixed since 2026-07-16 (release nixos-26.05.5116.73814047f34e); same backport as nixos-26.05.
• nixpkgs-unstable: fixed since 2026-07-17 (release nixpkgs-26.11pre1035929.59682e0069f0); same pinned versions.
• nixpkgs master: fixed since 2026-07-15, the commit date of the version bumps 94585324 (nginxStable: 1.30.3 -> 1.30.4) and 16d3d4fb (nginxMainline: 1.31.2 -> 1.31.3), which landed eleven seconds apart in the same pull request — the same day upstream released. An ungated branch, so no channel gating applies.
• nixpkgs release-26.05: fixed since 2026-07-16, the commit date of the backports 780f6631 and 235ce217 onto that branch. The nixos-26.05 channel published a release containing them the following day.
• The two ungated branches bound the channel dates: no channel row can predate the branch commit it derives from, which is the cross-check that the channel dates above are not stamped.
• NixOS security tracker (tracker.security.nixos.org) — the fix reached every tracked channel through the ordinary version bump and its 26.05 backport, not through the security tracker workflow.

References