GHSA-2wm5-q62r-hmrv

Dashboard / Vulnerabilities / GHSA-2wm5-q62r-hmrv

GHSA-2wm5-q62r-hmrv

Summary: Colord: Slow rejection of oversized malformed color strings

Details: ### 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`.

References: https://github.com/omgovich/colord/security/advisories/GHSA-2wm5-q62r-hmrv, https://nvd.nist.gov/vuln/detail/CVE-2026-85062, https://github.com/omgovich/colord/pull/141, https://github.com/omgovich/colord/commit/87018089515ed66a85b1a95c3c7c3fd69a25bac2, https://github.com/omgovich/colord