CVE-2026-9304: Cal.com cal.diy SSRF Vulnerability

CVE-2026-9304 Overview

CVE-2026-9304 is a Server-Side Request Forgery (SSRF) vulnerability affecting Cal.com cal.diy releases up to and including version 4.9.4. The flaw resides in the validateUrlForSSRF function within apps/web/app/api/logo/route.ts, which is part of the Logo API component. Attackers can manipulate URL input handled by this validation routine to coerce the server into issuing unintended outbound requests. The vulnerability is classified under CWE-918 and is exploitable remotely. A public proof-of-concept has been released, though the vendor did not respond to disclosure attempts.

Critical Impact

Successful exploitation allows an authenticated remote attacker to issue server-originated HTTP requests to internal or otherwise restricted endpoints through the Logo API.

Affected Products

• Cal.com cal.diy versions up to 4.9.4
• Logo API component (apps/web/app/api/logo/route.ts)
• Deployments exposing the validateUrlForSSRF code path

Discovery Timeline

• 2026-05-23 - CVE-2026-9304 published to NVD
• 2026-05-26 - Last updated in NVD database

Technical Details for CVE-2026-9304

Vulnerability Analysis

The vulnerability is a Server-Side Request Forgery (SSRF) issue in the Cal.com cal.diy Logo API. The validateUrlForSSRF function in apps/web/app/api/logo/route.ts is responsible for filtering user-supplied URLs before the server fetches remote logo resources. The validation logic fails to fully block requests targeting internal address spaces or restricted protocols. As a result, an attacker with low-privilege access can submit a crafted URL that bypasses the filter, causing the server to perform an attacker-controlled request. The advisory notes that exploitation is complex and described as difficult, which is reflected in the low CVSS 4.0 base score. Impact remains limited to low confidentiality, integrity, and availability effects on the application itself.

Root Cause

The root cause is insufficient validation inside validateUrlForSSRF. URL parsing and allow-list enforcement do not reliably reject requests that resolve to internal hosts, loopback addresses, link-local ranges, or non-HTTP schemes. Logic gaps allow malformed or DNS-rebinding-style inputs to pass validation before the outbound fetch occurs.

Attack Vector

The attack vector is network-based and requires low privileges with no user interaction. An authenticated attacker submits a manipulated URL to the Logo API endpoint backed by apps/web/app/api/logo/route.ts. The server then issues an outbound HTTP request to the attacker-specified destination. A public proof-of-concept demonstrating the bypass is available in the GitHub Gist PoC Repository and further documented in VulDB #365251. No verified exploitation code is reproduced here; refer to the linked references for the technical proof-of-concept.

Detection Methods for CVE-2026-9304

Indicators of Compromise

• Outbound HTTP requests from the cal.diy application server to RFC1918, loopback, or link-local addresses originating from the Logo API worker
• Unusual User-Agent values associated with the Next.js fetch client targeting internal metadata services such as 169.254.169.254
• Repeated POST or GET requests to the /api/logo route with URL parameters containing encoded internal hostnames or non-HTTP schemes

Detection Strategies

• Inspect application access logs for /api/logo requests with URL parameters resolving to private IP ranges or unexpected ports
• Correlate egress firewall logs with application request IDs to detect server-originated traffic to internal services
• Alert on DNS resolutions made by the application process that return private or reserved IP addresses

Monitoring Recommendations

• Forward Cal.com application and reverse-proxy logs to a centralized analytics pipeline for query against SSRF patterns
• Monitor cloud metadata endpoint access from application workloads, which is a common SSRF objective
• Track changes to the validateUrlForSSRF function across deployments to confirm patched code is in production

How to Mitigate CVE-2026-9304

Immediate Actions Required

• Identify all cal.diy instances at or below version 4.9.4 and prioritize patching
• Restrict outbound network access from the cal.diy application tier to only the domains required for logo fetching
• Require authentication and rate-limit the /api/logo endpoint to reduce abuse surface

Patch Information

The vendor was contacted but did not respond to the disclosure according to the VulDB advisory. Operators should track the Cal.com repository for updated releases beyond 4.9.4 that revise validateUrlForSSRF. Until an official patch is confirmed, apply compensating controls at the network and application layers.

Workarounds

• Place an egress proxy in front of the application that enforces an allow-list of destination domains for logo fetches
• Block traffic from the application workload to RFC1918, loopback, link-local, and cloud metadata IP ranges at the host or network firewall
• Disable the Logo API route if the feature is not required in the deployment
• Add a reverse-proxy rule that rejects /api/logo requests where the supplied URL parameter does not match an allow-listed pattern

# Example egress restriction using iptables to block cloud metadata and private ranges
# from the cal.diy application user (replace 'caldiy' with the actual service user)
iptables -A OUTPUT -m owner --uid-owner caldiy -d 169.254.169.254 -j REJECT
iptables -A OUTPUT -m owner --uid-owner caldiy -d 10.0.0.0/8       -j REJECT
iptables -A OUTPUT -m owner --uid-owner caldiy -d 172.16.0.0/12    -j REJECT
iptables -A OUTPUT -m owner --uid-owner caldiy -d 192.168.0.0/16   -j REJECT
iptables -A OUTPUT -m owner --uid-owner caldiy -d 127.0.0.0/8      -j REJECT