GHSA-36jr-mh4h-2g58

What it actually does

d3-color versions before 3.1.0 parse CSS color strings (rgb, hsl, and related notations) with a regular expression that is subject to catastrophic backtracking. A crafted color string can cause the JavaScript regex engine to consume CPU for an unbounded time, blocking the Node.js event loop or freezing a browser tab. Impact is availability only: no code execution, data disclosure, or privilege change.

Why it matters to the business

Apps that accept untrusted color values (themes, charts, design tools, visualization APIs) can be made unresponsive by a single request. On Node.js, a blocked event loop stalls the whole process, producing timeouts, failed health checks, and SLO breaches. The issue is not in CISA KEV, has no reported in-the-wild exploitation, and has been public since September 2022; residual risk is mainly unpatched transitive d3 dependencies rather than active campaigns.

How an attack unfolds

An attacker finds a path where attacker-influenced text is passed to d3-color parsing APIs such as d3.color, rgb, or hsl. They submit a color-like string that forces exponential backtracking in the pre-3.1.0 parser. The process or UI thread spends excessive CPU matching the input and stops serving other work until timeout or restart. No credentials are needed if the color input is public. Exploit maturity is none and no named threat actors or ransomware campaigns are associated, so use is expected to be opportunistic denial of service.

How to fix it

Upgrade d3-color (npm) to 3.1.0 or later, which replaces the vulnerable regular expression. If d3-color is transitive (common via d3, d3-interpolate, and related packages), bump the parent so the lockfile resolves d3-color >= 3.1.0. Until then, allow-list and length-limit color inputs before they reach d3-color, and use request timeouts plus worker isolation so a hung parse cannot stall the entire process.

How to confirm the fix worked

Search package-lock.json, yarn.lock, and pnpm-lock.yaml for every d3-color entry and confirm the resolved version is 3.1.0 or higher. Run npm ls d3-color (or yarn/pnpm equivalent) in each workspace. After deploy, verify production node_modules or bundles no longer contain d3-color < 3.1.0. Recheck color-input endpoints under load to confirm they complete promptly.

Typical attack path

1. Identify an HTTP, WebSocket, or client-side input that is parsed as a CSS color by d3-color or a dependent d3 module
2. Confirm the resolved d3-color version is older than 3.1.0 via lockfiles, package metadata, or bundled source maps
3. Submit a crafted color string on that path to trigger regular-expression catastrophic backtracking
4. Repeat or parallelize requests to keep CPU saturated and the event loop or UI thread blocked
5. Target multiple workers or instances if needed to widen the outage

How to detect it

This is a CPU hang, not an implant, so artifacts are scarce. Correlate color, theme, or visualization endpoint requests with worker timeouts, 504s, or event-loop lag. On Node.js, look for sustained 100% CPU with stacks in regex execution inside d3-color, and APM spans of extreme duration on color parse. Client-side, browser hang reports around color pickers or d3 charts may apply. No associated actor TTPs; unexplained availability incidents on unpatched d3-color services after 2022-09-29 are the main retrospective signal.

What your security team should do

• Inventory lockfiles and bundles for d3-color below 3.1.0, including transitive d3 ecosystem packages
• Upgrade d3-color to 3.1.0 or later and ship the lockfile change as a priority patch
• Enforce allow-list format and maximum length on user- or partner-supplied color strings
• Apply request timeouts, worker isolation, and CPU/event-loop health checks on Node.js services that parse colors
• Watch for further d3-family advisories given wide downstream use of the package