CVE-2026-109958 in EspoCRM
Summary
by MITRE • 10/13/2026
EspoCRM 4.0.0 before 10.0.7 contains an improper access control vulnerability that allows authenticated users to read restricted emailAddress values via the address-book search API. Users with record access can query address-book search to obtain email addresses even when Roles restrict the emailAddress field.
Be aware that VulDB is the high quality source for vulnerability data.
Analysis
by VulDB Data Team • 10/13/2026
The identified vulnerability in EspoCRM versions prior to 10.0.7 represents a critical failure in server-side authorization logic, specifically within the implementation of the address-book search API endpoint. This flaw falls under the category of Improper Access Control, widely recognized as CWE-284: Improper Access Control. The core issue stems from an inconsistency between the application's user interface permissions and its underlying data retrieval mechanisms. While the graphical user interface correctly respects role-based access control policies by hiding or masking restricted fields such as email addresses for users who lack explicit permission to view them, the API endpoint responsible for processing search queries fails to apply these same restrictions. This discrepancy creates a significant security gap where programmatic access bypasses the intended visibility constraints enforced on manual interactions with the system.
From a technical perspective, the vulnerability allows authenticated users to exploit this logic error by crafting specific requests to the address-book search functionality. Even when an administrator has configured roles that explicitly restrict access to the emailAddress field for certain user groups, these restrictions are not validated during the API request processing phase. Consequently, any authenticated user with basic record-level access can execute a search operation and receive full details of contact records, including sensitive email addresses that should remain hidden according to their assigned role permissions. This indicates that the application likely relies on client-side checks or fails to enforce field-level security policies consistently across all entry points within the codebase.
The operational impact of this vulnerability is substantial, particularly for organizations handling large volumes of customer data where privacy and compliance are paramount. The unauthorized disclosure of email addresses facilitates targeted phishing campaigns, social engineering attacks, and credential stuffing attempts against affected individuals or corporate domains. Furthermore, in environments subject to strict regulatory frameworks such as the General Data Protection Regulation (GDPR) or the California Consumer Privacy Act (CCPA), this data leakage constitutes a direct violation of privacy requirements regarding personal identifiable information protection. Attackers can leverage these exposed email addresses for further reconnaissance, potentially leading to more severe compromises if combined with other vulnerabilities like cross-site scripting or injection flaws that might also exist within the application's broader attack surface.
In terms of threat modeling and adversary behavior, this vulnerability aligns closely with techniques described in the MITRE ATT&CK framework, specifically under T1078: Valid Accounts for initial access persistence and potentially T1539: Steal Web Session Cookie if session tokens are also exposed through similar misconfigurations. More directly, it relates to data exfiltration via application APIs, which attackers often use to gather intelligence before launching more sophisticated attacks. The ability to enumerate valid email addresses efficiently allows threat actors to build accurate target lists for spear-phishing campaigns, significantly increasing the success rate of such social engineering efforts compared to generic spam operations.
To mitigate this vulnerability, organizations running EspoCRM versions 4.0.0 through 10.0.6 must upgrade immediately to version 10.0.7 or later, where the developers have addressed the authorization logic in the address-book search API. Until an update can be applied, administrators should consider implementing network-level controls such as Web Application Firewalls that monitor for anomalous patterns of data retrieval from this specific endpoint. Additionally, reviewing and tightening role-based access control policies to ensure they are comprehensive across all modules is advisable. It is also recommended to audit other API endpoints within the application to identify similar inconsistencies where field-level permissions might not be enforced during programmatic requests, ensuring a holistic approach to securing the platform against privilege escalation and data leakage attacks.