Roundcube Webmail CVE-2026-75007

Three conditions must simultaneously hold: (1) the attacker must possess a valid Roundcube user account (PR:L - low privilege, authenticated access required); (2) the Roundcube deployment must use an LDAP backend for authentication, addressbook lookups, or group membership checks, and the search_filter configuration option must contain at least one of the %u, %fu, or %d substitution placeholders; (3) the LDAP server must be reachable from the Roundcube application host. Deployments using only SQL-based authentication and addressbooks are entirely unaffected. The attacker must control the substituted value - typically the login username or mail domain - which is feasible for any authenticated user who can register or authenticate with a username containing LDAP metacharacters.

The vendor CVSS 8.8 (AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H) correctly identifies low-complexity network exploitation requiring only a valid account. However, A:H appears overstated - LDAP injection does not typically produce server availability loss, and neither the description nor the commit diff supports an availability impact; a more accurate assessment is A:N. Real-world risk is further bounded by EPSS of 0.25% (16th percentile) and SSVC technical impact rated only 'partial,' consistent with impact being limited to the LDAP directory rather than OS-level compromise. Crucially, the vulnerability is inert on Roundcube deployments backed by SQL or local authentication - only installations using LDAP backend with search_filter containing substitution variables are exposed. For enterprise and academic environments where Roundcube + LDAP is a common stack, the confidentiality and privilege escalation vectors are genuine high-priority concerns. No public exploit code has been identified; SSVC automatable is 'no,' meaning mass exploitation is not trivial.

An attacker with a valid Roundcube account crafts a username containing LDAP filter metacharacters such as *)(uid=admin)(|(uid=* and authenticates normally. Roundcube substitutes the unescaped username into the configured search_filter, causing the LDAP server to evaluate a malformed filter that returns unauthorized directory entries or collapses group membership restrictions. No public exploit code is known, but the technique is well-documented in LDAP injection literature and requires only basic authentication and knowledge of the server's filter template.