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 write-up

This bug was found many times over: F5 acknowledges sixteen parties for independently reporting it, and nginx’s changelog credits two of them by name. One reporter, Stan Shaw, published a detailed write-up that goes well beyond the advisories — a second primitive in which an undersized clobbered capture leaves uninitialised heap in the response, an ASLR bypass built on it, end-to-end pre-authentication code execution, thirteen affected call sites, and — importantly for auditing — that the capture reference and the map variable need not be in the same directive, only in the same evaluation.

Their place among F5’s acknowledged reporters is confirmed; those technical specifics are not. Neither the upstream advisory, the changelog, nor the CNA record mentions an information leak or an ASLR bypass, and F5 conditions code execution on ASLR being disabled or separately bypassed — so this tracker reports the write-up’s extras as claims rather than facts. Two of its points are worth acting on regardless, because both make exposure wider than a version check suggests: configuration shape decides reachability, and the trigger can straddle directives. Its configuration scanner is covered under Detection.

Affected versions

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

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, and every tracked suite is still open there. The fix has not reached unstable, so nothing is queued for testing or for the stable suites either; trixie, bookworm, and bullseye each need their own security upload backporting the patch onto 1.26.3, 1.22.1, and 1.18.0 respectively.

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.

The write-up’s author 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: “do not use unnamed captures. Use named captures instead and only use them in the same block with the regex match.” 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 the bug depends on.
• 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.
• 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. F5 conditions code execution on ASLR being disabled or bypassed, so leaving it on is what keeps the expected outcome a worker restart rather than execution — it is a barrier, not a guarantee.
• 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. The write-up’s author has announced a full exploitation write-up and proof of concept for roughly three weeks after the patch, which puts them in early August 2026.

Verification log

Last verified 2026-07-22.

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.
• Not listed in CISA’s KEV catalogue. EPSS scored 0.0083 (53.5th percentile), dated 2026-07-20, via the FIRST API.
• 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. The advisory’s own mitigation is to use named captures instead of unnamed ones, and only in the same block as the regex match. The page is a JS-rendered SPA that returns nothing to a headless fetch; these values were read from a PDF capture of it.
• Credit: F5 acknowledges sixteen parties for independently reporting the issue, among them Mufeed VH of Winfunc Research (whom the nginx changelog also credits, alongside Maxim Dounin) and Stan Shaw of cyberstan, whose write-up is referenced above.
• The write-up is the sole source for the information-leak primitive, the ASLR bypass, the thirteen call sites, and cross-directive triggering. None of that appears in the upstream advisory, CHANGES, or the CNA record, so it is recorded as an unverified claim.

Distributions

• Debian sid: Debian security tracker lists nginx 1.30.1-7 as vulnerable; no upload closing the CVE yet.
• Debian forky: 1.30.1-7, vulnerable — inherits sid through the usual testing migration.
• Debian 13 (trixie): apt-installable version 1.26.3-3+deb13u7 (trixie-security), vulnerable.
• 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; a fix would arrive as a DLA from the Debian LTS team.
• 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. Read from the pkgsrc-changes commit mail rather than the usual git clone: the pkgsrc git conversion is down for hardware reasons and its trunk still ends at 2026-07-19. www/nginx-devel/Makefile pins DISTNAME=nginx-1.29.6 with PKGREVISION=1, and its patches/ directory carries no CVE-2026-42533 backport — only the long-standing patch-auto_cc_conf, patch-auto_install, patch-conf_nginx.conf and the brotli extra-patch — so the mainline package is vulnerable.
• 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