The nginx map regex vulnerability is not a regression

The nginx map regex vulnerability narrative going around is that CVE-2026-93479 is self-inflicted: that July's emergency fix for CVE-2026-42533 introduced a fresh overflow in the same code, and October's release cleaned up the mess. It is a good story, the narrow affected range seems to support it, and we repeated a version of it ourselves before checking.

It does not survive the changelog. The bug affects nginx 1.30.0, which shipped on 14 April 2026 — three months before the patch it is blamed on. A regression cannot predate its cause.

The nginx map regex vulnerability and its misleading range

Set the two CVEs side by side as nginx's advisories page lists them, and you can see where the inference comes from.

	CVE-2026-42533	CVE-2026-93479
Title	Buffer overflow when using map and regex	Buffer overflow in script evaluation
Severity	major	medium
Vulnerable	0.9.6–1.31.2	1.31.2–1.31.6, 1.30.0–1.30.5
Fixed in	1.31.3+, 1.30.4+	1.31.7+, 1.30.6+

Every other CVE in the October release sweeps back years — the alias overflow reaches 0.1.29. This one sits in a tight band that begins, on mainline, at exactly the release before the July fix. That shape is genuinely characteristic of a regression, and it is why the reading spread.

What nginx's changelog actually says

Four pieces of evidence, all from nginx's own CHANGES files, point the other way.

The description does not match. The 1.30.6 entry reads: "a buffer overflow might occur in a worker process while evaluating string expressions with variables, which affected the document root calculation and request logging in the http and stream modules (CVE-2026-93479)". No map. No regex. July's entry, by contrast, is explicitly about "the map directive with regex matching if the map variable was included in a string expression after a capture affected by this map".

The credits differ. CVE-2026-42533 thanks "Mufeed VH of Winfunc Research and Maxim Dounin". CVE-2026-93479 thanks "Matt Suiche of Tolmo Inc". Different researchers, found independently.

nginx flags its regressions, and did not flag this one. This is the strongest signal. nginx has a long-standing changelog convention of naming the release a bug came from, and it used it in this very release — for something else: "Bugfix: in binary compatibility with third-party modules using script codes; the bug had appeared in 1.30.4." The mainline equivalent in 1.31.4 reads "the bug had appeared in 1.31.3". Those are the July releases. So July's patch did cause a regression, nginx said so plainly, and it is a binary-compatibility break for third-party modules — not the CVE.

The dates rule it out. On the stable branch CVE-2026-93479 affects 1.30.0 through 1.30.5. The CVE-2026-42533 fix landed in 1.30.4 on 15 July 2026. Releases 1.30.0 (14 April), 1.30.1, 1.30.2 and 1.30.3 never contained the July patch and are still listed as vulnerable.

What probably happened

Here is the charitable and most likely explanation: two things in the same release both trace to the July patch and the same area of code — "script codes" — and they got merged into one story. One is a real, acknowledged regression with no security impact. The other is a security bug in string expression evaluation, found separately, in code that July's patch happened to touch.

We cannot tell you the two bugs are unrelated at the source level, because we have not read the commits, and "adjacent code, independent bugs" is a claim we are not in a position to make with confidence. What we can say is that nothing in the primary sources supports the causal claim, and three independent signals point against it. That is enough to stop repeating it.

Why this matters more than the CVE does

A medium-severity overflow requiring a specific config is not the interesting part. The interesting part is that a plausible causal story travelled further than a changelog anyone can read in two minutes, and the version ranges that seemed to confirm it actually refute it.

That is an ordinary failure mode in vulnerability triage, and it has a cost. "Their last patch broke something" changes how a team treats the next advisory — it is the argument someone makes for waiting out the first week of a patch cycle. Basing that on a misread is how a real exposure window gets justified. nginx's May 2026 rewrite-module bug, CVE-2026-42945, was reportedly exploited within days of disclosure, so the cost of a cautious week is not hypothetical.

The practical habit: when an affected range looks like it tells a story, check it against the release dates before you believe it. It takes two minutes and it is the same discipline as checking a patch number twice rather than trusting the summary.

What to actually do about CVE-2026-93479

The remediation is unchanged by any of this. Upgrade to 1.30.6 on stable or 1.31.8 on mainline — not the 1.31.7 the advisory names, which the download page has already superseded. The full set of five October CVEs, and the severity disagreement between nginx and F5, is in our walkthrough of the release.

For reachability, the changelog is more useful than the CVE title. "Document root calculation and request logging in the http and stream modules" tells you where to look: a root built from a variable, and a custom log_format carrying one. Reporting attributes two workarounds to F5 — use named captures, and use them only inside the block with the regex match — which is sound config hygiene regardless. Note that the stream module is in scope too, which the TLS-and-HTTP framing of most coverage skips.

If your regression testing currently cannot tell you whether a security patch changed behaviour elsewhere, that is the gap worth closing — because July's patch really did break something, just not the thing it is being blamed for.