Repository navigation
Uncontrolled recursion in toString AST serialization — CVE-2026-9358 / SNYK-JS-POSTCSSSELECTORPARSER-16873882 #315
Description
Activity
Can we get some help on this , it is blocking for development work
Reacted by Michael HarwoodPR welcome to fix it
I've put up a fix for this in #316. Happy to iterate on the approach if you'd like it shaped differently.
Beyond the immediate patch, I wanted to raise the broader ownership question. This package sits deep in a lot of the postcss / CSS tooling ecosystem, so even moderate-severity issues like CVE-2026-9358 propagate widely the moment they hit advisory databases — and dormant repos with open CVEs are increasingly the soft targets of the current supply-chain attack wave (cf. postcss/postcss-url#185 recently).
For context: I'm a longtime contributor in this space (created cssnext, and a lot of other postcss plugins back in time), and I'm currently in the process of claiming/reclaiming maintenance on several inactive postcss plugins I created or contributed to, with @ai's agreement.
Given your other commitments across the JS tooling ecosystem, would you be open to me taking this package on as part of that effort? Either as an additional maintainer if you'd like to stay involved on direction, or taking it over entirely if you'd rather hand it off. Happy either way — and the patch above stands regardless of how that conversation lands.
@ai — looping you in per our discussion about taking on inactive postcss plugins.
I support the @MoOx in taking maintaince if @alexander-akait need a help
Reacted by Max T. and Juan JoséThanks @alexander-akait !
@arflenar-sep can you have a look to #316 ?
Can someone add me on the package https://www.npmjs.com/package/postcss-selector-parser as well ? Thanks ! (~moox)
@alexander-akait I agree. I added him to GitHub access of this repo. But seems like you need to add him at npm.
@MoOx Sent invite
Reacted by Max T.Thanks ! All good !
Thanks !
@adrianso Thanks for flagging the download numbers — that's useful context.
Before deciding on a 6.x back-patch, it's worth checking whether you're actually exposed, because in a Tailwind setup you almost certainly aren't.
What the vulnerability actually is: a denial-of-service. A pathologically deep selector (think thousands of nested
:not(...)/:is(...))makes the parser/serializer recurse deep enough to overflow the call stack. The only input that can trigger it is the selector string being parsed.Why a Tailwind user is almost certainly not at risk: Tailwind uses this library at build time, on your own, first-party CSS that you author. That input is trusted and never reaches those nesting depths. There's no untrusted, attacker-controlled selector reaching the parser, and a build step isn't a long-lived service a DoS would meaningfully harm. So in practice this is a non-issue for a standard Tailwind pipeline.
To make sure I'm not missing your case, a couple of questions:
- Are you ever feeding untrusted / user-supplied selector strings into postcss-selector-parser at runtime (e.g. a server that parses CSS coming from end users)? Or is it purely the Tailwind build step?
- Is this flagged because of a real exposure, or is it a scanner / compliance finding (Snyk, Dependabot, audit) you need to clear?
If you do have a genuine runtime exposure to untrusted selectors, tell me and I'll seriously consider a 6.x back-patch. I just don't want to maintain an extra release line unless someone actually needs it. Alternatively, you can check the PR fixing this and make a PR for a 6.x.x branch.
@MoOx It's flagged by the snyk scanner, in my case, I am required to comply to this as part of the PCI, which is an international standard that governs all websites credit cards.
I understand not wanting to maintain an old branch, but would humbly ask you to re-consider because lots of other users of this library would be in the same boat, and the download numbers for the 6.x.x branch would certainly lend some weight to that.
@adrianso Thanks for the context — PCI compliance is a fair and concrete reason, and you're right that the 6.x line carries most of the usage because Tailwind 3.4.x pins it. That's a strong enough case.
I back-patched the fix to the 6.x line and just created a 6.1.3 patch release. It's a small, self-contained change (a nesting-depth guard), so this is a one-off patch rather than a branch I'll be actively maintaining.
One important thing so this actually clears your scan: a published patch only makes Snyk/Dependabot go green if the advisory metadata is updated to mark the fixed version. So alongside the release I'll work on getting the GitHub/Snyk advisory updated to list the patched 6.x (and 7.x) versions — otherwise the scanner keeps flagging regardless of what you install.
Reacted by Adrian So- Reacted by Adrian SoReacted by Adrian So
Snyk has published advisory SNYK-JS-POSTCSSSELECTORPARSER-16873882 (CVE-2026-9358, medium severity) describing an uncontrolled-recursion flaw in the toString function of the AST serializer. The advisory marks all versions as affected and notes there is no fixed version available.
This is impacting downstream consumers (e.g. eslint-plugin-vue users) who currently have no remediation path other than ignoring the finding in their security tooling. Is there a planned patch release that adds a recursion-depth limit or otherwise mitigates this in toString?