Roundcube Webmail EUVD-2026-60166

The attacker must hold a low-privileged authenticated account on the target Roundcube instance (confirmed by PR:L in the CVSS vector), sufficient to send or present a contact entry containing a malicious payload. The victim must explicitly perform the 'Add to address book' action on a contact controlled or influenced by the attacker (UI:R per CVSS vector). The vulnerability is scoped specifically to the 'Add to address book' workflow - users who never trigger this action are not exposed via this vector. No non-default configuration is required; this is standard Roundcube functionality active in default deployments. Exploitation is further limited to instances running versions prior to 1.6.18 or 1.7.3. In open-registration or ISP-hosted deployments, the PR:L prerequisite is trivially met; in tightly controlled enterprise deployments with known user bases, the attacker pool is substantially narrowed.

The CVSS 5.4 Medium score is reasonable but understates practical webmail risk. The PR:L constraint (low-privileged authenticated attacker) is the primary limiting factor, requiring the attacker to hold a valid account on the same Roundcube instance. However, in shared hosting, ISP, or open-registration webmail deployments, this prerequisite is trivially satisfied. The UI:R constraint (victim must perform the 'Add to address book' action) is a realistic user behavior in webmail contexts, not a significant barrier. The S:C scope change elevates real-world impact: a successful exploit yields persistent script execution in the victim's browser, enabling session token theft, email exfiltration, or further actions under the victim's identity. No EPSS score was provided, so exploitation probability cannot be quantified from data. The absence of a KEV listing and no confirmed POC suggest opportunistic exploitation has not been observed at scale, but the vulnerability class (stored XSS in mainstream webmail) is well understood by attackers. This should be treated as a genuine remediation priority, particularly for shared or ISP-hosted Roundcube deployments.

An attacker with a low-privileged Roundcube account sends an email whose sender display name or contact field embeds a crafted XSS payload. When a victim user selects 'Add to address book' for that sender, the unsanitized payload is stored in the address book and executes in the victim's browser on subsequent loads, enabling the attacker to exfiltrate the victim's session cookie and hijack their mail session without any further interaction. No public exploit code is required given the well-understood mechanics of stored XSS.