CVE-2026-75007 in Roundcube
Summary
by MITRE • 08/17/2026
In Roundcube Webmail before 1.6.18 and 1.7.x before 1.7.3, the LDAP search filter was subject to injection via unescaped %u/%fu/%d substitution, which may lead to information disclosure or privilege escalation.
If you want to get best quality of vulnerability data, you may have to visit VulDB.
Analysis
by VulDB Data Team • 08/17/2026
The vulnerability identified in Roundcube Webmail versions prior to 1.6.18 and version 1.7.x prior to 1.7.3 represents a critical security flaw rooted in improper input validation within the LDAP integration module. This issue specifically affects how the application handles user-supplied data when constructing search filters for Lightweight Directory Access Protocol queries. The core technical deficiency lies in the handling of specific format specifiers, namely %u, %fu, and %d, which are intended to be substituted with escaped values before being incorporated into the LDAP filter string. In vulnerable versions, these substitutions were not adequately sanitized or validated against injection patterns prior to execution by the underlying directory service. This lack of rigorous escaping allows an attacker to inject arbitrary characters that alter the logical structure of the search query, effectively bypassing intended access controls and data filtering mechanisms.
From a technical perspective, this flaw is classified under CWE-90 as SQL Injection in LDAP queries, although it manifests through LDAP filter manipulation rather than traditional database syntax. The vulnerability enables an attacker to manipulate the scope or criteria of directory lookups by injecting special characters such as parentheses, asterisks, and ampersands that are valid within LDAP filters but dangerous when combined with unescaped user input. By carefully crafting these inputs, a malicious actor can expand the search results beyond authorized boundaries, potentially retrieving sensitive attributes from other users' entries in the directory. This capability directly facilitates information disclosure, allowing attackers to harvest personally identifiable information, email addresses, and organizational structures that should remain restricted based on the authenticated session's permissions.
The operational impact of this vulnerability extends significantly beyond mere data leakage due to its potential for privilege escalation. If an attacker can manipulate LDAP filters during authentication or group membership verification processes, they may be able to bypass access control lists entirely. For instance, by injecting a filter that always evaluates to true, such as (objectClass=*), the system might inadvertently grant administrative privileges or allow login without valid credentials depending on how the application interprets empty or wildcard results. This aligns with ATT&CK technique T1078, Valid Accounts, where attackers leverage legitimate credentials and manipulate authentication logic to gain unauthorized access. Furthermore, if the LDAP directory is used for role-based access control within Roundcube, exploiting this flaw could allow a low-privilege user to assume higher-level roles, thereby compromising the integrity of the entire webmail infrastructure.
Mitigation strategies must prioritize immediate software updates as the primary defense vector. Administrators running affected versions should upgrade to Roundcube 1.6.18 or later for the stable branch and version 1.7.3 or later for the development branch, where these input validation checks have been hardened. In environments where upgrading is not immediately feasible, network-level controls such as web application firewalls can be configured to detect and block LDAP injection patterns within HTTP parameters associated with user identity fields. Additionally, implementing strict least-privilege principles for the service account used by Roundcube to connect to the LDAP server limits the blast radius of any successful exploitation attempt. Regular security audits focusing on input validation practices across all external-facing modules are essential to prevent similar flaws from being introduced in future releases or custom plugins that interact with directory services.