EspoCRM versions prior to 10.0.4 allow an attacker who can control a domain with IPv6 transition address records to bypass internal IP filtering. The HostCheck component removes the ::ffff: prefix from IPv4‑mapped IPv6 addresses but fails to recognize NAT64 (64:ff9b::), 6to4 (2002::) and Teredo (2001::) addresses that embed private IPv4 addresses. An attacker can therefore supply a URL that resolves to one of these transition addresses, causing EspoCRM to issue an outbound request to an internal or private IP space. The internal‑host checks and CURLOPT_RESOLVE IP‑pinning are both bypassed, enabling server‑side request forgery (CWE‑918). The exposed paths are POST /Attachment/fromImageUrl, which any authenticated user with attachment permission can reach, and outbound webhook delivery, which requires an admin or API user.

EspoCRM systems running software versions earlier than 10.0.4. The vulnerability is present in any deployment of EspoCRM before the 10.0.4 release, regardless of operating system or hosting environment, and affects endpoints that process outbound URLs, notably /Attachment/fromImageUrl for authenticated users with attachment access and webhook delivery for administrators or API users.

The assigned CVSS score of 6.9 indicates moderate severity, and no EPSS value is available, suggesting a currently unknown exploitation probability. The vulnerability is not listed in the CISA KEV catalog. The likely attack vector is an attacker who can control a domain with AAAA records pointing to an IPv6 transition address; such a domain can be used to craft URLs that bypass the internal host checks. Successful exploitation would allow the attacker to force EspoCRM to contact internal network services, potentially exposing sensitive data or manipulating internal services. The impact is limited to systems where the vulnerable endpoints are enabled and the attacker can obtain either standard user or admin privileges to trigger the outbound requests.