Loading vulnerability…
EspoCRM is an open source customer relationship management application. Versions 9.3.3 and below have an authenticated Server-Side Request Forgery (SSRF) vulnerability that allows bypassing 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 is caused by HostCheck::isNotInternalHost() function relying on PHP's filter_var(..., FILTER_VALIDATE_IP), which does not recognize alternative IP formats, causing the validation to fall through to a DNS lookup that returns no records and incorrectly treats the host as safe, however the cURL subsequently normalizes the address and connects to the loopback destination. Through the confirmed /api/v1/Attachment/fromImageUrl endpoint, an authenticated user can force the server to make requests to loopback-only services and store the fetched response as an attachment. This vulnerability is distinct from CVE-2023-46736 (which involved redirect-based SSRF) and may allow access to internal resources reachable from the application runtime. This issue has been fixed in version 9.3.4.
Mallory correlates every CVE against your assets, your vendors, and active adversary campaigns. Know which vulnerabilities matter for you, not just which ones are loud.
1 valid exploit after Mallory filtered fakes, detection scripts, and README-only repos (1 hidden).
This repository is a small, focused exploit PoC for CVE-2026-33534 affecting EspoCRM 9.3.3. It contains one Python exploit script, a README, and a license file. The main script, CVE-2026-33534.py, is a standalone authenticated SSRF verification tool that targets EspoCRM's /api/v1/Attachment/fromImageUrl endpoint. It logs in using HTTP basic/session auth via the requests library, submits a control request using direct 127.0.0.1, and then retries with multiple alternative IPv4 loopback encodings that may bypass the application's loopback filtering while still resolving to localhost on the server side. The exploit's core capability is to make the EspoCRM server fetch internal resources and store them as attachments, thereby confirming SSRF. By default it targets the application's own loopback listener and fetches /client/img/logo-light.svg, but the operator can change the internal port and path to probe other internal services. Successful responses are identified by HTTP 200 plus a returned attachment id. The script can optionally stop on first success and can clean up by deleting created attachments through /api/v1/Attachment/{attachment_id}. Repository structure is minimal: the Python file contains all exploit logic, argument parsing, payload generation, request handling, success detection, and cleanup; README.md documents affected/fixed versions, requirements, usage examples, default payloads, and expected output; LICENSE is standard MIT. This is a real exploit PoC rather than a mere detector because it actively triggers the vulnerable server-side fetch behavior and can create artifacts on the target system, though it does not deliver code execution or a shell payload.
Products and vendors Mallory has correlated with this vulnerability. Open in Mallory to drill down to specific CPE configurations and version ranges.
Vendor-confirmed product mapping. Mallory continuously reconciles this list against your asset inventory.
1 sources tracked across advisories, community write-ups, and news. New activity surfaces here as Mallory finds it.
Query your assets running an affected version, and investigate the blast radius.
Every observed campaign linking this CVE to a named adversary.
Malware families riding this exploit, with evidence and IOCs.
YARA, Sigma, Snort, and vendor rules, auto-deployed to your SIEM.
Cross-references every affected SKU, including bundled OEM variants.
Community discussion across Reddit, Mastodon, and other social sources.