Security Advisory: Uncontrolled Recursion Depth in Tree Walkers Leads to Stack-Overflow DoS

[waydeshi]

Summary

braces 3.0.3 bounds only input character length (MAX_LENGTH = 10000), not brace nesting depth. Its recursive AST walkers use one stack frame per nesting level with no depth guard. A short, deeply-nested pattern under the character cap exhausts the call stack and throws RangeError: Maximum call stack size exceeded; uncaught, this terminates the Node process. Verified on Node v26.5.0 / braces@3.0.3: compile (the default braces() path) crashes at depth ≥ ~3500 and expand at ≥ ~4000, both within the 10,000-char cap.

• Component: braces
• Affected version: <= 3.0.3
• CWE: CWE-674 (Uncontrolled Recursion); CWE-400 (Uncontrolled Resource Consumption)
• Attack vector: Untrusted deeply-nested brace pattern from an unauthenticated caller

Description

parse() caps characters (lib/parse.js:37-39) but never nesting depth. Each nested { produces a brace node containing another brace node, and each output path walks the tree recursively:

// lib/compile.js:48-52 — default braces() path, no depth guard
if (node.nodes) {
  for (const child of node.nodes) {
    output += walk(child, node);   // one frame per nesting level
  }
}

The recursion is synchronous and driven purely by input depth. A few thousand nesting levels, far below the character cap, exceed the engine's stack limit. expand.js:102-104 shares the same recursion and crashes at depth ≥ ~4000. stringify.js:22-26 is structurally identical but does not overflow within the character cap (its lighter frames survive to the maximum depth of ~5000 the cap allows), so the exploitable sinks are compile and expand.

The README documents options.maxLength (default 10,000) only as a character guard, and its "Brace matching pitfalls" section covers only expansion output size. No depth bound is documented and there is no maxDepth option. These inputs stay under the character cap yet crash in default braces() compile mode, because the fault is in AST walk recursion. The library already validates malformed input via MAX_LENGTH; depth is the same class of guard, left incomplete.

Recommended Fix

• Enforce a maximum brace nesting depth in parse() (e.g. throw above ~100), analogous to the existing character cap. This bounds every downstream walker at the source.
• Optionally convert the walk/stringify recursion to an explicit iterative stack.
• Until a fixed release: set options.maxLength far below 10,000 and/or reject patterns whose { nesting exceeds a small bound before calling braces().

Reference

• CWE-674 (Uncontrolled Recursion); CWE-400 (Uncontrolled Resource Consumption)
• Related (distinct: token count vs. nesting depth): CVE-2024-4068 / GHSA-grv7-fg5c-xmjg

[waydeshi]

this is published as https://www.cve.org/CVERecord?id=CVE-2026-93687

[yanyu0517]

Any updates?

[moritzbednorz]

Any updates? +1

[sk1dcod3r]

++++++

[rformato]

Any updates? +1

[km5x2]

+++++

[andrewangelle]

++++++

[jonschlinkert]

Was this created by AI? This is complete nonsense.

1. To hit a nesting depth of 5,000 would require at least 10,001 characters. Setting maxLength to a value less than that is all that's needed, and is already supported.
2. For the same reason that you should not allow users to pass raw sql over http requests, you should not let users define regular expressions. If you are not letting users define regular expressions, then this CVE describes how you would attack yourself.
3. The maxDepth option might be a useful addition, but it will not solve this problem.

Why won't maxDepth solve the problem?

Because glob patterns are regular expressions:

• If a user writes !({a,b,c}{d,e,f}*), the regex engine has to build a Deterministic Finite Automaton (DFA) and invert its states to handle the negation.
• The state-space required to invert a non-deterministic loop can scale exponentially ((2^{n})).

No globbing library, including braces, can predict or cap how many internal states the regex compiler will allocate to resolve that negation without effectively writing a full DFA simulation engine. Please stop playing whack-a-mole with the unsolved generalized star height problem.

The point is that even if we implement this, despite the fact that it's absolutely already solved by maxLength, the researchers will pivot to some other contrived nonsense pattern no one would ever actually use, and if you're allowing users to pass globs, you have bigger issues.

The CVE is functionally equivalent to saying while (true) is a javascript vulnerability. It's not.