GHSA-2wm5-q62r-hmrv Colord: Slow rejection of oversized malformed color strings

• npm colord: < 2.9.4 → fixed in 2.9.4

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`.