[renovate]

This PR contains the following updates:

Package	Change	Age	Confidence
brace-expansion@<1.1.13	1.1.18 → 5.0.12

---

brace-expansion: DoS via exponential-time expansion of consecutive non-expanding {} groups

CVE-2026-13149 / GHSA-3jxr-9vmj-r5cp

More information

Details

Summary

brace-expansion's expand() exhibits exponential-time - O(2ⁿ) - behavior in the number of consecutive non-expanding {} groups. A short, all-ASCII input (~90 bytes/30 groups) blocks the calling thread for minutes; a slightly longer input hangs it effectively indefinitely. Because the dominant consumers run on Node's single-threaded event loop, one small input can fully stall a worker/process.

In expand_, post is computed unconditionally at the top of the function, before the early-return branches that don't use it:

const post = m.post.length ? expand_(m.post, max, false) : [''];   // always recurses
  ...
if (!isSequence && !isOptions) {
  if (m.post.match(/,(?!,).*\}/)) {
    str = m.pre + '{' + m.body + escClose + m.post;
    return expand_(str, max, true); // restart — `post` discarded
  }
  return [str];
}

For input like a{},{},…, the first {} is non-expanding, so control reaches the {a},b} rewrite branch - but expand_ has already recursed into post over the entire remaining tail, only to throw the result away.
Each level therefore spawns two recursive expansions over essentially the same remaining work: T(n) = 2·T(n−1) ⇒ O(2ⁿ).

The max option does not mitigate this: max only bounds the output-building loops; neither the post recursion nor the rewrite recursion consults it.

Measured on 5.0.6:

groups (n)	input bytes	time
20	60	130 ms
24	72	1.9 s
26	78	7.8 s
30 (PoC)	90	~2 min

Proof of concept

const { expand } = require('brace-expansion');
// 30 non-expanding groups, ~90 bytes — blocks for minutes:
expand('a{},{},{},{},{},{},{},{},{},{},{},{},{},{},{},{},{},{},{},{},{},{},{},{},{},{},{},{},{},{}');

Impact

Any application that passes attacker-influenced strings to brace-expansion.expand() - directly or transitively via minimatch/glob brace patterns - can be driven into a multi-minute-to-indefinite CPU hang by a tiny request, denying service on that thread/process.

Remediation

Upgrade to a patched release. The fix:

1. Defers computing post until after the early-return branches (and computes it locally in the $-suffix branch), so post is only expanded when a brace set actually expands and the value is used. This alone removes the exponential.
2. Converts the {a},b} rewrite from recursion to an in-function loop, so a long run of rewrites cannot grow the call stack.

Verified: the PoC drops from ~2 min to 0.55 ms, 5,000 groups complete in ~344 ms, and output is identical to 5.0.6 across a behavioral-equivalence suite (sequences, padding, $-prefix, a{},b}c, {},a}b, x{{a,b}}y, etc.). Post-fix complexity is ~O(n²) on this input class - acceptable for the security fix; a linear rewrite can be a non-urgent follow-up.

If immediate upgrade isn't possible, avoid passing untrusted input to expand() / glob brace patterns, or run such expansion under a timeout/worker.

Severity

• CVSS Score: 7.7 / 10 (High)
• Vector String: CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:N/VI:N/VA:H/SC:N/SI:N/SA:N/E:P/S:N/AU:Y/R:U/V:D/RE:M/U:Amber

References

• https://github.com/juliangruber/brace-expansion/security/advisories/GHSA-3jxr-9vmj-r5cp
• https://nvd.nist.gov/vuln/detail/CVE-2026-13149
• https://github.com/juliangruber/brace-expansion/pull/122
• https://github.com/juliangruber/brace-expansion/pull/123
• https://github.com/juliangruber/brace-expansion/commit/835d6be91201122d9adffb0c0c8c094189ace265
• https://github.com/juliangruber/brace-expansion/commit/c7e33ec13ac1a684c116720843ce24e208611754
• https://github.com/juliangruber/brace-expansion/commit/d74e63030c012e3b7ae81657b8d665619cd51b95
• https://github.com/juliangruber/brace-expansion/releases/tag/v1.1.16
• https://github.com/juliangruber/brace-expansion/releases/tag/v2.1.2
• https://github.com/juliangruber/brace-expansion/releases/tag/v5.0.7
• https://www.npmjs.com/package/brace-expansion
• https://github.com/advisories/GHSA-3jxr-9vmj-r5cp

