fix: prevent stack overflow from deeply nested patterns (CVE-2026-93687) - #72

Any ETA on getting this merged and release?

Any ETA on getting this merged and release?

I sent an email to the developers that can approve, but no answer so far in the past 9 days.

+1 on this also, it's getting on to being 2 weeks+ on this

Downstream follow-up: our application is blocked by GHSA-vfj7-8cjw-p6xm through Tailwind and Next ESLint dependency paths. We independently validated a minimal depth-guard backport against the published 3.0.3 release suite (all 764 tests pass unchanged on Node 24), plus excessive string/direct-AST depth, 100/101 boundaries, malformed/escaped inputs and glob/watch consumer checks. We retained original advisory visibility rather than treating package renaming as remediation. Is there a plan or ETA for reviewing this PR and publishing an official patched release? A release would let downstream consumers retire any temporary maintained patch without a broad toolchain migration. Thanks.

While validating this fix, I found a fractional maxDepth boundary case in the parser: parse('{{a,b},c}', { maxDepth: 1.5 }) accepts two nesting levels. The parser checks nesting >= maxDepth before incrementing, while the guarded walkers compare the resulting depth against the limit.

I prepared a focused correction and regression tests for both braces and parentheses. It passes the full existing suite (900 tests). The contribution targets this PR's source branch: FSDevelop#1

The change is small and keeps the parser's documented numeric limit consistent with the recursive walkers. Please incorporate it into this security fix if you agree.

Thanks for this fix. I'm using it in a fork while it waits for review, and found one behaviour change in lib/stringify.js that isn't part of the depth limit.

The recursive call now passes the current node as parent:

output += stringify(child, node, child.nodes ? depth + 1 : depth);

Before, it passed no parent (stringify(child)), so parent defaulted to {}. With escapeInvalid: true, utils.isInvalidBrace(parent) now looks at a real parent, and valid nested braces come out escaped:

const braces = require('braces');
braces.stringify(braces.parse('{{a}}'), { escapeInvalid: true });
// 3.0.3:   '{{a}}'
// this PR: '\\{\\{a\\}\\}'

The same happens with '{a,{b}}', '{{x}y}', '{a,{b,{c}}' and '{}{a}'. Keeping the old parent while still threading the depth fixes it:

output += stringify(child, undefined, child.nodes ? depth + 1 : depth);

With that change, and a regression test for the five patterns above, the suite passes (900 tests) and the depth limit still stops the stack overflow. The commit is pillarsdotnet@31d783e, if you'd like to pick it up.

I evaluated the depth guards from PR #72 at d0d575e55e74a4e0218e5248fafb79efc3e54ebb for a downstream [email protected] dependency path. Sharing a compatibility observation and bounded test results to help review/release planning.

The PR also changes the recursive stringify call from passing no parent to passing node. With escapeInvalid: true, this changes existing output independently of the depth guard:

const braces = require('braces');
console.log(braces.stringify('{1..8}', { escapeInvalid: true }));
// Published 3.0.3: {1..8}
// PR HEAD: \{1..8\}

For a narrow 3.0.3 backport experiment, I applied only this PR's five lib/ diffs to the published 3.0.3 source and retained the old parent handling while forwarding depth:

output += stringify(child, {}, child.nodes ? depth + 1 : depth);

This is a local derivative, not an assertion that the unmodified PR passes these compatibility checks. On Node 22.20.0 / linux-amd64, with network disabled during tests:

• Released 3.0.3 test suite plus this PR's new security regression tests: 769 passing, zero failures (Mocha 11).
• 12,019 adversarial/comparison assertions passed: 2,000 deterministic shallow/malformed patterns compared against published behavior for compile/expand/stringify with and without escapeInvalid; rejection at string nesting depths 101, 1,000 and 4,998; 10,000-level direct AST guards; configured-depth limits.
• Representative micromatch and fast-glob normal patterns and guarded hostile patterns passed.
• Published compile stack exhaustion was reproduced. An expand stack-overflow expectation at depth 4,000 was not reproduced with that fixture, so I do not claim that particular reproduction succeeded.

The full upstream HEAD suite separately passed 899 tests, but HEAD includes unreleased parser behavior; that result is distinct from the narrow backport results above. Expansion cardinality, AST width and malformed parent cycles remain outside this depth-only evaluation. No application-wide compatibility or production deployment is claimed.

Could the parent-propagation behavior change be separated or explicitly covered/documented, and could a fixed release be published after review? A local patch still leaves downstream version-based audit findings unresolved while the installed package is identified as affected 3.0.3. We are preserving the audit gate rather than suppressing it.

https://blog.yossarian.net/2022/12/28/ReDoS-vulnerabilities-and-misaligned-incentives

预计何时能合并并发布？ 着急 赶紧发布