GHSA-2WM5-Q62R-HMRV
Vulnerability from github – Published: 2026-09-08 20:51 – Updated: 2026-09-08 20:51Impact
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": [
{
"package": {
"ecosystem": "npm",
"name": "colord"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "2.9.4"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2026-85062"
],
"database_specific": {
"cwe_ids": [
"CWE-1333"
],
"github_reviewed": true,
"github_reviewed_at": "2026-09-08T20:51:57Z",
"nvd_published_at": "2026-09-03T21:17:23Z",
"severity": "MODERATE"
},
"details": "### Impact\n\n`colord`\u0027s 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\u00b2) ways, and rejecting an input retries every division. Parsing is synchronous and uninterruptible, so a long malformed color string blocks the thread:\n\n| input | time to reject |\n| --- | --- |\n| 16 KB | 224 ms |\n| 64 KB | 4.4 s |\n| 128 KB | 18.5 s |\n\nReachable through `colord()` and `getFormat()`, and through any method that accepts a color string \u2014 including `isEqual()`, `mix()` and `contrast()`. The affected matchers are `parseRgbaString` and `parseHslaString` (built in) and `parseHwbaString`, `parseLchaString`, `parseCmykaString` (plugins).\n\nGrowth is polynomial, not exponential \u2014 multi-kilobyte payloads are required for a noticeable stall.\n\n### Who is affected\n\nApplications that pass attacker-controlled strings of unbounded length to `colord()` \u2014 for example a server validating a color taken from a request body, JSON field, or uploaded stylesheet. `colord` applies no length limit before matching.\n\nTypical client-side use with short input is not meaningfully affected.\n\n### Patches\n\nFixed 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 \u2014 1 MB of input is rejected in ~5 ms.\n\n### Workarounds\n\nReject or truncate color strings longer than a sane limit (e.g. 100 characters) before passing them to `colord`.",
"id": "GHSA-2wm5-q62r-hmrv",
"modified": "2026-09-08T20:51:57Z",
"published": "2026-09-08T20:51:57Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/omgovich/colord/security/advisories/GHSA-2wm5-q62r-hmrv"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-85062"
},
{
"type": "WEB",
"url": "https://github.com/omgovich/colord/pull/141"
},
{
"type": "WEB",
"url": "https://github.com/omgovich/colord/commit/87018089515ed66a85b1a95c3c7c3fd69a25bac2"
},
{
"type": "PACKAGE",
"url": "https://github.com/omgovich/colord"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:N/VI:N/VA:L/SC:N/SI:N/SA:N",
"type": "CVSS_V4"
}
],
"summary": "Colord: Slow rejection of oversized malformed color strings"
}
Sightings
| Author | Source | Type | Date | Other |
|---|
Nomenclature
- Seen: The vulnerability was mentioned, discussed, or observed by the user.
- Confirmed: The vulnerability has been validated from an analyst's perspective.
- Published Proof of Concept: A public proof of concept is available for this vulnerability.
- Exploited: The vulnerability was observed as exploited by the user who reported the sighting.
- Patched: The vulnerability was observed as successfully patched by the user who reported the sighting.
- Not exploited: The vulnerability was not observed as exploited by the user who reported the sighting.
- Not confirmed: The user expressed doubt about the validity of the vulnerability.
- Not patched: The vulnerability was not observed as successfully patched by the user who reported the sighting.
The approach is described in our paper Mapping CVEs to MITRE ATT&CK Techniques: A Curated Gold-Set Classifier and the Limits of LLM-Assisted Label Expansion.
Browse all ATT&CK techniques and the vulnerabilities related to each.
Related by attack behaviour
Vulnerabilities whose description is nearest to this one in the vector space of the CIRCL/vulnerability-attack-technique-biencoder model. This is a similarity search over the bi-encoder space (plain cosine), not a classification, and it has no measured accuracy.