This data is provided by the GitHub Advisory Database (CC-BY 4.0).

---

brace-expansion: Quadratic-time expansion of the {a},b} rewrite causes CPU denial of service

CVE-2026-102277 / GHSA-q2hr-2g5m-vwhr

More information

Details

Summary

Expanding {a},b}-shaped input takes time quadratic in the number of literal } characters, blocking the event loop.

Bash preserves a quirk where a brace group followed by a comma set still expands ({a},b}). The parser implements this by rewriting the string and restarting the scan. Each pass absorbs exactly one } and re-scans from the beginning, so n trailing braces cost n full passes.

Reproduction

const build = n => '{a}' + '}'.repeat(n) + ',z}'

for (const n of [8000, 16000, 32000, 64000, 128000]) {
  const t = Date.now()
  expand(build(n))
  console.log(n, Date.now() - t + 'ms')
}

n	input	time	results
8,000	8 KB	110 ms	2
16,000	16 KB	446 ms	2
32,000	32 KB	1.7 s	2
64,000	64 KB	6.9 s	2
128,000	128 KB	27.7 s	2

ms/n^2 is flat at ~1.7 and each doubling of n costs exactly 4.0x - quadratic. 128 KB of input blocks the event loop for nearly half a minute to produce two results.

Mechanism

Instrumenting the rewrite branch confirms it runs exactly n + 1 times, once per literal }, each re-scanning the whole string.

There is a second multiplier. The rewrite replaces the group's closing } with the internal escClose sentinel, which is '\0CLOSE' + Math.random() + '\0' - about 25 characters. The working string therefore grows by ~25 characters on every pass:

n	input length	final string length
1,000	1,006	26,006
8,000	8,006	208,006

So the input is inflated roughly 26x, and that factor multiplies both the quadratic constant and peak memory. This makes it partly a memory-pressure issue as well as a CPU one.

Why max and maxLength do not help

The cost is in parsing, before the result set exists. The payload yields 2 results regardless of size, so neither bound is ever reached.

Impact

An application passing an untrusted pattern to expand(), directly or through minimatch / glob, can have its event loop blocked for tens of seconds by a payload well under minimatch's 65,536-character cap. For a single-threaded Node server that is a full stall, not just a slow request.

Degraded availability rather than a crash - the process recovers once the expansion completes.

Affected versions

Verified affected on 1.1.18, 2.1.4, 3.0.6 and 5.0.9, all within a few percent of each other (~460-490 ms at n=16,000).

Patch

The rewrite loop gets an iteration bound. Past the cap the remaining string is treated as non-expanding and returned literally, consistent with the existing max / maxLength caps, which truncate rather than throw.

Note this bounds the number of passes, not the cost of each: worst-case work remains proportional to cap x input length. The cap is set low enough that the residual is bounded in practice, and far above what any realistic {a},b} input needs.

Severity note

Scored 5.3 Medium (A:L) for consistency with GHSA-3jxr-9vmj-r5cp, the other algorithmic-complexity advisory on this package (CWE-407), which uses the same vector. The stack-exhaustion advisories on this package score A:H because they crash the process outright; this one stalls it.

Severity

• CVSS Score: 5.3 / 10 (Medium)
• Vector String: CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:L

References

• https://github.com/juliangruber/brace-expansion/security/advisories/GHSA-q2hr-2g5m-vwhr
• https://nvd.nist.gov/vuln/detail/CVE-2026-102277
• https://github.com/juliangruber/brace-expansion/commit/33a5ef17b8d800bbfa8c52b14c39043b6aac1a96
• https://github.com/juliangruber/brace-expansion/commit/bdff773f98e5988616b7039cc9b508df5d640b22
• https://github.com/juliangruber/brace-expansion/commit/c55e67d8d8b1c56a2474afff15c2891166b2d364
• https://github.com/juliangruber/brace-expansion/commit/ffdfa3e3806bed17c0874b8f1439b084de354a7e
• https://github.com/advisories/GHSA-q2hr-2g5m-vwhr

