CVE-2026-33534: EspoCRM SSRF Vulnerability

CVE-2026-33534 Overview

CVE-2026-33534 is an authenticated Server-Side Request Forgery (SSRF) vulnerability affecting EspoCRM, an open source customer relationship management application. The vulnerability allows authenticated attackers to bypass the internal-host validation logic by using alternative IPv4 representations such as octal notation (e.g., 0177.0.0.1 instead of 127.0.0.1). This enables unauthorized access to internal services and resources reachable from the application runtime.

Critical Impact

Authenticated users can force the EspoCRM server to make requests to loopback-only services and retrieve sensitive information from internal resources, storing the fetched response as an attachment.

Affected Products

• EspoCRM versions 9.3.3 and below

Discovery Timeline

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

Technical Details for CVE-2026-33534

Vulnerability Analysis

This SSRF vulnerability exists in EspoCRM's host validation mechanism, specifically within the HostCheck::isNotInternalHost() function. The flaw allows authenticated attackers to bypass internal host restrictions by exploiting how PHP's filter_var() function handles non-standard IP address formats compared to how cURL normalizes and processes these addresses.

The vulnerability is accessible through the /api/v1/Attachment/fromImageUrl endpoint, which is designed to fetch images from external URLs. When an attacker provides an IP address in octal notation (such as 0177.0.0.1), the validation function fails to recognize it as the loopback address 127.0.0.1. This allows the request to pass validation checks, but cURL subsequently normalizes the address and connects to the actual loopback destination.

This vulnerability is distinct from CVE-2023-46736, which involved redirect-based SSRF techniques. CVE-2026-33534 specifically exploits the discrepancy between PHP's IP validation and cURL's IP normalization behavior.

Root Cause

The root cause lies in the HostCheck::isNotInternalHost() function's reliance on PHP's filter_var(..., FILTER_VALIDATE_IP) for IP address validation. This PHP function does not recognize alternative IP address formats such as octal notation. When an octal-formatted IP address is provided, filter_var() fails to validate it as a proper IP address, causing the validation logic to fall through to a DNS lookup. Since no DNS records exist for the octal-formatted address, the function incorrectly treats the host as safe and allows the request to proceed.

Attack Vector

The attack vector requires network access and valid authentication credentials. An authenticated attacker can exploit the /api/v1/Attachment/fromImageUrl endpoint by submitting a request with an octal-formatted loopback address. The attack flow proceeds as follows:

1. Attacker authenticates to EspoCRM with valid credentials
2. Attacker crafts a request to /api/v1/Attachment/fromImageUrl with a URL containing an octal IP address (e.g., http://0177.0.0.1/internal-service)
3. The HostCheck::isNotInternalHost() function fails to recognize the octal IP as internal
4. cURL normalizes the octal address to 127.0.0.1 and connects to the loopback interface
5. The response from the internal service is stored as an attachment accessible to the attacker

This vulnerability can be used to access internal services, cloud metadata endpoints, or other resources only accessible from the server's local network.

Detection Methods for CVE-2026-33534

Indicators of Compromise

• Unusual requests to the /api/v1/Attachment/fromImageUrl endpoint containing non-standard IP formats
• Attachments created from URLs with octal, hexadecimal, or integer IP address representations
• Server logs showing connections to internal services immediately following attachment creation requests
• Network traffic from the EspoCRM server to internal loopback or RFC 1918 addresses

Detection Strategies

• Implement web application firewall (WAF) rules to detect and block requests containing alternative IP address formats (octal, hexadecimal, integer notation)
• Monitor application logs for requests to /api/v1/Attachment/fromImageUrl with suspicious URL patterns
• Review created attachments for content that appears to originate from internal services or metadata endpoints
• Deploy network monitoring to detect unexpected outbound connections from the CRM server to internal services

Monitoring Recommendations

• Enable detailed logging for all API requests to the Attachment endpoint
• Set up alerts for high-frequency attachment creation activities from single user accounts
• Monitor for any server-side network requests to loopback addresses (127.0.0.0/8) or internal IP ranges
• Review attachment metadata and content periodically for signs of internal data exfiltration

How to Mitigate CVE-2026-33534

Immediate Actions Required

• Upgrade EspoCRM to version 9.3.4 or later immediately
• Audit existing attachments for any that may have been created through exploitation of this vulnerability
• Review user access logs for the /api/v1/Attachment/fromImageUrl endpoint for suspicious activity
• Consider temporarily disabling the attachment-from-URL functionality if immediate patching is not possible

Patch Information

EspoCRM has released version 9.3.4 which addresses this vulnerability. The patch improves the IP address validation logic to properly detect and block alternative IP address formats before processing URL requests. Organizations should upgrade to this version or later as soon as possible.

For more information, see the GitHub Security Advisory GHSA-h7gx-8gwv-7g73 and the EspoCRM 9.3.4 Release.

Workarounds

• Restrict access to the /api/v1/Attachment/fromImageUrl endpoint to trusted administrative users only
• Implement network-level controls to prevent the EspoCRM server from connecting to internal services or the loopback interface
• Deploy a reverse proxy or WAF configured to reject requests containing non-standard IP address formats
• If the image URL import feature is not required, consider disabling it entirely until patching is complete