CVE-2026-105831 in EspoCRM
Summary
by MITRE • 10/08/2026
EspoCRM before 10.0.6 contains a stored HTML injection vulnerability that allows unauthenticated attackers to inject HTML by submitting crafted Lead Capture public form data. The request body is stored in LeadCaptureLogRecord.data and rendered unescaped when administrators view the log record, though Content Security Policy blocks JavaScript execution.
If you want to get best quality of vulnerability data, you may have to visit VulDB.
Analysis
by VulDB Data Team • 10/08/2026
EspoCRM versions prior to 10.0.6 are susceptible to a Stored Cross-Site Scripting vulnerability within its public-facing lead capture functionality. This flaw arises from insufficient input validation and output encoding when handling data submitted through the Lead Capture form, which is designed for external users to submit information without authentication. The core technical deficiency lies in the application's failure to properly sanitize HTML special characters or encode user-supplied content before persisting it into the database. Specifically, the malicious payload is stored within the LeadCaptureLogRecord.data field during the initial submission phase. While the input itself may not immediately execute code due to server-side processing constraints, the critical security lapse occurs at the retrieval and rendering stage. When an administrator accesses the log records associated with these lead captures, the application renders the stored data directly into the HTML document structure without applying necessary escaping mechanisms. This behavior transforms a passive storage issue into an active execution vector for any user with administrative privileges who views the affected logs.
The operational impact of this vulnerability is significant because it targets privileged accounts rather than general end-users or anonymous visitors. Although the application implements Content Security Policy headers that effectively block the execution of inline JavaScript, preventing traditional script-based attacks such as session hijacking via document.cookie theft, the lack of HTML escaping allows for more sophisticated non-scripting based attacks. Attackers can inject malicious HTML elements including images with malformed attributes, iframes pointing to phishing sites, or other structural tags designed to manipulate the visual presentation and layout of the administrative interface. This capability enables Clickjacking scenarios where an attacker overlays deceptive UI elements over legitimate admin controls, potentially tricking administrators into performing unintended actions such as changing passwords, modifying user permissions, or exporting sensitive data. Furthermore, injected HTML can be used for phishing campaigns against other staff members by altering the appearance of internal dashboards to mimic external login portals or warning messages that induce credential disclosure.
From a classification perspective, this vulnerability aligns with CWE-79: Improper Neutralization of Input During Web Page Generation commonly known as Cross-site Scripting. The specific nature of storing malicious content in the database and retrieving it later for display categorizes it under Stored XSS rather than Reflected XSS. In terms of adversary tactics, this flaw supports ATT&CK technique T1059: Command and Control via HTML Injection or more broadly T1189: Drive-by Compromise if combined with social engineering elements that lure administrators to click on injected links within the manipulated interface. The absence of JavaScript execution mitigates some risks but does not eliminate the threat landscape, as modern web browsers render complex DOM structures that can be exploited for UI redressing and credential harvesting without requiring script execution capabilities.
To mitigate this vulnerability, immediate patching is required by upgrading EspoCRM to version 10.0.6 or later where these input validation rules have been corrected. In the interim, administrators should restrict access to lead capture logs through additional authentication layers if possible, although the primary fix must address the root cause in the rendering engine. Developers implementing custom modules or integrations with EspoCRM should ensure that any data retrieved from database fields intended for HTML display is passed through robust output encoding functions such as htmlspecialchars in PHP environments before being inserted into DOM elements. Implementing strict Content Security Policy directives remains a valuable defense-in-depth measure, but it must be complemented by proper input sanitization and output encoding to fully neutralize stored injection risks. Regular security audits of public-facing forms are essential to identify similar patterns where user-supplied data is persisted without adequate validation checks against HTML entity boundaries.