EspoCRM EUVD-2026-102099

Attacker must hold a valid, authenticated EspoCRM account that has been granted Import scope access (PR:L), and must supply another user's import record identifier to POST /api/v1/Import/{id}/exportErrors on an instance running a version prior to 9.3.7. The data exposed is limited to the error CSV rows of the targeted import. Limiting factors: no unauthenticated access is possible (a provisioned account with Import permission is mandatory), the attacker needs or must guess/enumerate a target import ID, and upgrading to 9.3.7 (which adds the entity-level checkEntityRead ownership check) fully closes the path; no user interaction by the victim is required.

This is a broken object-level authorization flaw (CWE-862) in EspoCRM's Import export-errors endpoint. The CVSS 3.1 vector (AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:N/A:N, base 6.5) indicates a network-reachable, low-complexity attack requiring only low privileges (PR:L = an authenticated account with Import scope), with high confidentiality impact and no integrity or availability impact. The commit diff confirms the root cause: exportErrors() fetched the Import record by ID without calling checkEntityRead(), so a scope-level check passed while the per-record ownership check was skipped - a classic IDOR. Publicly available exploit material exists (the vendor GHSA advisory, the fixing commit, and the 9.3.7 release are all referenced), which raises practical risk because the vulnerable code path and fix are fully disclosed. No CISA KEV listing and no EPSS score were provided in the input, so there is no evidence of active in-the-wild exploitation and exploitation probability cannot be quantified from the data given. Net assessment: a genuine but medium-severity authenticated information-disclosure issue - not a drive-by unauthenticated RCE. The high CVSS confidentiality rating should be weighed against the real limiting factor that the attacker must already hold a valid EspoCRM account with Import permissions, which narrows the threat largely to insider or post-account-compromise scenarios.

An authenticated EspoCRM user who holds Import scope access (but not ownership of a given import) sends POST /api/v1/Import/{id}/exportErrors supplying another user's import identifier, and the server returns an attachment identifier for a CSV containing rows from that victim's import, which the attacker then downloads. Because the endpoint only checks scope-level access and omits the entity-level ownership check, the attacker reads data they were never authorized to see. A public exploit path is disclosed via the vendor advisory and fixing commit, lowering the effort to reproduce.