What is the CVSS score of CVE-2026-41141?

CVE-2026-41141 has a CVSS 3.1 base score of 6.5 (Medium). CVSS vector: CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:N/A:N. EPSS exploitation probability: 0.0%.

Is there a public PoC exploit available for CVE-2026-41141?

Yes, a public proof-of-concept exploit is available for CVE-2026-41141. Prioritise patching immediately. EPSS: 0.0%.

Is there a patch available for CVE-2026-41141?

Yes, a patch is available for CVE-2026-41141. Update the affected software to the latest version immediately.

EspoCRM CVE-2026-41141

EUVD-2026-32947 MEDIUM

Authorization Bypass Through User-Controlled Key (CWE-639)

2026-05-28 GitHub_M

Authentication Bypass Espocrm

6.5

CVSS 3.1 · GitHub Advisory

Severity by source

GitHub Advisory PRIMARY

6.5 MEDIUM

AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:N/A:N

Primary rating from GitHub Advisory · only source for this CVE.

CVSS VectorGitHub Advisory

CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:N/A:N

Attack Vector

Network

Attack Complexity

Low

Privileges Required

Low

User Interaction

None

Scope

Unchanged

Confidentiality

High

Integrity

None

Availability

None

Lifecycle Timeline

Patch available

May 28, 2026 - 18:02 EUVD

Analysis Generated

May 28, 2026 - 17:27 vuln.today

DescriptionGitHub Advisory

EspoCRM is an open source customer relationship management application. Prior to 9.3.5, the POST /api/v1/EmailTemplate/:id/prepare endpoint accepts an emailAddress parameter and resolves the owning entity (Contact, Lead, Account, or User) without performing an ACL check. An authenticated user with EmailTemplate read permission can extract all field values of any entity by supplying the target's email address, bypassing read: own or read: team ACL restrictions. This vulnerability is fixed in 9.3.5.

AnalysisAI

EspoCRM's POST /api/v1/EmailTemplate/:id/prepare endpoint exposes an IDOR-class ACL bypass (CWE-639) allowing authenticated low-privileged users to exfiltrate all field values from arbitrary Contact, Lead, Account, or User records prior to version 9.3.5. By supplying a target entity's email address as an attacker-controlled lookup key, the endpoint resolves and returns the full record without enforcing read:own or read:team ACL restrictions. A publicly available proof-of-concept exists; no public exploit identified at time of analysis as confirmed actively exploited (CISA KEV listing absent), but the low attack complexity and public POC meaningfully elevate real-world risk.

Technical ContextAI

EspoCRM implements role-based ACL policies including read:own (user can only read records they own) and read:team (user can only read records within their team). CWE-639 (Authorization Through User-Controlled Key) describes the root cause: the EmailTemplate prepare endpoint accepts a user-supplied emailAddress parameter and uses it as a lookup key to resolve the owning entity from any of four entity types (Contact, Lead, Account, User) without invoking the ACL layer. This means the authorization decision is effectively delegated to attacker-controlled input rather than a server-enforced permission check. The affected CPE is cpe:2.3:a:espocrm:espocrm:*:*:*:*:*:*:*:*, indicating all releases of the EspoCRM application up to the patched version are in scope. The vulnerability resides specifically in the entity-resolution logic of the email template preparation API rather than in EspoCRM's ACL engine itself, which functions correctly in other contexts.

RemediationAI

Upgrade EspoCRM to version 9.3.5 or later, which is the vendor-released patch that introduces proper ACL enforcement on the EmailTemplate prepare endpoint; the advisory is published at https://github.com/espocrm/espocrm/security/advisories/GHSA-vvmh-mf4h-96hw. If immediate upgrade is not feasible, a targeted compensating control is to revoke EmailTemplate read permissions from any role that operates under read:own or read:team ACL restrictions - this removes access to the vulnerable endpoint but will break legitimate email template preview functionality for those roles, which may be an acceptable trade-off in sensitive deployments. A second compensating control is to restrict access to the /api/v1/EmailTemplate/:id/prepare path at the network perimeter or via WAF rules for untrusted or externally-facing network segments; note this may disrupt internal users relying on template previews. Neither workaround addresses the root cause and both carry functional side effects - patching to 9.3.5 remains the definitive fix.