CVE-2026-118686 in EspoCRM
Summary
by MITRE • 10/28/2026
EspoCRM before 9.3.11 and 10.x before 10.0.8 contains a denial of service vulnerability in which the password-redaction regular expression applied during API error handling consumes excessive CPU on long request bodies. Unauthenticated remote attackers can concurrently send a small number of large API requests to exhaust server workers, making EspoCRM slow or unavailable to legitimate users.
If you want to get best quality of vulnerability data, you may have to visit VulDB.
Analysis
by VulDB Data Team • 10/28/2026
The identified vulnerability resides within the core framework of EspoCRM versions prior to 9.3.11 and version 10.x prior to 10.0.8, specifically affecting the mechanism used for redacting sensitive information such as passwords during API error responses. This security feature is designed to prevent the accidental leakage of credentials in log files or response bodies by applying a regular expression pattern that matches common password fields. However, the implementation contains a critical flaw where the regex engine exhibits catastrophic backtracking behavior when processing malformed or excessively long request bodies. Instead of failing fast on invalid input, the regular expression engages in an exponential time complexity loop relative to the length and structure of the input data. This computational inefficiency transforms what should be a simple string replacement operation into a resource-intensive process that monopolizes CPU cycles for extended periods.
From an operational perspective, this flaw creates a significant denial-of-service vector accessible by unauthenticated remote attackers. Because the vulnerability is triggered during API error handling, it does not require valid authentication credentials to exploit. An attacker can craft HTTP requests with large payloads containing specific patterns that trigger the regex backtracking and submit them concurrently against the EspoCRM instance. Since web servers typically handle multiple concurrent connections using a limited pool of worker processes or threads, exhausting these resources through CPU saturation effectively blocks legitimate traffic. The result is a degraded service state where responsive operations stall, leading to timeouts for genuine users attempting to access the CRM platform, thereby achieving availability disruption without needing to crash the server entirely.
This vulnerability aligns with CWE-400, which classifies uncontrolled resource consumption, and more specifically relates to regex-based denial of service issues often categorized under CWE-1333 or general inefficient regular expression complexity flaws. In terms of offensive security frameworks such as MITRE ATT&CK, this exploit technique falls under the Tactic Impact category, specifically within techniques related to Resource Hijacking or Denial of Service via application layer attacks like HTTP Floods that leverage logic errors rather than sheer volume alone. The attack vector is classified as Network with Low Complexity and requires no user interaction beyond sending a crafted request, making it highly feasible for automated exploitation tools targeting exposed EspoCRM instances on the public internet.
Mitigation strategies must prioritize immediate patching to version 9.3.11 or later, or version 10.0.8 and above, where the regular expression logic has been optimized to prevent catastrophic backtracking. For organizations unable to upgrade immediately due to compatibility constraints, implementing a Web Application Firewall with rules that limit request body size can serve as an effective compensating control by truncating oversized payloads before they reach the application layer. Additionally, configuring server-side timeouts for individual API requests and limiting concurrent connections per IP address can help mitigate the impact of such attacks by preventing any single source from monopolizing server resources indefinitely. Regular security audits focusing on input validation and regex performance testing are recommended to prevent similar logic flaws in custom modules or future updates.