CVE-2026-46694: EspoCRM Information Disclosure Vulnerability

CVE-2026-46694 Overview

EspoCRM is an open source customer relationship management (CRM) application widely deployed for sales, support, and portal-based collaboration. CVE-2026-46694 is a missing authorization flaw [CWE-862] affecting EspoCRM versions 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. Maintainers released a fix in version 9.3.7.

Critical Impact
Authenticated portal users can retrieve internal agent-only stream notes attached to records they share, exposing confidential comments intended for internal staff.

Affected Products

EspoCRM versions prior to 9.3.7
EspoCRM deployments exposing the customer portal with stream access
Self-hosted and cloud EspoCRM installations with portal users assigned to shared parent records

Discovery Timeline

2026-10-15 - CVE-2026-46694 published to NVD
2026-10-16 - Last updated in NVD database

Technical Details for CVE-2026-46694

Vulnerability Analysis

The flaw resides in the portal Note access check implemented in application/Espo/Classes/AclPortal/Note/AccessChecker.php. EspoCRM's stream feature records activity notes against parent entities. Some notes are marked internal via the isInternal property so only internal users can view them. The list endpoint filters these notes out of stream responses, but the direct single-record fetch handler evaluates authorization only against the parent entity relationship. When a portal user has legitimate access to the parent record and knows or guesses a note identifier, the API returns the full note payload regardless of the internal flag.

Root Cause

The root cause is a missing authorization check [CWE-862] in the portal access checker. The function evaluated parent ownership but omitted the condition that denies access to notes where isInternal returns true. Access control inconsistency between list and single-item endpoints allowed the internal filter to be bypassed by addressing a note directly.

Attack Vector

Exploitation requires an authenticated portal account with stream access to at least one shared parent record. The attacker issues a direct GET request against the portal Note API using a known or enumerated note identifier. Because note identifiers are referenced in stream payloads and related metadata, discovery is often trivial for a user already interacting with the parent record. The API then returns the internal note content, including comments authored by internal agents.

php

// Patch excerpt - application/Espo/Classes/AclPortal/Note/AccessChecker.php
        $parentId = $entity->getParentId();
        $parentType = $entity->getParentType();

+        if ($entity->isInternal()) {
+            return false;
+        }
+
        if ($parentId && $parentType) {
            $parent = $this->entityManager->getEntityById($parentType, $parentId);

Source: EspoCRM commit ee039bd

Detection Methods for CVE-2026-46694

Indicators of Compromise

Portal user accounts issuing direct GET /api/v1/portal/Note/{id} requests outside of normal stream list browsing patterns.
HTTP 200 responses to portal Note fetches where the response body contains notes previously filtered from stream list endpoints.
Spikes in portal API traffic enumerating sequential or guessed Note identifiers.

Detection Strategies

Review web server and application logs for portal users accessing the single-Note endpoint without a preceding stream list request for the same parent record.
Correlate portal session activity with Note record identifiers to identify access to notes marked isInternal = true.
Alert on EspoCRM audit log entries that show portal roles reading Note entities authored by internal users.

Monitoring Recommendations

Enable verbose request logging for the EspoCRM portal API and forward logs to a centralized analytics platform for retention and search.
Add detection rules that flag portal user agents retrieving note content with internal metadata fields present.
Monitor for high-volume identifier enumeration against the /api/v1/portal/Note/ route.

How to Mitigate CVE-2026-46694

Immediate Actions Required

Upgrade all EspoCRM installations to version 9.3.7 or later as the primary remediation.
Audit portal user accounts and remove unnecessary stream access to sensitive parent records.
Review historical access logs for portal Note API requests and investigate any unexpected retrievals of internal notes.

Patch Information

The vendor fix is included in EspoCRM 9.3.7, released on GitHub. The patch adds an isInternal() check at the top of the portal note access evaluator, denying access when the note is flagged internal. See the GitHub Security Advisory GHSA-cg9f-34hj-p238 and the GitHub Release 9.3.7 for release artifacts and notes.

Workarounds

If an immediate upgrade is not possible, restrict portal user roles so that users with access to sensitive parent records cannot invoke the Note API directly.
Apply the upstream patch from commit ee039bd manually to AccessChecker.php and clear the EspoCRM cache.
Place a reverse proxy or web application firewall rule in front of EspoCRM to block portal requests to /api/v1/portal/Note/{id} pending patch deployment.

bash

# Upgrade EspoCRM to the patched release
cd /var/www/espocrm
php command.php upgrade --version=9.3.7
php command.php clear-cache
php command.php rebuild