CVE-2026-46694 in EspoCRM
Summary
by MITRE • 10/15/2026
EspoCRM is an open source customer relationship management application. Prior to 9.3.7, a portal user with stream access to a parent record can directly fetch a Note through the portal Note API and read an internal stream note when the note identifier is known. Stream list responses correctly hide notes whose isInternal field is true, but the direct single-Note access check does not enforce that restriction, exposing internal agent content. This issue is fixed in version 9.3.7.
If you want to get best quality of vulnerability data, you may have to visit VulDB.
Analysis
by VulDB Data Team • 10/15/2026
EspoCRM serves as a widely utilized open-source customer relationship management platform designed to help businesses manage interactions with current and potential customers. Within this ecosystem, the application provides various user roles and access controls to ensure data privacy and operational integrity. A significant security flaw was identified in versions prior to 9.3.7 concerning the handling of internal notes within the portal interface. The vulnerability stems from an inconsistency in how access control checks are applied across different API endpoints related to note management, specifically affecting users who have stream access to a parent record but lack explicit permissions for direct object-level operations on Notes.
The technical core of this flaw lies in the disparity between list-based retrieval and single-item retrieval mechanisms within the portal Note API. When a user requests a list of notes associated with a specific entity or stream, the application correctly filters out records where the isInternal field is set to true. This ensures that internal agent comments are not visible in aggregated views intended for external portal users. However, when an authenticated portal user attempts to fetch a single Note by its unique identifier through the direct access endpoint, the system fails to perform the same validation check against the isInternal flag. Consequently, if an attacker or malicious actor can deduce or obtain the specific identifier of an internal note, they can bypass the intended restrictions and retrieve sensitive information that was meant to be hidden from external users.
This vulnerability represents a classic case of broken access control where the enforcement logic is not uniformly applied across all entry points for a given resource type. From a threat modeling perspective, this allows for unauthorized data disclosure, enabling portal users who should only see customer-facing communications to view internal agent discussions, strategic notes, or other confidential operational details. The impact extends beyond mere privacy violation; it can compromise competitive intelligence if competitors gain access through partner portals, or it may violate regulatory compliance requirements regarding the segregation of sensitive business information. Such exposure undermines trust in the platform and could lead to significant reputational damage for organizations relying on EspoCRM for their customer engagement strategies.
In terms of industry standard classifications, this issue aligns with CWE-284, which describes Improper Access Control, specifically highlighting a failure to enforce restrictions on data access based on user roles or attributes. Furthermore, it maps to the MITRE ATT&CK framework under T1530, Data from Cloud Storage, as an attacker exfiltrates data stored within the application's database through unauthorized API calls. The vulnerability highlights the critical importance of implementing consistent security checks across all methods that interact with sensitive objects, ensuring that object-level permissions are validated regardless of whether the access is bulk or singular.
To mitigate this risk and prevent similar vulnerabilities in future development cycles, it is essential to enforce uniform validation logic for internal data fields across all API endpoints. Developers should implement a centralized authorization service or middleware that checks the isInternal attribute before returning any Note object, irrespective of the retrieval method used. Additionally, implementing strict input validation on identifiers can help mitigate enumeration attacks where attackers guess valid note IDs. Organizations currently running versions prior to 9.3.7 must upgrade immediately to the patched version which resolves this inconsistency by ensuring that direct access requests also respect the internal status flag. Regular security audits and penetration testing focusing on API endpoint permissions are recommended to identify any other potential bypasses in role-based access control implementations.