GHSA-2wm5-q62r-hmrv: Npm/colord vulnerability
Impact
colord's CSS color string matchers described a number as ([+-]?\d\.?\d+). In that form \d and \d+ can match the same digits, so a run of n digits can be divided between them in O(n²) ways, and rejecting an input retries every division. Parsing is synchronous and uninterruptible, so a long malformed color string blocks the thread:
| input | time to reject | | --- | --- | | 16 KB | 224 ms | | 64 KB | 4.4 s | | 128 KB | 18.5 s |
Reachable through colord() and getFormat(), and through any method that accepts a color string — including isEqual(), mix() and contrast(). The affected matchers are parseRgbaString and parseHslaString (built in) and parseHwbaString, parseLchaString, parseCmykaString (plugins).
Growth is polynomial, not exponential — multi-kilobyte payloads are required for a noticeable stall.
Who is affected
Applications that pass attacker-controlled strings of unbounded length to colord() — for example a server validating a color taken from a request body, JSON field, or uploaded stylesheet. colord applies no length limit before matching.
Typical client-side use with short input is not meaningfully affected.
Patches
Fixed in 2.9.4. The number is now written as ([+-]?(?:\d\.\d+|\d+)), which accepts exactly the same syntax but leaves only one way to match it, making rejection linear — 1 MB of input is rejected in ~5 ms.
Workarounds
Reject or truncate color strings longer than a sane limit (e.g. 100 characters) before passing them to colord.
Affected Software
Remediation
Recommended actions to resolve this vulnerability, in priority order.
- Upgrade
Upgrade
npm/colordto a version that resolves this vulnerability.Fixed in 2.9.4 - Upgrade
Upgrade to a fixed release to a version that resolves this vulnerability.
Fixed in 2.9.4 - Configuration
Add an explicit length limit for any attacker-controlled color strings passed to colord (before calling colord()). Reject or truncate inputs that exceed the limit to prevent synchronous uninterruptible parsing stalls.
colord color-string length limit = Reject or truncate color strings longer than a sane limit
Event History
Frequently Asked Questions
Which deployments are realistically exposed to a service disruption?
Server-side applications that pass attacker-controlled, unbounded color strings into colord are affected, such as services processing request bodies, JSON fields, or uploaded stylesheets. Typical client-side use with short inputs is not meaningfully affected.
What must an attacker provide to cause a noticeable stall?
The attacker needs to supply a long malformed color string, particularly one containing a long run of digits that the matcher must reject. The issue has polynomial growth rather than exponential growth, so multi-kilobyte payloads are needed for a noticeable delay.
Are calls other than colord() affected?
Yes. getFormat() and any method accepting a color string can reach the vulnerable parsing, including isEqual(), mix(), and contrast(). The built-in RGBA and HSLA matchers are affected, as are the HWBA, LCHA, and CMYKA plugin matchers.
Does colord limit input length before parsing?
No. colord applies no length limit before matching, so applications that accept unbounded external input need to account for input size before passing color strings to the library.