Cal.com cal.diy CVE-2026-9303

Successful exploitation requires the victim to be authenticated to a cal.diy instance (active session with valid cookies) and to interact with attacker-controlled content (visit malicious page or click forged link) while the session remains valid. The CSRF vulnerability is exploitable in default configurations of cal.diy 4.9.4 and earlier with no special setup required. Attack success depends on the application's session timeout settings and whether users keep persistent sessions. SameSite cookie protections, if implemented via reverse proxy or browser defaults, would mitigate exploitation. The UI:R (user interaction required) constraint means attacks cannot be fully automated - social engineering is necessary. Browsers with strict Referer/Origin policies or CSRF-aware extensions may block some attack variants.

Real-world risk is moderate despite the 4.3 CVSS base score. The CVSS vector shows AV:N (network exploitable), AC:L (low complexity), PR:N (no privileges required to launch), UI:R (user interaction required), with impact limited to integrity (I:L). The E:P (Proof-of-concept exists) temporal metric confirms exploit availability, which is substantiated by two GitHub Gists in the references. However, exploitation requires user interaction - the attacker must socially engineer an authenticated cal.diy user to visit a malicious page or click a forged link while logged in. CVSS scope is unchanged (S:U), meaning the vulnerability cannot pivot to other application components. The RL:X (Remediation Level: unavailable) metric is critical: the vendor was contacted but did not respond, and no patch exists at time of analysis. No KEV listing suggests this is not yet targeted at scale, but the public exploit code makes opportunistic attacks feasible. Organizations running cal.diy 4.9.4 or earlier face persistent risk until vendor engagement occurs. The low confidentiality/availability impact (C:N/A:N) means this cannot directly exfiltrate data or cause service disruption, but integrity modification (I:L) could enable attackers to manipulate calendar entries, modify user settings, or perform administrative actions depending on victim privileges.

An attacker crafts a malicious HTML page containing a hidden form that auto-submits a POST request to a cal.diy instance's vulnerable endpoint (e.g., event creation, user settings modification, or integration authorization). The attacker distributes the page via phishing email or compromised website. When an authenticated cal.diy user visits the malicious page while logged in, their browser automatically sends the forged request with valid session cookies, causing the application to process the action as if the user intentionally initiated it. Public exploit code at https://gist.github.com/YLChen-007/dafada36e356bc895b09829d8ec57e49 provides attackers with a working proof-of-concept, significantly lowering exploitation barrier.