EspoCRM CVE-2026-75505

Exploitation requires an authenticated EspoCRM account (prior to version 10.0.2) that has been granted mass-update permission, plus possession of a valid attachment identifier for a file the attacker is not otherwise authorized to read. The vulnerable path is specifically the mass-update file-copy logic (copyFileField / copyAttachmentMultipleField in Tools/MassUpdate/Processor.php), which duplicated attachments without an ACL read check. The primary limiting factor, explicitly stated by the vendor, is the difficulty of obtaining a valid attachment ID (reflected as AC:H); additionally the mass-update permission is an elevated privilege not held by ordinary read-only users, so this is effectively an insider/privilege-boundary bypass rather than an unauthenticated remote exposure.

This is a medium-severity authorization (access-control) flaw, not a critical one. The vendor-provided CVSS 4.0 vector (6.0) shows AV:N but AC:H and PR:L, meaning that while the mass-update endpoint is reachable over the network, exploitation requires an already-authenticated account holding mass-update permission AND knowledge of a valid attachment identifier - the description itself notes 'obtaining a valid attachment identifier may be difficult,' which justifies the high attack complexity. Impact is confidentiality-only (VC:H, VI:N, VA:N): an attacker can read file contents they should not access, but cannot modify or deny service. No EPSS score was provided in the input and the CVE is NOT listed in CISA KEV, so there is no evidence of widespread or active exploitation; the 'publicly available' POC references actually point to the vendor security advisory, the patch commit, and the 10.0.2 release rather than a standalone weaponized exploit. No SSVC decision data was supplied. Net: a legitimate but lower-priority insider/privilege-boundary issue - prioritize patching for multi-tenant or least-privilege EspoCRM deployments, but it is not a mass-exploitation threat given the authentication requirement and the difficulty of guessing attachment IDs.

An authenticated EspoCRM user who holds mass-update permission but lacks read access to a sensitive attachment supplies that attachment's known identifier to the mass-update functionality; the processor duplicates the file into a record the attacker controls, bypassing record- and field-level ACLs and exposing the file contents. A patch commit and security advisory are publicly available, but no standalone weaponized exploit was identified, and the attacker must first obtain a valid attachment ID, which the vendor notes is difficult.