This data is provided by the GitHub Advisory Database (CC-BY 4.0).

---

brace-expansion: DoS via uncontrolled recursion in parseCommaParts causing stack exhaustion

CVE-2026-102276 / GHSA-6j4f-fj2g-mc7p

More information

Details

Summary

parseCommaParts() can exhaust the native stack and crash the process. There are two distinct ways to trigger it, both reachable from a single untrusted pattern string.

This is the parsing-side counterpart to CVE-2026-14257 / GHSA-mh99-v99m-4gvg. That fix made expand_() iterative and documented a constant-stack-depth guarantee, but parseCommaParts() was left recursive, so the guarantee only held for one of the two parsing paths.

Vector 1 - unbounded recursion on post

parseCommaParts() recursed on the remainder of the string once per brace group:

const postParts = parseCommaParts(post)   // unbounded

A brace group containing many comma-separated groups drives one recursion level per group:

expand('{' + '{a},'.repeat(7000) + 'b}')
// RangeError: Maximum call stack size exceeded

About 7,300 repetitions - roughly 29 KB of input - is enough on Node 24; roughly 6,300 (25 KB) on Node 18. The threshold is identical on every affected release line.

Vector 2 - push.apply with an unbounded array

Even with the recursion removed, parseCommaParts() spread whole arrays into an argument list:

p.push.apply(p, postParts)
parts.push.apply(parts, p)

Function.prototype.apply places one argument per element on the stack, so a single large array overflows it. This needs no recursion depth at all - the following reaches a recursion depth of exactly 1:

expand('{{x},' + 'a,'.repeat(125000) + 'b}')
// RangeError: Maximum call stack size exceeded

Threshold is about 124,300 repetitions (~249 KB). This vector was not part of the original report; it was found while verifying the fix. A patch that only de-recurses but keeps push.apply leaves a working denial of service behind.

Why max and maxLength do not help

Both crashes happen during parsing, before any expansion. The payloads produce one result per group, so output size grows linearly with input and is never the limiter. expand(payload, { max: 1, maxLength: 1 }) still overflows.

Impact

Any application that passes an untrusted string to expand() - directly, or through minimatch / glob where it is a user-supplied glob pattern - can be crashed. In Node, a RangeError that the application does not catch terminates the process, so a server that globs user input is exposed to remote unauthenticated denial of service.

minimatch's own MAX_PATTERN_LENGTH cap (65,536) does not help against vector 1: the overflow threshold sits well below it. Confirmed on minimatch 10.2.6 - a 64,003-byte pattern passes the length check and overflows both minimatch.braceExpand() and new minimatch.Minimatch().

This is an availability-only issue. No code execution and no data exposure.

Not a regression

5.0.8 and 5.0.9 overflow at the same repetition count, so the gap predates the recent advisories; those fixes simply did not reach it. Verified affected on 1.1.18, 2.1.4, 3.0.6, 5.0.8 and 5.0.9, all at an identical threshold.

Patch

parseCommaParts() is rewritten as a loop that carries the partial part across chunks, and every array append uses an element-by-element loop rather than push.apply. The redundant if (!str) return [''] guard is dropped - the loop returns [''] for the empty string on its own.

Equivalence of the old and new implementations was checked by differential testing: exhaustive over every string of {, }, ,, a up to length 7 plus 300,000 random inputs - 322,000 cases, zero mismatches.

Severity note

Scored 7.5 High under CVSS 3.1 for consistency with the other availability advisories on this package (GHSA-mh99-v99m-4gvg, GHSA-rgw5-rvv9-x895), which use the same vector. The reporter self-assessed 6.9 Medium under CVSS 4.0 (CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:N/VI:N/VA:L/SC:N/SI:N/SA:N).

Credit

Reported by baeseungwon1010, with a working proof of concept and a proposed patch. Vector 2 was identified during maintainer verification.

Severity

• CVSS Score: 7.5 / 10 (High)
• Vector String: CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H

References

