Roundcube twofactor_gauthenticator EUVD-2026-110649

Three concrete conditions must all hold: (1) the attacker already possesses the victim's valid Roundcube account password, since this bypasses only the second factor; (2) the twofactor_gauthenticator IP-whitelist/trusted-address feature is configured so that 2FA is skipped for whitelisted source IPs - installations not using IP whitelisting are not exploitable; and (3) the deployment accepts and trusts attacker-supplied Client-IP or X-Forwarded-For headers (e.g., no reverse proxy that strips/overwrites them), allowing the attacker to spoof a whitelisted address. Limiting factors that reduce realistic risk: the mandatory prior password compromise, the non-default whitelist configuration requirement, and AC:H reflecting that the attacker must know a valid whitelisted IP value.

This is a medium-severity authentication-bypass (CWE-290) with multiple signals pointing to limited, conditional real-world risk rather than an emergency. The CVSS 4.0 base score is 6.3 with AV:N/AC:H/AT:N/PR:N/UI:N and only Low confidentiality/integrity impact (VC:L/VI:L/VA:N), and the vuln.today Decision label is 'this_month' - a routine-but-timely priority, not act_now or emergency. EPSS is 0.48% (41st percentile), indicating low modeled exploitation probability, and there is no CISA KEV listing and no public exploit code referenced. The most important caveat is a signal conflict: the CVSS vector encodes PR:N (nominally unauthenticated), but the description explicitly states the attacker must first obtain the user's password, so exploitation is NOT truly pre-authentication in practice - treat the PR:N as understating the real prerequisite, which is why AC:H is justified. Exploitation is further gated on the plugin's IP-whitelist feature being enabled, so default/non-whitelisting deployments are not affected. Net: a legitimate issue to patch on a normal cycle, not a high-CVSS-but-hollow finding, but also not a drop-everything priority given low EPSS, no KEV, no POC, and the stacked preconditions.

An attacker who has already compromised a Roundcube user's password (e.g., via phishing or credential reuse) targets an installation where the twofactor_gauthenticator IP-whitelist feature is enabled. Because the plugin trusts the Client-IP and X-Forwarded-For request headers without validation, the attacker sends a login request with a forged header matching a whitelisted IP, causing the second factor to be skipped and granting mailbox access. No public exploit code is referenced, but the technique (header spoofing) is low-effort once the preconditions are met.