GHSA-wxhq-pm8v-cw75

What it actually does

Vulnerable clean-css versions use regular expressions that can exhibit catastrophic backtracking when minifying or parsing certain CSS. A single crafted stylesheet can pin a Node.js thread at 100% CPU, block the event loop, and stall all other work in that process until timeout or restart. The flaw is availability-only: it does not yield code execution, authentication bypass, or direct data disclosure.

Why it matters to the business

Build pipelines, asset CDNs, and any runtime that minifies CSS on the fly can hang, delaying releases or taking down user-facing features until processes are recycled. Impact is highest where untrusted or third-party stylesheets are processed. The advisory is from 2019, is not in CISA KEV, is not associated with ransomware, and has no published exploit maturity, so mass in-the-wild abuse is unlikely; leftover risk is mainly unmaintained npm trees still pinning clean-css below 4.1.11.

How an attack unfolds

An attacker who can influence CSS that reaches clean-css—via an upload, a user-controlled theme, a style injection, or a compromised upstream package—submits input that forces a vulnerable regular expression into catastrophic backtracking. The minifier never completes; the hosting Node.js process stops handling other requests and appears hung. The attacker repeats or parallelizes submissions to extend the outage. This path does not by itself steal data or implant malware.

How to fix it

Upgrade the npm package clean-css to 4.1.11 or later in every direct and transitive dependency (package.json and lockfile). Rebuild and redeploy so runtime node_modules no longer contains vulnerable copies. Where immediate upgrade is blocked, isolate CSS minification behind strict size/time limits and do not feed untrusted stylesheets to clean-css. Prefer a currently maintained clean-css major line rather than remaining on 4.1.x indefinitely.

How to confirm the fix worked

Run npm ls clean-css (and inspect package-lock.json/yarn.lock/pnpm-lock.yaml) and confirm every installed instance is 4.1.11 or newer. Search container images and build artifacts for nested node_modules/clean-css. After upgrade, process representative and oversized CSS fixtures under a CPU/time cap and confirm minification completes without event-loop stalls.

Typical attack path

1. Discover an application, CI job, or service that minifies CSS with clean-css older than 4.1.11
2. Obtain a channel to supply or inject stylesheet content into that minification path
3. Submit CSS crafted to trigger catastrophic regular-expression backtracking
4. Saturate CPU and block the Node.js event loop so legitimate minify and application traffic fail
5. Repeat or fan out requests to prolong denial of service until operators restart the process

How to detect it

There are no public in-the-wild campaigns or named threat actors for this 2019 ReDoS, and exploit maturity is none, so confirmed historical compromise is unlikely. Hunt for past availability incidents rather than malware artifacts: Node.js processes at sustained 100% CPU during CSS minify/build steps, minify HTTP endpoints with multi-minute durations or timeouts, worker restarts coinciding with stylesheet uploads, and application logs showing clean-css or css minification hanging then crashing. Review npm install history and lockfiles to see whether a vulnerable version was present at the time of any outage.

What your security team should do

• Inventory all applications and CI images for clean-css versions older than 4.1.11, including transitive installs
• Upgrade to clean-css 4.1.11 or later and commit refreshed lockfiles
• Fail builds that reintroduce vulnerable clean-css via dependency scanning
• Apply request size limits and hard timeouts around any runtime CSS minify path that accepts external input
• Treat leftover copies in abandoned services as availability debt and schedule removal or isolation