Skip to content

Bound parser depth and validate supplied ASTs before recursive traversal - #88

Open
Corvette052 wants to merge 1 commit into
micromatch:masterfrom
Corvette052:fix/bounded-parser-ast-depth
Open

Corvette052 wants to merge 1 commit into
micromatch:masterfrom
Corvette052:fix/bounded-parser-ast-depth

Conversation

@Corvette052

Copy link
Copy Markdown

Addresses publicly disclosed GHSA-vfj7-8cjw-p6xm: GHSA-vfj7-8cjw-p6xm. Parser brace/parenthesis nesting is bounded at 128. Iterative depth/path validation precedes compile, expand and stringify, including supplied ASTs. Deep/cyclic inputs throw SyntaxError; shared acyclic nodes remain supported. Callers must handle validation errors. This does not address every expansion-resource hazard. Adds Mocha regressions for 12,000-level ASTs, cycles, 4,000-level patterns, ordinary ranges, 64-level nesting and shared nodes. Validation: npm install --ignore-scripts --no-package-lock; npm test: 899 passing on Node 24.19.0. No package version change. Maintainer feedback welcome on depth and error semantics.

@ulises-jeremias

Copy link
Copy Markdown

I independently reviewed and tested this head on Node 24.17. The suite passes (899 tests), but there is still a hang through the caller-supplied AST path: the preflight only validates nodes, while expand() follows parent pointers in while loops.

Reproducer (the nodes graph is acyclic):

const ast = { type: 'root', nodes: [] };
const paren = { type: 'paren', nodes: [{ type: 'text', value: 'x' }] };
ast.nodes.push(paren);
paren.parent = paren;
require('./lib/expand')(ast);

At this PR head (a795ee8) it does not terminate (I stopped it after 2 seconds). The same case on PR #87 (d44b9b1) rejects with RangeError: AST parent chain contains a cycle; that implementation also passes its 908 tests. Please validate parent chains (or guard queueOwner/the expand parent walks) and add this regression before relying on the AST preflight as a complete fix.

Gabriouss added a commit to Gabriouss/Grana. that referenced this pull request Oct 16, 2026
…audit de 14 para 0

Nenhum dos dois tem versao corrigida publicada (V-3, ordem de prioridade do autor, 15/10/2026).
- braces: GHSA-vfj7-8cjw-p6xm, estouro de pilha com chaves/parenteses aninhados. Correcao do
  PR micromatch/braces#88 (teto de 128 niveis no parse e percurso iterativo antes de compile,
  expand e stringify).
- node-forge: GHSA-86w9-cpqp-85rv, assinatura RSA PKCS#1 v1.5 forjada com lixo no
  DigestAlgorithm. Correcao do PR digitalbazaar/forge#1152 em lib/rsa.js.

Tarballs oficiais do npm (sha512 igual ao do lock anterior), ligados por file: + override,
mesmo padrao da decode-uri-component. Teste __tests__/vendor-braces-node-forge.cjs (no test:ci)
prova no pacote que micromatch e @expo/code-signing-certificates carregam: a entrada do
advisory nao reproduz, o uso normal continua igual; contraprova nos originais reproduz as duas.
Atencao: npm audit nao audita pacote file:, ver README-GRANA.md de cada pasta (quando apagar).

Prova num clone: npm ci, tsc, test:ci, expo export web, todos verdes; app abrindo no emulador
com o Metro carregando os vendors.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
robmclarty added a commit to robmclarty/fascicle that referenced this pull request Oct 16, 2026
braces 3.0.3 caps a pattern's length but not its nesting, and its
recursive walkers overflow the stack on a deep one: on Node 24,
braces.expand throws RangeError at a depth of 4990, inside the length cap
(GHSA-vfj7-8cjw-p6xm, high). No release fixes it, so pnpm carries
micromatch/braces#88 as a patch. The parser refuses nesting deeper than
128 and the walkers check depth before recursing, so such a pattern
throws a SyntaxError instead. braces reaches the tree only through
markdownlint-cli2's globbing, and ordinary globs match as before.

pnpm audit matches by version, so pnpm-workspace.yaml names the advisory
under audit.ignore, and `pnpm audit` passes. The security slot still
reads red, because checkride gates on the report's per-severity totals
and pnpm 11 keeps an ignored advisory in them (pnpm 12.4 leaves it out).
The slot stays explicit-only, and its note now says how an advisory with
no fixed release gets cleared.

TIL: under pnpm 11, audit.ignore drops an advisory from the report's advisory list but not from metadata.vulnerabilities, so a tool that gates on those per-severity totals still counts it
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants