Roundcube Webmail EUVD-2026-107809

Exploitation requires the attacker to deliver an email whose subject contains CRLF sequences to a Roundcube Webmail user running a version before 1.6.20 or 1.7.x before 1.7.5, AND requires that victim to subsequently forward the received message using the 'forward as attachment' compose feature - it is this feature that copies the subject verbatim into the generated attachment (MIME part) name. Limiting factors: the attack cannot succeed without the specific victim-initiated forward-as-attachment action (effective user interaction not reflected in the input UI:N), it is confined to MIME part header injection with only a low integrity impact, and it yields no confidentiality or availability loss and no code execution.

This is a genuinely low-to-moderate priority issue despite the scope-change in the vector. The input CVSS 4.0 (CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:C/C:N/I:L/A:N) reflects a network vector with high attack complexity, no required privileges, and only a LOW integrity impact (no confidentiality or availability loss) - the scope change (S:C) is what inflates an otherwise minor header-injection flaw. No EPSS score was provided, there is no CISA KEV listing, and no public exploit was supplied, so exploitation signals point to no public exploit identified at time of analysis. CONFLICTING SIGNAL: the vector states UI:N, but the description makes clear a victim user must actively forward a received message 'as an attachment' for the injection to occur - this is user interaction, so the UI:N metric appears understated and real-world triggering depends on a specific victim action. Combined with AC:H, this is a vendor-patched, low-impact integrity flaw that should be remediated on a normal patch cycle rather than treated as an emergency.

An attacker sends an email to a Roundcube user with a subject line containing CRLF sequences. When that user later forwards the received message as an attachment, Roundcube uses the subject verbatim as the attachment name, allowing the embedded CRLF to inject arbitrary MIME part headers into the outgoing message. No public exploit code was identified; exploitation requires the victim to perform the forward-as-attachment action.