Fix version ranges for GHSA-mh99-v99m-4gvg (brace-expansion)

[andymai]

What this changes

GHSA-mh99-v99m-4gvg (CVE-2026-14257) currently declares a single range, introduced: 0 → fixed: 5.0.8. That was accurate when the advisory was published on 2026-07-24, when 5.0.8 was the only patched release.

The maintainer has since backported the fix to the 1.x, 2.x and 3.x maintenance lines. Those releases are not reflected in the range, so the advisory reports patched versions as affected.

This adds per-line fixed events:

Line	Last affected	First patched
1.x	1.1.16	1.1.17 (2026-07-29)
2.x	2.1.2	2.1.3 (2026-07-28)
3.x	3.0.2	3.0.3 (2026-07-27)
4.x	4.0.1	no patched release — rolls forward to 5.0.8
5.x	5.0.7	5.0.8 (2026-07-23)

The 4.x line has no backport, so it stays affected through to 5.0.8, preserving the current behaviour for those versions.

How the boundaries were determined

Each version was checked behaviourally with the advisory's own published proof of concept ('{a,b}'.repeat(1500)), run under a constrained heap (node --max-old-space-size=512), rather than by inspecting source for the EXPANSION_MAX_LENGTH marker:

1.1.16  FATAL ERROR: JavaScript heap out of memory
1.1.17  bounded — 2666 results
2.1.2   FATAL ERROR: JavaScript heap out of memory
2.1.3   bounded — 2666 results
3.0.2   FATAL ERROR: JavaScript heap out of memory
3.0.3   bounded — 2666 results
4.0.1   FATAL ERROR: JavaScript heap out of memory
5.0.7   FATAL ERROR: JavaScript heap out of memory
5.0.8   bounded — 2666 results

Testing behaviourally matters here: 1.1.16 and 2.1.2 do define an EXPANSION_MAX_LENGTH constant and reference the CVE in comments, but the bound is not effective — both still crash on the PoC. Only the later backports actually enforce it. A source-marker check would place the 1.x and 2.x boundaries one release too early.

Why it matters

minimatch@3 — still depended on by widely used packages such as eslint-plugin-jsx-a11y — pins brace-expansion: ^1.1.7 and calls it as a function. It cannot move to 5.x, whose CJS build exports { expand } rather than a callable. 1.1.17 is the correct remediation for that dependency tree, but the current range reports it as vulnerable, leaving consumers with a finding they cannot action.

database_specific.last_known_affected_version_range (<= 5.0.7) is left untouched, since that field appears to be generated.

[Copilot]

Pull request overview

Updates the brace-expansion advisory to recognize patched maintenance releases.

Changes:

• Adds fixed boundaries for versions 1.1.17, 2.1.3, and 3.0.3.
• Preserves vulnerability coverage for 4.x through 5.0.8.

---

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

[wisetara]

Arrived at the same five boundaries independently before spotting this PR, so consider this corroboration and some effort to save a verifier the digging:

Each backport is a self-identifying commit in juliangruber/brace-expansion:

line	backport commit	PR	first patched release
v1	cb4b9e47cc2e "fix: backport GHSA-mh99-v99m-4gvg"	#129	1.1.17 (5c57cc2519df, 2026-07-29)
v2	d13ff455a58b "fix: backport GHSA-mh99-v99m-4gvg"	#130	2.1.3 (878df3989e81, 2026-07-28)
v3	139d015104e7 "fix: backport GHSA-mh99-v99m-4gvg to v3"	#136	3.0.3 (e6d559e9b751, 2026-07-27)

Each lands immediately before its release commit, which confirms the fixed values in this diff from the source side. The v3 one is worth noting specifically: it precedes 3.0.3, so 3.0.3 is right even though the maintenance-v3 dist-tag points at 3.0.5 and would tempt a later boundary.

Also +1 on rolling 4.x forward to fixed: 5.0.8 rather than inventing a 4.x boundary. The repo has v1, v2, v3 and main branches only—no v4—and 4.0.1 predates the advisory, so that line genuinely has no patched release to point at.