CVE-2026-85062

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.