Severity by source
AV:N/AC:H/PR:L/UI:N/S:C/C:L/I:N/A:N
DNS rebinding requires attacker-controlled DNS infrastructure and a timing race (AC:H); any authenticated standard user suffices (PR:L); internal network access changes scope (S:C) with limited confidentiality impact only (C:L, I:N, A:N).
Primary rating from GitHub Advisory.
CVSS VectorGitHub Advisory
Lifecycle Timeline
6DescriptionGitHub Advisory
EspoCRM is an open source customer relationship management application. In versions 9.3.3 and below, the POST /api/v1/Attachment/fromImageUrl endpoint is vulnerable to Server-Side Request Forgery (SSRF) via a DNS rebinding (TOCTOU) condition. Host validation uses dns_get_record() but the actual HTTP request resolves hostnames through curl's internal resolver (gethostbyname()), allowing the two lookups to return different IP addresses for the same hostname. A secondary issue exists where an empty DNS result (due to DNS failure, IPv6-only domains, or non-existent hostnames) causes the validation to implicitly allow the host without further checks. An authenticated attacker with default attachment creation access can exploit this gap to bypass internal IP restrictions and scan internal network ports, confirm the existence of internal hosts, and interact with internal HTTP-based services, though data extraction from binary protocol services and remote code execution are not possible through this endpoint. This issue has been fixed in version 9.3.4.
AnalysisAI
Server-Side Request Forgery in EspoCRM 9.3.3 and below allows authenticated attackers to bypass internal IP restrictions via a DNS rebinding race condition in the image attachment endpoint, enabling internal network reconnaissance. The root cause is a split-resolver design: host validation uses dns_get_record() while the actual HTTP fetch uses curl's independent gethostbyname() resolver - attacker-controlled DNS can return a public IP for validation and an internal IP for the actual request. A secondary bypass exists where empty DNS results cause validation to silently permit the host. No public exploit has been confirmed as actively exploited (not in CISA KEV), though a POC is publicly available and the vendor-confirmed fix shipped in 9.3.4.
Technical ContextAI
The vulnerability resides in EspoCRM's POST /api/v1/Attachment/fromImageUrl endpoint, which fetches remote images via curl. The affected HostCheck.php (versions ≤9.3.3) calls dns_get_record() to resolve a submitted hostname and validates the result against an internal IP blocklist, but the subsequent curl request independently resolves the same hostname via gethostbyname(). This split-resolver pattern is a textbook TOCTOU (Time-of-Check/Time-of-Use) race: by controlling a DNS server with a very short TTL, an attacker makes the validation lookup return a legitimate public IP, then flips the record to an internal IP before curl fires. CWE-918 (SSRF) applies. CPE: cpe:2.3:a:espocrm:espocrm:*:*:*:*:*:*:*:*. A compounding secondary flaw caused empty DNS responses - from DNS failure, IPv6-only domains, or non-existent hostnames - to implicitly pass validation instead of failing closed. The 9.3.4 fix in commit dca03cc introduces getCurlResolve(), which pre-resolves the hostname once and pins that resolved IP to curl via the --resolve flag, eliminating the race window entirely, and explicitly rejects empty DNS results by returning false.
RemediationAI
Upgrade to EspoCRM 9.3.4, which resolves both the DNS rebinding TOCTOU race and the empty-DNS-result bypass; the patched release is available at https://github.com/espocrm/espocrm/releases/tag/9.3.4 and the fixing commit is dca03cc3458e487362c26c746378a2d4de9990b1. If immediate patching is not feasible, restrict access to the POST /api/v1/Attachment/fromImageUrl endpoint via WAF rules or reverse proxy ACLs - note this disables the image URL attachment feature entirely as a trade-off. As a network-layer compensating control, block outbound HTTP and HTTPS connections from the EspoCRM application server to RFC-1918 address ranges (10.0.0.0/8, 172.16.0.0/12, 192.168.0.0/16) and link-local ranges (169.254.0.0/16) at the perimeter firewall; this limits SSRF blast radius to external targets but does not eliminate the vulnerability. The secondary empty-DNS bypass can be partially mitigated by ensuring the EspoCRM server's DNS resolver is configured to fail-closed on resolution errors rather than returning empty results, though this is a non-standard resolver configuration with potential operational side effects.
Directory traversal vulnerability in EspoCRM before 2.6.0 allows remote attackers to include and execute arbitrary local
Path traversal in EspoCRM's formula scripting engine allows authenticated administrators to achieve arbitrary file read/
EspoCRM version 7.1.8 is vulnerable to Unrestricted File Upload allowing attackers to upload malicious file with any ext
EspoCRM 5.6.4 is vulnerable to user password hash enumeration. Rated high severity (CVSS 8.8), this vulnerability is rem
Authorization bypass in EspoCRM 5.8.5 lets an authenticated low-privilege user reuse or manipulate Basic-Authorization a
CSV Injection in Create Contacts in EspoCRM 7.1.8 allows remote authenticated users to run system commands via creating
Path traversal in EspoCRM admin template management allows authenticated administrators to read, create, overwrite, or d
Server-side request forgery in EspoCRM before 10.0.4 allows authenticated users to route outbound HTTP requests to inter
Stored cross-site scripting in EspoCRM 9.3.3 and below enables an authenticated attacker to execute arbitrary JavaScript
EspoCRM's POST /api/v1/EmailTemplate/:id/prepare endpoint exposes an IDOR-class ACL bypass (CWE-639) allowing authentica
EspoCRM is an Open Source CRM (Customer Relationship Management) software. Rated medium severity (CVSS 6.5), this vulner
Cross Site Scripting in Import feature in EspoCRM 7.1.8 allows remote users to run malicious JavaScript in victim s brow
Same weakness CWE-918 – Server-Side Request Forgery (SSRF)
View allShare
External POC / Exploit Code
Leaving vuln.today
EUVD-2026-22083