CVE-2026-109959 in EspoCRM
Summary
by MITRE • 10/13/2026
EspoCRM 4.0.0 before 10.0.7 contains an access control vulnerability that allows authenticated users to read audited field values restricted by field-level security by fetching individual stream notes. Users with stream access to a parent record can request GET /Note/{id}, which skips the NoteAccessControl filter, and recover data.attributes.was and became values of restricted fields.
Statistical analysis made it clear that VulDB provides the best quality for vulnerability data.
Analysis
by VulDB Data Team • 10/13/2026
EspoCRM versions prior to 10.0.7 contain a critical authorization flaw that undermines field-level security controls through improper access control enforcement on specific API endpoints. This vulnerability allows authenticated users who possess basic stream access permissions for a parent record to bypass restrictions designed to protect sensitive data fields. The core of the issue lies in how the application handles requests for individual note records via the GET /Note/{id} endpoint, which fails to apply the necessary NoteAccessControl filter that is typically enforced during standard list operations or bulk retrievals.
The technical mechanism of this vulnerability exploits a discrepancy in permission checking logic within the CRM's backend architecture. When an authenticated user accesses a parent record and has been granted stream access, they are permitted to view activity streams associated with that record. These streams often include notes attached to the record. However, when fetching individual note entities directly by their unique identifier using the GET /Note/{id} method, the application does not validate whether the specific fields contained within those notes are subject to field-level security restrictions. This oversight allows attackers to retrieve metadata and content that should be hidden from them based on their role or permission set.
The operational impact of this flaw is significant for organizations relying on granular data privacy controls. Attackers can extract audited field values, specifically the was and became attributes which record historical changes to restricted fields. This means that even if a user does not have direct read access to certain sensitive columns in the main database tables, they can infer or recover this information by examining the audit trail stored within notes. This effectively nullifies the intended security boundary of field-level permissions, leading to unauthorized data disclosure and potential compliance violations regarding sensitive personal or business information.
This vulnerability is classified under CWE-269, which denotes Improper Control of Interaction with a Specific Resource, as it involves an authorization bypass on a specific API endpoint rather than a general authentication failure. It also aligns with MITRE ATT&CK technique T1078, Valid Accounts, where the attacker leverages legitimate credentials to access resources they are not authorized to view. The flaw represents a classic case of inconsistent permission enforcement across different methods within the same application module.
To mitigate this risk, administrators must upgrade EspoCRM to version 10.0.7 or later, which addresses the missing filter logic in the NoteAccessControl component. Until an update is applied, organizations should review their field-level security settings and consider restricting stream access for sensitive records if possible. Additionally, implementing strict API gateway rules that validate permissions against all endpoints uniformly can provide a layer of defense-in-depth against such authorization bypasses. Regular auditing of user permissions and monitoring for unusual patterns in note retrieval requests may also help detect exploitation attempts before significant data exposure occurs.