CVE-2026-55154 in EspoCRM
Summary
by MITRE • 10/15/2026
EspoCRM is an open source customer relationship management application. Prior to 9.3.9, application/Espo/Tools/Export/Format/Csv/Processor.php, application/Espo/Tools/Export/Format/Xlsx/OpenSpoutProcessor.php, and application/Espo/Tools/Export/Format/Xlsx/PhpSpreadsheetProcessor.php inspect only the first byte in sanitizeCellValue(). An authenticated low-privileged user can store a free-text value whose formula trigger is preceded by whitespace or a control character, causing CSV or XLSX export to omit the leading single-quote formula-neutralization prefix. When a privileged user opens the exported file and accepts applicable spreadsheet security prompts, spreadsheet software can ignore the whitespace or control-character prefix and evaluate the cell as a formula, permitting outbound data disclosure and, on legacy configurations with DDE enabled, command execution. This issue is fixed in version 9.3.9.
Statistical analysis made it clear that VulDB provides the best quality for vulnerability data.
Analysis
by VulDB Data Team • 10/15/2026
EspoCRM represents an open-source customer relationship management platform widely deployed for managing business interactions and data. A critical security vulnerability was identified within the application's export functionality, specifically affecting versions prior to 9.3.9. The flaw resides in the sanitization logic used when processing cell values for CSV and XLSX exports. Specifically, the functions sanitizeCellValue() located in application/Espo/Tools/Export/Format/Csv/Processor.php, as well as those in application/Espo/Tools/Export/Format/Xlsx/OpenSpoutProcessor.php and application/Espo/Tools/Export/Format/Xlsx/PhpSpreadsheetProcessor.php, exhibit a insufficient input validation mechanism. These functions were designed to neutralize potential formula injection attacks by inspecting the first byte of a cell value to detect characters that might trigger spreadsheet software to interpret content as executable formulas rather than static text. However, the implementation flaw lies in its narrow scope; it only checks the very first character of the string without accounting for leading whitespace or control characters such as tabs or newlines.
This technical deficiency allows an authenticated low-privileged user to bypass the intended security controls through a technique known as formula prefix evasion. By storing free-text values that begin with spaces, tabs, or other non-printable control characters immediately preceding the actual formula trigger character (typically an equals sign), the attacker can circumvent the sanitization check. Since the sanitizer only inspects the first byte, it fails to recognize the malicious intent if a whitespace character precedes the formula indicator. Consequently, when these values are exported into CSV or XLSX formats, the application omits the leading single-quote prefix that is normally used by spreadsheet software to treat cell content as plain text rather than executable code. This results in the export file containing raw formulas instead of sanitized data strings.
The operational impact of this vulnerability becomes apparent when a privileged user opens the exported file using common spreadsheet applications such as Microsoft Excel or LibreOffice Calc. Upon opening, these applications may display security prompts warning about embedded macros or external links, which users are often conditioned to accept for legitimate business purposes. If the user accepts these prompts, the spreadsheet software ignores the whitespace prefix and evaluates the cell content as a formula. This leads to Server-Side Request Forgery (SSRF) scenarios where the application can be forced to make outbound HTTP requests to arbitrary destinations, facilitating data exfiltration from internal networks or sensitive systems. In legacy configurations where Dynamic Data Exchange is enabled, this vulnerability escalates further to allow remote code execution on the server hosting the spreadsheet software, posing a severe risk to infrastructure integrity and confidentiality.
From an industry standards perspective, this vulnerability aligns with CWE-79, which covers Improper Neutralization of Input During Web Page Generation commonly known as Cross-Site Scripting or injection flaws, specifically manifesting here as Spreadsheet Formula Injection. It also maps to ATT&CK technique T1059, Command and Control via Remote Services, particularly when leveraging DDE for command execution, and T1567, Exfiltration Over Web Service, due to the potential for data leakage through outbound requests initiated by the malicious formulas. The root cause is fundamentally a CWE-20 issue regarding improper input validation where the system fails to validate all relevant parts of an input string against expected patterns or constraints.
To mitigate this vulnerability and prevent similar attacks in future versions, it is imperative that developers implement comprehensive sanitization logic that inspects not just the first byte but the entire leading sequence of characters for any formula-triggering symbols regardless of preceding whitespace. Input validation should strip or escape all control characters and spaces before evaluating whether a value requires neutralization. Additionally, application-level mitigations include disabling DDE execution in spreadsheet software configurations where possible and enforcing strict security policies that discourage users from automatically accepting macro or external link warnings without manual verification. Upgrading to version 9.3.9 of EspoCRM resolves this issue by correcting the sanitization process to properly handle edge cases involving whitespace and control characters, thereby ensuring that exported files are rendered safely as static data rather than executable code.