• https://github.com/juliangruber/brace-expansion/security/advisories/GHSA-6j4f-fj2g-mc7p
• https://nvd.nist.gov/vuln/detail/CVE-2026-102276
• https://github.com/juliangruber/brace-expansion/commit/0bcbfc0a5928c3073d48f42999d1ce4fc1c42fbc
• https://github.com/juliangruber/brace-expansion/commit/316359e6019c39b3254c8ba8e25dc586a480652c
• https://github.com/juliangruber/brace-expansion/commit/5171e681c0922b7ae8bfaf9a331e309107be6edc
• https://github.com/juliangruber/brace-expansion/commit/6735c94873ca570bcdd6a0690033bdd3126379d3
• https://github.com/advisories/GHSA-6j4f-fj2g-mc7p

This data is provided by the GitHub Advisory Database (CC-BY 4.0).

---

brace-expansion: DoS via uncontrolled recursion on nested brace groups causing stack exhaustion

CVE-2026-102278 / GHSA-qhr7-859c-m2p7

More information

Details

Summary

expand_() recurses once per level of brace nesting. Deeply nested input exhausts the native stack and crashes the process.

This is distinct from CVE-2026-14257 / GHSA-mh99-v99m-4gvg, which made the tail iterative (recursion on m.post, driven by how many groups are chained). Nesting depth drives a different recursion that the tail fix never touched, so the documented constant-stack-depth guarantee only ever covered chained input, not nested input.

It is also distinct from GHSA-6j4f-fj2g-mc7p, which fixed recursion in parseCommaParts(). Both payloads below still crash with that fix applied.

Two recursion sites

Comma members. Each alternative of a brace set is expanded by a recursive call, so nesting a set inside every alternative recurses once per level:

expand('{a,'.repeat(4000) + 'z' + '}'.repeat(4000))
// RangeError: Maximum call stack size exceeded

Crashes at depth 3,907 - about 15.6 KB of input.

Single set. A brace set whose body parses to a single part is expanded by a recursive call before being re-wrapped (x{{a,b}}y -> x{a}y x{b}y), which recurses once per nesting level:

expand('{'.repeat(3200) + 'a,b' + '}'.repeat(3200))
// RangeError: Maximum call stack size exceeded

Crashes at depth 3,125 - about 6.25 KB of input. This is the cheapest stack-exhaustion payload known against this package: roughly a quarter the input of GHSA-6j4f-fj2g-mc7p (29 KB), and about a tenth of minimatch's MAX_PATTERN_LENGTH (65,536).

Why max and maxLength do not help

Both crashes happen while recursing into sub-expansions, before the result set grows. The payloads produce almost no output - the single-set case yields 2 results - so neither bound is ever the limiter. expand(payload, { max: 1, maxLength: 1 }) still overflows.

Impact

Any application passing an untrusted string to expand(), directly or through minimatch / glob as a user-supplied glob pattern, can be crashed. In Node a RangeError the application does not catch terminates the process, so a server globbing user input is exposed to remote unauthenticated denial of service.

Availability only. No code execution, no data exposure.

Affected versions

Verified affected on 1.1.18, 2.1.4, 3.0.6 and 5.0.9, at near-identical depths on every line (single set: 3,125 on all four; comma members: 3,907-4,102). Not a regression from any recent fix - the gap predates them.

Patch

A maxDepth bound (default EXPANSION_MAX_DEPTH) is threaded through expand_(). Past the cap a group is treated as non-expanding and returned literally, which is how the parser already handles a group that cannot expand. This matches the existing max / maxLength caps, which truncate rather than throw, so expand() continues never to throw on any input.

The default sits far above any realistic nesting depth and well below the crash threshold.

Severity

• CVSS Score: 7.5 / 10 (High)
• Vector String: CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H

References

• https://github.com/juliangruber/brace-expansion/security/advisories/GHSA-qhr7-859c-m2p7
• https://nvd.nist.gov/vuln/detail/CVE-2026-102278
• https://github.com/juliangruber/brace-expansion/commit/1efee7c397c191da6287a78ec19512476a966a7b
• https://github.com/juliangruber/brace-expansion/commit/935d78f32f335b2ff76578e5c5e877d31ae9888c
• https://github.com/juliangruber/brace-expansion/commit/de84f144e9816f30e25fc8179e2e1249ab6df0db
• https://github.com/advisories/GHSA-qhr7-859c-m2p7

