EspoCRM CVE-2026-55154

Exploitation requires an authenticated low-privileged EspoCRM account (PR:L) able to store a free-text field value, plus a crafted payload where a formula trigger character (+, -, @, =) is preceded by whitespace or a control character so that the first-byte-only sanitizeCellValue() check fails to prepend the single-quote neutralization prefix. Impact is not self-contained: a SEPARATE privileged user must export the affected records to CSV or XLSX, open the resulting file, AND accept the spreadsheet application's formula/security prompts (UI:R) before the cell is evaluated. Data disclosure (e.g., outbound fetch formulas) is the baseline outcome; command execution is further LIMITED to legacy configurations with DDE explicitly enabled in the spreadsheet software. Affected: all EspoCRM versions prior to 9.3.9. Key limiting factors: dependency on victim interaction and prompt acceptance, low-privilege (not anonymous) access, and non-default DDE for the code-execution case.

This is a moderate, conditional risk best treated as a medium-priority hygiene fix rather than an urgent emergency. The CVSS 3.1 vector (AV:N/AC:L/PR:L/UI:R/S:C/C:L/I:L/A:N, base 5.4) is internally consistent with the description: a network-reachable CRM, low attack complexity to store the payload, low-privilege authentication required (PR:L), and mandatory user interaction (UI:R) because a separate privileged user must export, open the file, and actively accept spreadsheet security prompts before any impact occurs. The scope change (S:C) correctly reflects that the payload executes outside EspoCRM in the victim's spreadsheet application. Publicly available exploit code exists (vendor advisory GHSA-xrwp-2gph-985x plus the fix commit and release), which raises the practical likelihood of copycat attempts, but this is NOT the same as active exploitation - the CVE is not in CISA KEV and no EPSS score was provided in the input, so widespread automated exploitation cannot be asserted. The real-world risk is throttled by a long interaction chain (attacker-stored value → privileged export → file opened → security prompts accepted) and by the fact that the most severe outcome (command execution via DDE) depends on legacy, non-default spreadsheet configurations. Net: a legitimate issue to patch, but its medium CVSS and heavy reliance on victim behavior make it a priority-two item rather than a drop-everything event. EPSS and KEV are both absent/negative, consistent with the conclusion that no mass exploitation is confirmed.

A low-privileged EspoCRM user enters a crafted free-text field value (e.g., in a contact or lead record) where a formula such as =WEBSERVICE(...) or a DDE payload is prefixed with a space or control character so EspoCRM's single-quote neutralization is skipped. Later an administrator or manager exports those records to CSV/XLSX and opens the file; upon accepting the spreadsheet's security prompt, the cell is evaluated as a formula, leaking data outbound or, on legacy DDE-enabled setups, executing a command. Public exploit/advisory detail exists, lowering the bar for reproduction.