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

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. sid and forky share the same fixed upload. Debian tags trixie no-dsa — a minor issue that will land via the next point release rather than a dedicated security upload — while bookworm still needs its own security upload backporting the patch onto 1.22.1. Bullseye’s LTS support ended 2026-08-31 with no DLA ever issued for this CVE — the security tracker no longer lists the suite at all, and no fix is coming; a host still on bullseye 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: www/nginx follows the stable track, www/nginx-devel the mainline one. pkgsrc-current is the rolling tip; the quarterly stable branches inherit fixes by cherry-pick, and pkgsrc-2026Q2 is the current one.

Both packages build from an nginx-<version> distfile, but www/nginx-devel renames the package itself, so an installed mainline build reports as nginx-devel-<version> while the stable one reports as nginx-<version> — the identifiers in the tables above are what a host actually prints.

The identifier carries an nbN suffix when the package’s PKGREVISION is set. That revision bumps for many reasons besides security patches — recursive bumps for shared-library ABI changes, dependency and build-system tweaks — so an nbN suffix on its own says nothing about this CVE. Both packages carry PKGREVISION=1 on pkgsrc-current today for exactly such an unrelated reason: the fixed nginx-1.30.4nb1 took its nb1 from a recursive bump that predates the update, and the still-vulnerable nginx-devel-1.29.6nb1 carries the same suffix.

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.

Each channel row’s Fixed since is the date that channel actually published a release containing the fix, not the date this tracker noticed it.

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 match their channel pointers as of this update, 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.

Their Fixed since is the commit date of the version bump, not a channel release date: an ungated branch has the fix as soon as the commit lands. That also bounds every other row — no channel can be fixed before the branch it is cut from.

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. Separately, cyberstan has announced a full exploitation write-up and proof of concept for 21 days after the patch — early August 2026 — which is still outstanding.

Verification log

Upstream

• CVE-2026-42533 published 2026-07-15 by F5 (the CNA), alongside the fixed releases nginx 1.31.3 (mainline) and 1.30.4 (stable). Confirmed against the nginx security advisories page, which 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.
• The nginx CHANGES entry for 1.31.3 (15 Jul 2026) — identical to the 1.30.4 entry in CHANGES-1.30 — 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”, notes the similar issue with a non-cacheable variable in a string expression, and 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 present with 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 — and 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) published advisory 19/2026 on 2026-07-29. It reports that researchers have published proof-of-concept exploit code, states in its own voice that the code works on systems with ASLR enabled, and 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, published 2026-07-15 and 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. Beyond nginx itself it lists 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), with 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. A capture of the same article 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 nevertheless 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. The page is a JS-rendered SPA that returns nothing to a headless fetch, so these values come from PDF captures.
• Credit: F5’s acknowledgements name eighteen reporters, thanked for “independently bringing this issue to our attention” — counted from the capture. Collapsing the four AntAISecurityLab researchers into a single party gives fifteen; no reading of the list yields the sixteen this tracker previously carried, which was simply a miscount. 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 — the latter two being 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: 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; and 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. Checked against the upstream advisories page, CHANGES, the CNA record, and both F5 captures: none 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; the tracker records no separate testing-migration event for forky, so it carries the same date.
• Debian 13 (trixie): apt-installable version 1.26.3-3+deb13u7 (trixie-security), vulnerable. The tracker’s Notes field tags it no-dsa (“Minor issue; will be fixed via point release”), so no dedicated security upload is planned — the fix rides the next point release instead.
• Debian 12 (bookworm): apt-installable version 1.22.1-9+deb12u9 (bookworm-security), vulnerable.
• Debian 11 (bullseye): apt-installable version 1.18.0-6.1+deb11u8 (bullseye-security), vulnerable, frozen at that verdict — the Debian LTS schedule gives bullseye’s LTS window as 2024-08-15 to 2026-08-31, and the Debian security tracker no longer lists the suite at all as of this check, so no DLA is coming.
• pkgsrc-current: 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. First confirmed from the pkgsrc-changes commit mail while the pkgsrc git conversion was down for hardware reasons; the git clone now 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: nginx-1.30.3 and nginx-1.29.6, neither with a PKGREVISION nor a CVE patch, both vulnerable; the 1.30.4 update has not been pulled up to the quarterly branch. Read from the git clone, whose pkgsrc-2026Q2 ends at 2026-07-18.
• 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