This data is provided by the GitHub Advisory Database (CC-BY 4.0).

---

Release Notes

juliangruber/brace-expansion (brace-expansion@<1.1.13)

v5.0.12

Compare Source

v5.0.11

Compare Source

v5.0.10

Compare Source

v5.0.9

Compare Source

v5.0.8

Compare Source

v5.0.7

Compare Source

v5.0.6

Compare Source

v5.0.5

Compare Source

v5.0.4

Compare Source

v5.0.3

Compare Source

v5.0.2

Compare Source

v4.0.1

Compare Source

• fmt 5a5cc17
• Fix potential ReDoS Vulnerability or Inefficient Regular Expression (#​65) 0b6a978

---

v4.0.0

Compare Source

• feat: use string replaces instead of splits (#​64) 278132b
• fmt dd72a59
• add tea.yaml 70e4c1b

As a precaution to not risk breaking anything with 278132b, this is a new semver major release

v3.0.9

Compare Source

v3.0.8

Compare Source

v3.0.7

Compare Source

v3.0.6

Compare Source

v3.0.5

Compare Source

v3.0.4

Compare Source

v3.0.3

Compare Source

v3.0.2

Compare Source

v3.0.1

Compare Source

• pkg: publish on tag 3.x 3059c07
• fmt 8229e6f
• Fix potential ReDoS Vulnerability or Inefficient Regular Expression (#​65) 15f9b3c

---

v3.0.0

Compare Source

• Switch to ES Modules and balanced-match 3.0.0 (#​62) c0360e8
• added jsdoc (#​55) 68c0e37
• node 16 is EOL 9e781e9
• add standard 3494c4d
• use const and let (#​57) dd5a4cb
• docs 6dad209
• remove test e3dd8ae
• ci: update node versions d23ede9
• docs: add @​lanodan to contributors 1eb3fa4
• docs 1e7c9cd
• switch from tape to test module (#​60) 2520537
• Bump minimist from 1.2.5 to 1.2.6 (#​59) 61a94f1
• Bump path-parse from 1.0.6 to 1.0.7 (#​51) dc741cf
• docs: add back ci badge 8ee5626
• Add github actions, remove travis. Closes #​52 (#​53) 5c8756a
• CI: Drop unused sudo: false Travis directive (#​50) 05978a7

v2.1.7

Compare Source

v2.1.6

Compare Source

v2.1.5

Compare Source

v2.1.4

Compare Source

v2.1.3

Compare Source

v2.1.2

Compare Source

v2.1.1

Compare Source

• Backport v5.0.6 change to v2 (#​109) c3a817c

---

v2.1.0

Compare Source

v2.0.3

Compare Source

v2.0.2

Compare Source

• pkg: publish on tag 2.x 14f1d91
• fmt ed7780a
• Fix potential ReDoS Vulnerability or Inefficient Regular Expression (#​65) 36603d5

---

v2.0.1

Compare Source

v2.0.0

Compare Source

v1.1.21

Compare Source

v1.1.20

Compare Source

v1.1.19

Compare Source

---

Configuration

📅 Schedule: (UTC)

• Branch creation
  • At any time (no schedule defined)
• Automerge
  • At any time (no schedule defined)

🚦 Automerge: Disabled by config. Please merge this manually once you are satisfied.

♻ Rebasing: Whenever PR is behind base branch, or you tick the rebase/retry checkbox.

🔕 Ignore: Close this PR and you won't be reminded about these updates again.

---

• If you want to rebase/retry this PR, check this box

---

This PR was generated by Mend Renovate. View the repository job log.

[alwaysmeticulous]

✅ Meticulous spotted 0 visual differences across 14 screens tested: view results.

Meticulous evaluated ~4 hours of user flows against your PR.

_{Expected differences? Click here. Last updated for commit f1786ba chore(deps): update dependency brace-expansion@<1.1.13 to v5 [security]. This comment will update as new commits are pushed.}