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

Xác định bản ghi advisory GHSA-mh99-v99m-4gvg trong cơ sở dữ liệu advisory và so sánh phạm vi dễ bị tấn công hiện tại của bản ghi với các phạm vi theo từng dòng trong issue. Sử dụng bản tái hiện npm pack và grep được cung cấp để xác minh các phiên bản đầu tiên đã được sửa cho từng dòng còn được duy trì. Được xem là hoàn tất khi metadata biểu diễn riêng các dòng từ 1.x đến 5.x, giữ 4.x rõ ràng là dễ bị tấn công và trỏ mỗi dòng bị ảnh hưởng đến phiên bản đã vá được nêu hoặc cho biết không có bản vá khả dụng.

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.