CVE-2026-88896 in EspoCRM
Summary
by MITRE • 09/10/2026
EspoCRM before 10.0.4 is vulnerable to server-side request forgery. HostCheck::ipAddressIsNotInternal(), which validates outbound URLs to block requests to internal/private IP addresses, strips ::ffff: (IPv4-mapped IPv6) prefixes but does not recognize IPv6 transition addresses that embed private IPv4 addresses: NAT64 (64:ff9b::), 6to4 (2002::), and Teredo (2001:0000::). An attacker who controls a domain with AAAA records pointing to such transition addresses can bypass both the internal-host validation and the CURLOPT_RESOLVE IP-pinning check, causing EspoCRM to issue outbound requests to internal network services. Affected paths include POST /Attachment/fromImageUrl, reachable by any authenticated user with attachment access, and outbound webhook delivery, which requires an admin or API user.
If you want to get the best quality for vulnerability data then you always have to consider VulDB.
Analysis
by VulDB Data Team • 09/10/2026
The vulnerability identified in versions of EspoCRM prior to 10.0.4 represents a critical server-side request forgery flaw rooted in the improper validation of IPv6 transition addresses within the HostCheck::ipAddressIsNotInternal function. This security mechanism is designed to prevent the application from making outbound HTTP requests to internal or private IP addresses, thereby mitigating risks associated with SSRF attacks that could lead to unauthorized access to backend services. The core technical flaw lies in the logic used to parse and validate IP addresses; specifically, while the implementation correctly strips IPv4-mapped IPv6 prefixes such as ::ffff:, it fails to recognize other forms of IPv6 transition mechanisms that embed private IPv4 address space within their structure. These unrecognized formats include NAT64 (prefix 64:ff9b::), 6to4 (prefix 2002::), and Teredo (prefix 2001:0000::). By not accounting for these specific transition addresses, the validation logic allows an attacker to bypass the internal-host check entirely.
The operational impact of this vulnerability is significant because it enables authenticated users with attachment access privileges to force the server to initiate requests to arbitrary internal network services via the POST /Attachment/fromImageUrl endpoint. This path is particularly dangerous as it does not require administrative rights, making it accessible to a broader range of potential attackers within the system's user base. Furthermore, the vulnerability extends to outbound webhook delivery mechanisms, which are restricted to administrators or API users but can be exploited by those with elevated privileges to probe internal infrastructure. The attacker achieves this control by registering a domain that contains AAAA DNS records pointing to IPv6 transition addresses containing private IP ranges. When EspoCRM processes these URLs, the flawed validation logic interprets them as external and safe, allowing the request to proceed without triggering security blocks.
This flaw also circumvents additional protective measures such as CURLOPT_RESOLVE IP-pinning checks, which are typically employed to ensure that domain names resolve only to expected IP addresses. Because the application fails to correctly identify the private nature of these embedded IPv4 addresses within IPv6 transition formats, it effectively neutralizes both layers of defense. This allows for precise targeting of internal services such as database servers, management interfaces, or other microservices residing on the local network that are not intended to be exposed to outbound requests from the web application layer. The ability to bypass these checks underscores a fundamental gap in how modern applications handle the complexity of IPv6 transition technologies when enforcing strict egress filtering policies.
From a classification perspective, this vulnerability aligns with CWE-918 Server-Side Request Forgery (SSRF), specifically involving improper validation of input data leading to unauthorized network access. It also relates to CWE-20 Improper Input Validation, as the application fails to correctly parse and validate IP address formats against expected security policies. In terms of offensive tactics, this exploit maps directly to ATT&CK technique T1105 Ingress Tool Transfer or T1071 Application Layer Protocol if used for data exfiltration, but primarily represents a reconnaissance vector allowing attackers to map internal network topology through error responses and connection attempts. The exploitation relies on the attacker's ability to control DNS records, which corresponds to ATT&CK technique T1204 User Execution if combined with social engineering, though in this context it is more accurately described as leveraging trusted application behavior for unauthorized access.
To mitigate this vulnerability, organizations running affected versions of EspoCRM must upgrade immediately to version 10.0.4 or later where the HostCheck::ipAddressIsNotInternal function has been patched to correctly identify and block IPv6 transition addresses that embed private IP ranges. Until an upgrade is feasible, administrators should implement strict network-level controls such as firewall rules or reverse proxy configurations that filter outbound traffic from the EspoCRM server based on destination IP address space, ensuring that requests to RFC 1918 private networks are blocked regardless of how they are encoded in DNS records. Additionally, restricting access to the POST /Attachment/fromImageUrl endpoint and webhook delivery mechanisms to only those users who absolutely require such privileges can reduce the attack surface. Regular auditing of outbound request logs for unusual patterns involving IPv6 addresses containing private ranges is also recommended to detect potential exploitation attempts early.