GHSA-mh99-v99m-4gvg (brace-expansion): flat `<= 5.0.7` range misses backported fixes in 1.x, 2.x and 3.x

Localiza el registro del aviso GHSA-mh99-v99m-4gvg en la base de datos de avisos y compara su rango vulnerable actual con los rangos por línea del issue. Usa la reproducción proporcionada con npm pack y grep para verificar las primeras versiones corregidas de cada línea mantenida. Se considera terminado cuando los metadatos representan por separado las líneas 1.x a 5.x, mantienen 4.x explícitamente como vulnerable y señalan cada línea afectada a la versión parcheada indicada o a que no hay ningún parche disponible.

Summary

GHSA-mh99-v99m-4gvg / CVE-2026-14257 declares a single flat vulnerable range for brace-expansion:

vulnerable_version_range:  <= 5.0.7
first_patched_version:     5.0.8

Because that range is a plain semver comparison, it sweeps in every older major line — but the maintainer backported this fix to the 1.x, 2.x and 3.x lines. Consumers legitimately pinned to a patched 1.x/2.x/3.x release are therefore reported as vulnerable when they are not.

Sibling advisories on this same package already express themselves per line, which is why this one reads like a data gap rather than intended scope — e.g. GHSA-3jxr-9vmj-r5cp lists 5.0.7 | 1.1.16 | 2.1.2, and GHSA-f886-m6hf-6m8v lists 5.0.5 | 3.0.2 | 2.0.3 | 1.1.13.

Evidence

The fix for this CVE is the EXPANSION_MAX_LENGTH bound (the pre-existing EXPANSION_MAX caps the number of expansions but not their total length). Published tarballs carry it, with an inline comment citing CVE-2026-14257 by name. Checked every maintained line:

Reproducible with:

for v in 1.1.15 1.1.16 2.1.1 2.1.2 3.0.2 3.0.3 4.0.1 5.0.7 5.0.8; do
  npm pack "brace-expansion@$v" --silent >/dev/null && tar -xzf "brace-expansion-$v.tgz"
  f=$(ls package/index.js package/dist/commonjs/index.js 2>/dev/null | head -1)
  printf '%-8s %s\n' "$v" "$(grep -c EXPANSION_MAX_LENGTH "$f")"
  rm -rf package
done

Suggested ranges

< 1.1.16                 -> 1.1.16
>= 2.0.0, < 2.1.2        -> 2.1.2
>= 3.0.0, < 3.0.3        -> 3.0.3
>= 4.0.0, <= 4.0.1       -> (no patched version available)
>= 5.0.0, <= 5.0.7       -> 5.0.8

Note the 4.x row separately: 4.0.1 is the latest 4.x and does not contain the fix, so 4.x has no upgrade path within its own line. The current flat range happens to flag 4.x correctly, but for the wrong reason, and a per-line rewrite should keep it flagged explicitly rather than by accident.

Why this matters in practice

The two shapes are not interchangeable for consumers. 1.x/2.x are CommonJS with a callable default export; 3.x and later are ESM with named exports. Tooling that does require('brace-expansion') — minimatch, and therefore ESLint — crashes with TypeError: expand is not a function when forced onto 5.x. So "just upgrade to 5.0.8" is not always available, and pinning to a genuinely patched 2.1.x is the correct remediation for those trees. With the current metadata that correct remediation is reported as unresolved, which pushes people toward either a breaking upgrade or dismissing a real advisory.