VYPR
← All advisories
Medium severity6.5NVD Advisory· Published May 28, 2026· Updated May 28, 2026

CVE-2026-41141

CVE-2026-41141

Description

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.

AI Insight

LLM-synthesized narrative grounded in this CVE's description and references.

EspoCRM prior to 9.3.5 allows authenticated users to read any entity's field values via the EmailTemplate prepare endpoint without ACL check.

Vulnerability

In EspoCRM versions before 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. The code in Espo\Tools\EmailTemplate\Processor::prepare() at lines 362-383 uses getEntityByAddress() and adds the entity directly to the template rendering context without verifying read permissions [1]. This allows an authenticated user with EmailTemplate read permission to access any entity's field values.

Exploitation

An attacker must be authenticated and have at least read permission on EmailTemplates. They can create or use an existing email template containing placeholder variables (e.g., {{Contact.description}}, {{Person.name}}). By calling the prepare endpoint with the victim's email address, the server resolves the victim's entity and fills the template, returning all referenced field values in the API response [1]. No additional privileges are required.

Impact

Successful exploitation leads to unauthorized disclosure of all field values of any Contact, Lead, Account, or User entity. This bypasses read: own or read: team ACL restrictions, potentially exposing sensitive personal or business data [1]. The attacker gains information disclosure at the level of the entity's full attribute set.

Mitigation

The vulnerability is fixed in EspoCRM version 9.3.5 [1]. Users should upgrade to this version or later. No workarounds are mentioned in the advisory. If upgrading is not immediately possible, consider restricting access to the EmailTemplate prepare endpoint or disabling the feature until the patch is applied.

References
  1. IDOR in EmailTemplate Prepare Endpoint Leaks Entity Data via Email Address Lookup

AI Insight generated on May 28, 2026. Synthesized from this CVE's description and the cited reference URLs; citations are validated against the source bundle.

Affected products

2
  • Espocrm/Espocrminferred2 versions
    <9.3.5+ 1 more
    • (no CPE)range: <9.3.5
    • (no CPE)range: <9.3.5

Patches

1
0737fb82e3b5

Email template check entity

https://github.com/espocrm/espocrmYuriiApr 17, 2026Fixed in 9.3.5via llm-release-walk
commit
1 file changed · +8 −0
  • application/Espo/Tools/EmailTemplate/Processor.php+8 −0 modified
    @@ -370,6 +370,14 @@ private function prepare(Data $data, User $user, Params $params): array
                     User::ENTITY_TYPE,
                 ]
             );
+
+            if (
+                $foundByAddressEntity &&
+                $params->applyAcl() &&
+                !$this->aclManager->checkEntityRead($this->user, $foundByAddressEntity)
+            ) {
+                $foundByAddressEntity = null;
+            }
         }
 
         if ($foundByAddressEntity) {

Vulnerability mechanics

Root cause

"Missing ACL check in EmailTemplate prepare endpoint when resolving an entity by email address allows unauthorized data access."

Attack vector

An authenticated attacker with EmailTemplate read permission sends a POST request to `/api/v1/EmailTemplate/:id/prepare` with a victim's email address as the `emailAddress` parameter [ref_id=1]. The server resolves the owning entity (Contact, Lead, Account, or User) via `getEntityByAddress()` without performing any ACL check, then substitutes template variables (e.g., `{{Contact.description}}`) with the entity's full attribute set [ref_id=1]. The attacker receives the rendered template containing all referenced field values in the API response, bypassing read: own or read: team ACL restrictions [ref_id=1].

Affected code

The vulnerable code is in `Espo\Tools\EmailTemplate\Processor::prepare()`, specifically lines 362-383 which handle entity resolution by email address [ref_id=1]. This code path calls `getEntityByAddress()` and adds the result directly to `$entityHash` without an ACL check, unlike the secure `parentId` path at lines 386-401 which calls `$this->aclManager->checkEntityRead()` [ref_id=1].

What the fix does

The advisory states the vulnerability is fixed in version 9.3.5 [ref_id=1]. The fix should add an ACL check (similar to the one already present in the `parentId` code path at lines 386-401) after the entity is resolved by email address, ensuring that `$this->aclManager->checkEntityRead()` is called before the entity is added to the template rendering context [ref_id=1]. Without this check, any authenticated user with EmailTemplate read permission can read all fields of any entity whose email address they know.

Preconditions

  • authAttacker must be an authenticated user with EmailTemplate read permission
  • inputAttacker must know the target entity's email address
  • networkAttacker must be able to send HTTP POST requests to the /api/v1/EmailTemplate/:id/prepare endpoint

Reproduction

The advisory includes a PoC archive (poc.zip) with a Docker Compose setup and an exploit.sh script [ref_id=1]. Steps: (1) Extract the uploaded compressed file, (2) Run `docker compose up -d`, (3) Run `bash exploit.sh` [ref_id=1].

Generated on May 28, 2026. Inputs: CWE entries + fix-commit diffs from this CVE's patches. Citations validated against bundle.

References

1

News mentions

0

No linked articles in our index yet.