[GHSA-mh99-v99m-4gvg] brace-expansion: DoS via unbounded expansion length causing an out-of-memory process crash

[G-Rath]

Updates

• Affected products
• References

Comments
Updated fixed versions due to backport

[github]

Hi there @juliangruber! A community member has suggested an improvement to your security advisory. If approved, this change will affect the global advisory listed at github.com/advisories. It will not affect the version listed in your project repository.

This change will be reviewed by our Security Curation Team. If you have thoughts or feedback, please share them in a comment here! If this PR has already been closed, you can start a new community contribution for this advisory

[Copilot]

Pull request overview

Updates the advisory to reflect the brace-expansion 3.x security backport.

Changes:

• Adds 3.0.3 as a fixed version.
• Adds the backport pull request reference.
• Updates advisory metadata.

Comments suppressed due to low confidence (1)

advisories/github-reviewed/2026/07/GHSA-mh99-v99m-4gvg/GHSA-mh99-v99m-4gvg.json:53

• This new range does not mark 3.0.3 as safe: affected entries are unioned, and the existing introduced: "0" / fixed: "5.0.8" range still includes 3.0.3. Make the ranges non-overlapping—for example, start the existing 5.x/4.x range at 4.0.0, while retaining this 0 → 3.0.3 range—so 3.0.3 is actually excluded and the unfixed 4.x line remains affected.

              "introduced": "0"
            },
            {
              "fixed": "3.0.3"

---

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

[github]

Hi there @juliangruber! A community member has suggested an improvement to your security advisory. If approved, this change will affect the global advisory listed at github.com/advisories. It will not affect the version listed in your project repository.

This change will be reviewed by our Security Curation Team. If you have thoughts or feedback, please share them in a comment here! If this PR has already been closed, you can start a new community contribution for this advisory

[kevcisme]

Thanks for filing this. One issue with the current diff: the first affected entry keeps "introduced": "3.0.0" alongside "fixed": "5.0.8". Since consumers union the affected entries for a package, that range subsumes the new [3.0.0, 3.0.3) entry, so the 3.x backports 3.0.3, 3.0.4 and 3.0.5 stay flagged.

Changing that first entry's introduced to 4.0.0 resolves it. The 4.x line has no patched release, so [4.0.0, 5.0.8) correctly covers 4.0.0, 4.0.1 and 5.0.2–5.0.7.

I verified first-patched-per-branch empirically, running the advisory's own PoC against the resolved entry point of every published version under node --max-old-space-size=512:

const mod = require('brace-expansion');
const expand = typeof mod === 'function' ? mod : mod.expand;
expand('{a,b}'.repeat(1500));

version	result
1.1.15, 1.1.16	fatal OOM
2.1.1, 2.1.2	fatal OOM
2.1.3	survives — 2666 results, ~250 ms
3.0.2	fatal OOM
3.0.3, 3.0.4, 3.0.5	survives
4.0.0, 4.0.1	fatal OOM
5.0.7	fatal OOM
5.0.8	survives

So: 1.x has no fix, 2.x is fixed in 2.1.3, 3.x in 3.0.3, 4.x has no fix, 5.x in 5.0.8. With introduced: 4.0.0 on the first entry the union is exact — every patched version clears and every vulnerable one is still caught.

One trap worth recording, because it makes 1.1.16 and 2.1.2 look patched when they are not: both ship a dist/commonjs/index.js that is byte-identical to the patched 5.0.8 build, but their package.json sets "main": "index.js" with no exports field. So require('brace-expansion') resolves to the root index.js, which is the legacy unpatched implementation, and the dist/ build is unreachable dead code. Diffing dist/ against 5.0.8 gives the wrong answer; only the PoC against the resolved entry point is reliable. The current <= 2.1.2 upper bound in this PR is correct.

[github]

Hi there @juliangruber! A community member has suggested an improvement to your security advisory. If approved, this change will affect the global advisory listed at github.com/advisories. It will not affect the version listed in your project repository.

This change will be reviewed by our Security Curation Team. If you have thoughts or feedback, please share them in a comment here! If this PR has already been closed, you can start a new community contribution for this advisory

[skrtheboss]

Since juliangruber/brace-expansion#129 has also been merged and released, we can now also add the fixed V1 version and match GHSA-mh99-v99m-4gvg

[ozgurkran]

The v1 backport is now published as brace-expansion 1.1.17, so the current third affected entry in this PR still needs to be split. As written, introduced 0 / fixed 2.1.3 continues to flag the patched 1.1.17 release.

The package owner advisory already reports:
patched_versions: 5.0.8, 3.0.3, 2.1.3, 1.1.17
vulnerable_version_range: <1.1.17, >=2.0.0 <2.1.3, >=3.0.0 <3.0.3, 4.0.0-5.0.7

The exact non-overlapping ecosystem ranges should therefore be:

• introduced 0; fixed 1.1.17
• introduced 2.0.0; fixed 2.1.3
• introduced 3.0.0; fixed 3.0.3
• introduced 4.0.0; fixed 5.0.8

Please also add juliangruber/brace-expansion#129 as the v1 backport reference. Release commit: juliangruber/brace-expansion@5c57cc2

This preserves every genuinely vulnerable branch while allowing scanners to clear all four patched maintenance lines.

[github]

Hi there @juliangruber! A community member has suggested an improvement to your security advisory. If approved, this change will affect the global advisory listed at github.com/advisories. It will not affect the version listed in your project repository.

This change will be reviewed by our Security Curation Team. If you have thoughts or feedback, please share them in a comment here! If this PR has already been closed, you can start a new community contribution for this advisory

[LordNikon1983]

Independent consumer verification: npm audit currently reports brace-expansion@1.1.17 as affected when it is installed through minimatch@3.1.5, even though the published 1.1.17 entry point contains the EXPANSION_MAX_LENGTH bound for CVE-2026-14257. The per-maintenance-line ranges in this PR are therefore needed to remove an actionable false positive without directing minimatch@3 consumers to the incompatible v5 export shape. I also confirmed the installed 2.1.3 backport contains the corresponding bound.