PostCSS: Quadratic complexity in flat selector parsing allows CPU exhaustion

Impact

. and # are not word delimiters in the tokenizer, so a flat selector such as .a.a.a... reaches splitWord() as a single word token carrying n class or id indexes. Three passes scanned those index arrays linearly for every index, making the parse O(n^2) in the number of indexes rather than in input length: uniqs(), the indices.forEach loop, and the Sass-interpolation filter. Parsing a 400 KB flat selector took ~34 s on a modern laptop, fully occupying a single thread. A benign selector of identical byte size parses in tens of milliseconds, so the cost is driven by the index count, not the input size. The nesting depth of such a selector is 0, so the maxNestingDepth guard added in 7.1.3 offers no protection.

Reachability is deployment dependent. Only consumers that parse untrusted, attacker-supplied selectors synchronously in a request path are exposed, for example CSS sanitizers, CSS-in-JS services and online playgrounds. Ordinary build-time use on trusted sources is not affected.

Patches

Fixed in 7.1.6. The three passes now use Set membership tests, making parsing linear in the number of indexes. There is no behaviour change: parsing is byte-identical on a differential corpus of 8413 selectors.

Workarounds

Cap the size of selectors accepted from untrusted sources before parsing.