Crafty Controller CVE-2026-90821

Exploitation requires (1) a valid authenticated Crafty Controller account with permission to reach and submit the Webhook URL form field (PR:L), and (2) a separate victim user subsequently viewing the page that renders the stored, unsanitized webhook value (UI:R) - the payload does not fire on the attacker's own action. The specific trigger is malicious input in the Webhook URL field that the application fails to neutralize before storage and rendering. Limiting factors: no anonymous/pre-auth path exists, the attacker cannot self-trigger impact, and real damage depends on a higher-privileged victim (e.g., an admin) loading the affected view, so deployments that restrict webhook configuration to trusted operators materially reduce exposure.

This is a genuinely moderate, not high-priority, issue. The CVSS 3.1 score of 5.4 (vector AV:N/AC:L/PR:L/UI:R/S:C/C:L/I:L/A:N) reflects a stored XSS that is network-reachable and low-complexity but requires an authenticated account (PR:L) and victim interaction (UI:R), with only Low confidentiality and integrity impact and no availability impact. The scope-changed flag (S:C) is the standard and appropriate treatment for stored XSS, since the injected script executes in another user's browser context. No EPSS score, CISA KEV listing, or public POC was provided in the input, so by the precision rules this is 'no public exploit identified at time of analysis.' The authentication requirement plus required user interaction meaningfully lowers real-world risk below what the 'network vector' alone suggests: an attacker must first obtain a valid Crafty Controller account and then induce a higher-privileged user (e.g., an admin viewing the webhook configuration) to render the stored payload. Missing data to note explicitly: no EPSS/KEV/POC signals and no SSVC decision data were supplied, so exploitation likelihood cannot be quantified; the single reference is a GitLab work item rather than a formal advisory with confirmed fixed versions.

A low-privileged but authenticated Crafty Controller user enters a malicious script payload into the Webhook URL form field, which the application stores without proper neutralization. When an administrator or other user later views the page rendering that webhook configuration, the script executes in their browser session, potentially enabling session/token theft or actions in the victim's context. No public exploit code was identified at time of analysis, and exploitation depends on the victim loading the affected view.