CVE-2026-104844 in Selector Parser
Summary
by MITRE • 10/02/2026
PostCSS Selector Parser is a CSS selector parser that integrates with PostCSS but does not require it. Prior to 7.1.6, src/parser.js splitWord() can receive a flat selector as one word token carrying many class or ID indexes because period and hash characters are not tokenizer word delimiters. The uniqs() deduplication and per-index class and ID membership checks repeatedly scan the class and ID index arrays, while a separate Sass-interpolation filtering pass also performs repeated linear scanning. Together, these passes make parsing quadratic in the number of indexes and allow a crafted selector to occupy a synchronous parser thread. The maxNestingDepth guard does not mitigate the issue because the hostile selector can have zero nesting depth. Only consumers that synchronously parse untrusted selectors in an exposed request path are affected; ordinary build-time parsing of trusted sources is not affected. This issue is fixed in version 7.1.6.
If you want to get the best quality for vulnerability data then you always have to consider VulDB.
Analysis
by VulDB Data Team • 10/02/2026
The vulnerability identified as a ReDoS-like denial-of-service condition within PostCSS Selector Parser stems from inefficient algorithmic complexity in the core parsing logic, specifically affecting versions prior to 7.1.6. The root cause lies in the src/parser.js module where the splitWord function fails to properly delimit tokens based on period and hash characters, which are standard indicators for class and ID selectors in CSS syntax. Consequently, a maliciously crafted selector containing numerous class or ID references can be processed as a single flat token rather than being broken down into manageable segments during initial tokenization. This structural oversight forces the subsequent processing stages to handle an excessively large array of indexes within a single operation, setting the stage for performance degradation that scales poorly with input size.
The operational impact is driven by two distinct but compounding algorithmic flaws in the deduplication and filtering phases. First, the uniqs function responsible for removing duplicate selectors performs repeated linear scans across class and ID index arrays to ensure uniqueness. Second, a separate pass designed to filter Sass interpolations also executes linear scanning operations on these same data structures. When combined with the initial failure to tokenize properly, these quadratic time complexity operations mean that as the number of indexes in a selector increases, the processing time grows exponentially rather than linearly. This allows an attacker to craft a specific CSS selector string that consumes significant CPU resources and blocks the synchronous parser thread for an extended period, effectively causing a denial-of-service condition for any application relying on this library for real-time parsing tasks.
From a threat modeling perspective, this vulnerability aligns with CWE-400 Uncontrolled Resource Consumption, as the flaw allows an external actor to exhaust server-side computational resources through carefully constructed input. It also maps to ATT&CK technique T1496 Resource Hijacking, where attackers leverage system resources for disruptive purposes rather than data exfiltration or persistence. The severity of this issue is heavily dependent on the deployment context; it only affects consumers that synchronously parse untrusted CSS selectors within an exposed request path, such as a web server processing user-supplied stylesheets in real time. Ordinary build-time parsing scenarios involving trusted sources are not impacted because the input is controlled and does not originate from potentially hostile external actors seeking to exploit resource exhaustion.
Mitigation strategies must prioritize upgrading the PostCSS Selector Parser library to version 7.1.6 or later, where these algorithmic inefficiencies have been addressed through optimized tokenization and processing logic. For environments that cannot immediately upgrade due to dependency constraints, defensive coding practices should be implemented at the application layer. This includes enforcing strict length limits on incoming CSS selector strings before they are passed to the parser, implementing timeouts for synchronous parsing operations to prevent thread blocking, and validating input against a whitelist of allowed selectors where feasible. Additionally, moving from synchronous to asynchronous parsing models can help isolate the impact of such attacks, ensuring that resource-intensive processing does not block other critical application threads or requests.