CVE-2026-33659: EspoCRM SSRF Vulnerability via DNS Rebinding

CVE-2026-33659 Overview

CVE-2026-33659 is a Server-Side Request Forgery (SSRF) vulnerability affecting EspoCRM, an open source customer relationship management (CRM) application. The vulnerability exists in the POST /api/v1/Attachment/fromImageUrl endpoint, which is susceptible to DNS rebinding attacks due to a Time-of-Check Time-of-Use (TOCTOU) race condition in hostname validation.

The flaw arises from a discrepancy between two DNS resolution mechanisms: the application uses dns_get_record() for initial host validation, but the subsequent HTTP request relies on curl's internal resolver (gethostbyname()). This architectural weakness allows an attacker to manipulate DNS responses between the validation check and the actual request, effectively bypassing internal IP address restrictions.

Critical Impact

Authenticated attackers can bypass internal IP restrictions to scan internal network ports, confirm the existence of internal hosts, and interact with internal HTTP-based services.

Affected Products

• EspoCRM versions 9.3.3 and below

Discovery Timeline

• 2026-04-13 - CVE-2026-33659 published to NVD
• 2026-04-14 - Last updated in NVD database

Technical Details for CVE-2026-33659

Vulnerability Analysis

This SSRF vulnerability exploits a fundamental weakness in the application's hostname validation logic. The security mechanism attempts to prevent requests to internal network resources by checking the resolved IP address against a blocklist of internal IP ranges. However, the validation occurs at a different point in time than the actual HTTP request, creating a TOCTOU race condition that can be exploited through DNS rebinding techniques.

A secondary vulnerability compounds this issue: when DNS resolution fails (due to DNS failure, IPv6-only domains, or non-existent hostnames), the validation logic implicitly allows the host without performing additional security checks. This empty DNS result bypass provides an alternative attack vector that doesn't require sophisticated DNS rebinding infrastructure.

The vulnerability requires authentication, as the affected endpoint requires default attachment creation access. While the impact is limited to information disclosure and internal network reconnaissance (data extraction from binary protocol services and remote code execution are not possible through this endpoint), it still represents a significant security boundary violation.

Root Cause

The root cause is a Time-of-Check Time-of-Use (TOCTOU) race condition classified under CWE-367. The application performs hostname-to-IP resolution twice using different resolvers:

1. Validation phase: Uses PHP's dns_get_record() function to resolve the hostname and check if the resulting IP is an internal address
2. Request phase: Uses curl's internal resolver (gethostbyname()) to resolve the same hostname for the actual HTTP request

Because these are separate DNS lookups occurring at different times, an attacker controlling a DNS server can return a legitimate external IP during validation and then quickly switch to returning an internal IP (such as 127.0.0.1 or 192.168.x.x) before the curl request resolves the hostname. The additional flaw of accepting empty DNS results without proper error handling exacerbates the vulnerability.

Attack Vector

The attack leverages DNS rebinding, a technique where an attacker controls a DNS server that alternates between returning different IP addresses for the same domain name. The attack flow is as follows:

1. The attacker sets up a malicious domain with a very low TTL (Time-to-Live) DNS record
2. The attacker authenticates to EspoCRM with standard user credentials that include attachment creation privileges
3. The attacker sends a request to POST /api/v1/Attachment/fromImageUrl with their malicious domain URL
4. During the first DNS lookup (validation), the malicious DNS server returns a legitimate external IP address, passing the security check
5. By the time curl makes its request and performs a second DNS lookup, the malicious DNS server returns an internal IP address (e.g., 192.168.1.1, 10.0.0.1, or 127.0.0.1)
6. The HTTP request is now directed at an internal service, bypassing the intended security controls

Through this technique, attackers can perform internal network reconnaissance, identify active hosts and open ports, and potentially interact with internal HTTP services that should not be accessible from the application layer.

Detection Methods for CVE-2026-33659

Indicators of Compromise

• Unusual outbound requests from the EspoCRM server to internal IP ranges (e.g., 127.0.0.0/8, 10.0.0.0/8, 172.16.0.0/12, 192.168.0.0/16)
• Multiple requests to the /api/v1/Attachment/fromImageUrl endpoint with domains that have very low TTL values
• DNS resolution logs showing the same hostname resolving to different IP addresses in quick succession
• Error logs indicating failed connections to internal services from the attachment processing component

Detection Strategies

• Monitor web application logs for POST requests to /api/v1/Attachment/fromImageUrl with suspicious or unfamiliar domain names
• Implement network-level monitoring to detect outbound connections from the CRM server to internal network segments that shouldn't be accessed
• Deploy DNS monitoring to identify requests for domains with unusually low TTL values (sub-second or single-digit seconds)
• Configure intrusion detection systems to alert on patterns consistent with SSRF scanning behavior

Monitoring Recommendations

• Enable detailed logging for the EspoCRM attachment creation functionality
• Set up alerts for any HTTP requests originating from the EspoCRM server targeting internal RFC 1918 addresses
• Monitor for authentication attempts followed by rapid attachment URL requests, which may indicate automated exploitation
• Review DNS query logs from the EspoCRM server for patterns of repeated lookups to the same unusual domains

How to Mitigate CVE-2026-33659

Immediate Actions Required

• Upgrade EspoCRM to version 9.3.4 or later immediately, as this release contains the security fix
• Audit user accounts with attachment creation permissions and restrict access to only those who require it
• Review application logs for any evidence of exploitation attempts targeting the /api/v1/Attachment/fromImageUrl endpoint
• Consider implementing network segmentation to limit the EspoCRM server's ability to reach sensitive internal services

Patch Information

EspoCRM has released version 9.3.4 which addresses this vulnerability. The fix is documented in the GitHub Security Advisory GHSA-6m4j-fwrx-crh7 and implemented in commit dca03cc3458e487362c26c746378a2d4de9990b1. The release notes for version 9.3.4 are available on GitHub.

Workarounds

• If immediate patching is not possible, consider temporarily disabling the image-from-URL attachment feature at the web server or application firewall level
• Implement egress filtering at the network level to prevent the EspoCRM server from initiating connections to internal network ranges
• Use a web application firewall (WAF) to block or rate-limit requests to the /api/v1/Attachment/fromImageUrl endpoint
• Review and restrict attachment creation permissions to minimize the number of users who can potentially exploit this vulnerability

# Example nginx configuration to block the vulnerable endpoint temporarily
location /api/v1/Attachment/fromImageUrl {
    deny all;
    return 403;
}