Dependabot: brace-expansion (GHSA-mh99-v99m-4gvg) cannot be resolved — no compatible patched release

[dannyhw]

Tracking issue for the brace-expansion Dependabot alert left open by #1410.

Update: upstream backports are landing. The 2.x half of this is fixable now; the 1.x half is still blocked. See Upstream tracking.

What we resolve

version	reached via	status
2.1.2	minimatch@8.0.7 ← glob@9.3.5 ← babel-plugin-module-resolver ← tests/metro-compat	fixable — 2.1.3 is out
1.1.16	minimatch@3.1.5 ← test-exclude@6 ← babel-plugin-istanbul ← jest 29	blocked — no patched 1.x yet

Why it wasn't resolved in #1410

At the time, 5.0.8 was the only patched release, and it is not API-compatible. It moved from a default export to a named one:

// 1.x / 2.x
module.exports = expandTop;

// 5.0.8
exports.expand = expand;   // plus __esModule: true, no `default`

Both consumers want the default — minimatch@3.1.5 does var expand = require('brace-expansion') and calls it directly; minimatch@8.0.7 does __importDefault(...) then .default(...), which is undefined under 5.0.8. So an override to ^5.0.8 breaks glob resolution across jest and the metro-compat suite. 5.0.8 also raises the floor to node: 20 || >=22.

Upgrading jest doesn't help: jest 30 pulls test-exclude@7 → minimatch@9 → brace-expansion@^2.0.1.

Upstream tracking

The maintainer confirmed the <=5.0.7 advisory range is correct — 1.1.16 and 2.1.2 ship the fix in the tarball but nothing can reach it through require('brace-expansion') (see juliangruber/brace-expansion#131, closed as not-a-bug with independent reproductions).

Crucially, the maintainer is doing shape-preserving in-place backports rather than repointing main, precisely because repointing would break minimatch@3.x/5.x/9.x:

PR	branch	status	result
#136	v3	merged 2026-07-27	3.0.5 published
#130	v2	merged 2026-07-28	2.1.3 published
#129	v1	still open	—

Verified 2.1.3 keeps the original shape:

$ npm view brace-expansion@2.1.3 main   → index.js   (no "type": "module", no exports map)
$ head -3 index.js                      → module.exports = expandTop;

It is a true drop-in and satisfies minimatch@8's ^2.0.1, so it needs no compatibility shim.

Also relevant: isaacs/minimatch#313 and #314 (both closed) — minimatch is not planning a change; the fix is expected to come from brace-expansion's own branches.

Impact on end users: none

brace-expansion is absent from the production dependency graph of every published package. Verified with pnpm why --prod brace-expansion in each of @callstack/repack, @callstack/repack-dev-server, @callstack/repack-init, @callstack/repack-plugin-expo-modules, @callstack/repack-plugin-nativewind, @callstack/repack-plugin-reanimated — all six return no match. It enters this repo only through our own dev tooling (jest and the metro-compat suite), so nobody installing a Re.Pack package pulls it in through us.

The advisory is a ReDoS in brace expansion of glob patterns. Even in our dev tooling the patterns come from our own config, not untrusted input.

Next steps

1. Now-ish: add an override to take the 2.x fix, which closes one of the two alerts:

   "brace-expansion@2": ^2.1.3

   Note this is currently blocked locally by a minimumReleaseAge cooldown — 2.1.3 was published 2026-07-28T10:16Z, so it becomes installable once it clears the configured window. Not worth bypassing the cooldown for a dev-only ReDoS.
2. Then: watch juliangruber/brace-expansion#129 for the 1.x backport. Once a patched 1.x publishes, a matching "brace-expansion@1" override clears the remaining alert and this issue can close.

[dannyhw]

resolved