ApostropheCMS EUVD-2026-105154

Requires an authenticated user holding edit rights on content that uses a color field - specifically, per the vendor changeset, a widget style color field rendered inline (no selector) whose value is written into the wrapper's style attribute. The attacker crafts a value beginning with a valid rgb()/hsl() color prefix and appends arbitrary HTML, exploiting that TinyColor validation only requires a valid color substring rather than a full match. Exploitation is LIMITED by: (1) the need for a valid authenticated account with content-edit privileges (PR:L), (2) the requirement that a victim subsequently render/view the stored value (UI:R), and (3) the project defining and inline-rendering such a free-form color/style field. Payload execution occurs in the victim's browser on versions prior to 4.34.0.

This is a moderate-severity stored XSS (CWE-79) with a self-consistent CVSS:3.1/AV:N/AC:L/PR:L/UI:R/S:C/C:L/I:L/A:N vector scoring 5.4. The signals point to a real but low-urgency issue rather than a mass-exploitation priority. PR:L confirms an attacker must already hold an authenticated account with content-edit rights, and UI:R means a victim must subsequently render/view the poisoned content, both of which sharply narrow the exploit population to insiders or compromised editor accounts. S:C and C:L/I:L reflect classic XSS browser-context impact (session/UI manipulation) rather than direct server compromise, and A:N confirms no availability effect. There is no KEV listing, no public POC referenced, and no EPSS score supplied, so exploitation probability cannot be quantified from the input but all available evidence indicates no known exploitation. No key signals conflict with each other; the main data gap is the absence of EPSS/KEV/POC telemetry, which is consistent with a recently patched, privilege-gated CMS flaw rather than evidence of safety.

A low-privileged but authenticated ApostropheCMS editor edits a widget that exposes an inline-rendered color (style) field and submits a value like a valid rgb() or hsl() prefix followed by trailing HTML attribute/markup content, which the lax TinyColor validation accepts and stores. When another user - such as a site visitor or admin - loads the published page, the stored payload reaches the wrapper's style attribute and executes in their browser, yielding stored XSS. No public exploit code was identified at time of analysis.