CVE-2026-41160
Broken Access Control in EspoCRM Allows Note Pinning
Publication date: 2026-05-28
Last updated on: 2026-05-28
Assigner: GitHub, Inc.
Description
Description
CVSS Scores
EPSS Scores
| Probability: | |
| Percentile: |
Meta Information
Affected Vendors & Products
| Vendor | Product | Version / Range |
|---|---|---|
| espocrm | espocrm | to 9.3.5 (exc) |
| espocrm | espocrm | 9.3.5 |
| espocrm | espocrm | From 9.3.3 (inc) |
Helpful Resources
Exploitability
| CWE ID | Description |
|---|---|
| CWE-862 | The product does not perform an authorization check when an actor attempts to access a resource or perform an action. |
| CWE-639 | The system's authorization functionality does not prevent one user from gaining access to another user's data or record by modifying the key value identifying the data. |
| CWE-284 | The product does not restrict or incorrectly restricts access to a resource from an unauthorized actor. |
Attack-Flow Graph
AI Powered Q&A
Can you explain this vulnerability to me?
CVE-2026-41160 is a Broken Access Control vulnerability in EspoCRM versions 9.3.3 and earlier. It allows low-privileged users to pin arbitrary notes to objects they do not have edit permissions for. This happens because the backend API endpoint for pinning notes processes the pin request by first updating the database and then performing the authorization check. As a result, even if the server returns a 403 Forbidden error indicating insufficient permissions, the note's pinned status is already permanently modified in the database.
The vulnerability is due to a 'write first, authorize later' logic flaw in the POST /api/v1/Note/{id}/pin endpoint. Attackers can exploit this by intercepting a note ID from a legitimate request and sending a manual POST request to pin the note using their authentication tokens. Although the server responds with a 403 error, the note remains pinned, creating a 'phantom write' that is difficult to audit.
How can this vulnerability impact me? :
This vulnerability can impact you by allowing unauthorized users with low privileges to manipulate the pinned status of notes within EspoCRM. This means attackers can change the priority and visibility of notes in business workflows, such as sales or customer relationship management, without proper authorization.
The primary impact is on data integrity, as unauthorized modifications can occur without detection. This can lead to confusion, miscommunication, or manipulation of business processes that rely on note prioritization.
How can this vulnerability be detected on my network or system? Can you suggest some commands?
This vulnerability can be detected by monitoring for unauthorized POST requests to the endpoint /api/v1/Note/{id}/pin that result in a 403 Forbidden response but still cause changes in the pinned status of notes in the database.
An attacker may send manual POST requests with valid authentication tokens to pin notes without proper permissions. Detection involves correlating 403 responses with unexpected changes in note pinning.
Suggested commands include using network traffic inspection tools like curl or intercepting proxy tools (e.g., Burp Suite) to replay or monitor POST requests to the pin endpoint.
- Example curl command to test pinning a note (replace {id} and token):
- curl -X POST https://your-espocrm-instance/api/v1/Note/{id}/pin -H "Authorization: Bearer <token>"
After sending such a request, check if the note's pinned status has changed despite receiving a 403 Forbidden response.
What immediate steps should I take to mitigate this vulnerability?
The immediate mitigation step is to upgrade EspoCRM to version 9.3.5 or later, where this vulnerability has been fixed.
Until the upgrade can be applied, restrict access to the /api/v1/Note/{id}/pin endpoint to trusted users only, and monitor logs for suspicious POST requests to this endpoint.
Additionally, review and tighten API authorization logic if possible, to ensure that write operations are authorized before being applied.