GHSA-rj75-hqrm-r3gf: Medium severity npm/postcss-selector-parser vulnerability
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.
Affected Software
Remediation
Recommended actions to resolve this vulnerability, in priority order.
- Upgrade
Upgrade
npm/postcss-selector-parserto a version that resolves this vulnerability.Fixed in 7.1.6 - Upgrade
Upgrade to a fixed release to a version that resolves this vulnerability.
Fixed in 7.1.6 - Compensating control
Cap the size of selectors accepted from untrusted sources before parsing.
Event History
Frequently Asked Questions
Which deployments are realistically exposed to this denial-of-service issue?
Deployments are exposed only when they synchronously parse untrusted, attacker-supplied selectors in a request path, such as CSS sanitizers, CSS-in-JS services, or online playgrounds. Ordinary build-time parsing of trusted sources is not affected.
What input would an attacker need to supply?
An attacker would need to provide a flat selector with many repeated class or ID indexes, such as a long sequence using . or # delimiters. This causes quadratic parsing work while keeping nesting depth at zero.
Does the maxNestingDepth protection mitigate this issue?
No. The problematic selector has nesting depth 0, so the maxNestingDepth guard added in 7.1.3 does not protect against it.
What version fixes the issue?
The issue is fixed in version 7.1.6. The fix replaces the affected linear scans with Set membership tests, making parsing linear in the number of indexes without changing parsing behavior.