npm · colord
Colord: Slow rejection of oversized malformed color strings
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.
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.
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.
Reject or truncate color strings longer than a sane limit (e.g. 100 characters) before passing them to colord.
Is your project exposed to this? Stateward checks every dependency on every pull request and flags it only if your code actually reaches it.
Check my repoSources: CISA KEV (public domain), OSV.dev & GitHub Advisory Database (CC-BY-4.0), FIRST EPSS, NVD/CWE (public domain). Served live from the Stateward advisory database.