The honest one-paragraph answer

Cal.com is a legitimate, certified platform (SOC 2 Type II, ISO 27001, GDPR/CCPA/HIPAA listed on its own security page — captured below) that also had a very bad month in early 2026: in January, security firm Gecko found three chained access-control flaws that allowed taking over any account and exposing millions of bookings. They were patched in v6.0.8 and disclosed, and they were the proximate reason Cal.com made one of 2026’s most-discussed architecture decisions — going closed source in April. Whether that makes Cal.com “safe” depends on which risk model you use, so this page keeps the two threads separate: what actually happened, and what’s verifiably true today. We state only announced facts and our own observations; no “secure!” or “unsafe!” verdict.

Thread 1: the January 2026 vulnerabilities (real, patched, disclosed)

  • What: three chained access-control vulnerabilities in Cal.com Cloud — missing endpoint access controls plus IDOR — that together allowed complete account takeover of any user, with millions of bookings and their PII reachable. Found January 26, 2026 by Gecko Security’s AI-driven SAST engine. (Per Gecko’s own write-up and AlphaSignal’s April 17, 2026 analysis; dates cross-checked.)
  • Fix status: Cal.com shipped the patch in v6.0.8. The version banner we captured during our hands-on test on August 31 read v6.8.6-h, i.e. the production platform was running well past the fixed version during our entire test.
  • Scope note (matters a lot): the flaws were demonstrated against Cal.com Cloud and self-hosted instances of the then-open code. If you self-hosted an old version, the exposure math is different than if you always used cal.com.

Thread 2: went closed source in April 2026 — and what they said why

On April 14, 2026, CEO Bailey Pumfleet announced in Cal.com’s own blog (“Cal.com Goes Closed Source: Why AI Security Is Forcing Our Decision”) that the production codebase moved to a private repository after five years open source, citing AI-driven scanning of public code as making openness “like handing attackers the blueprints to the vault.” The engineering follow-up (April 15, by Keith Williams, “Going Closed-Source: Technical Changes Behind Cal.diy”) documents the rewrite of authentication and billing for the production system, and how security fixes were backported between repos before the split (including critical CVE upgrades in axios/handlebars and SSRF/CSRF hardening). Independent coverage at the time also noted the announcement’s headline claim — that open source makes code 5–10× easier to exploit — has no published study behind it (AlphaSignal, Apr 17).

What that leaves verifiable today: the community edition Cal.diy is MIT-licensed (we pulled the LICENSE text from the public repo) but strips team management, workflows and analytics; the production platform’s code is no longer auditable by the public — the flip side of the same decision.

What’s verifiably true on the security page (captured 2026-09-02)

cal.com/security states Cal.com has achieved ISO 27001 and SOC 2 Type II, with downloadable SOC 2 report, ISO 27001 certificate, and penetration-test report links on the page (access typically gated behind a form), plus CCPA, GDPR and HIPAA posture and a published vulnerability-disclosure program. We captured the page; we did not open the gated PDFs. A vendor’s own certification claims are meaningful but are still vendor claims — the download links at least make them checkable, which is more than most scheduling tools publish.

What we observed hands-on (2026-08-31 run, free plan)

Security-adjacent observations from our full hands-on test, none of which are “vulnerabilities” but all relevant to how the product guards itself:

  • Signup is bot-hostile on purpose: email/password signup sits behind a Cloudflare interactive Turnstile that rejected every automated path we tried (error 600010, twice reproduced); Google/Microsoft SSO worked immediately. Good for account safety, mildly annoying for you.
  • Cloudflare sometimes false-blocks real users: our second test booking’s confirmation page was intermittently blocked (1 of 2 visits), meaning a visitor could lose sight of their own meeting link until reload — an availability annoyance, not a data exposure.
  • Visitor email validation is real: fake domains were rejected server-side (HTTP 400, “email address cannot receive mail”) — spam-resistant bookings.
  • Cancel flows require the logged-in owner: our scripted cancel attempts had to go through the owner’s session and the dropdown/confirmation flow; bookings did not vanish from unauthenticated access paths.

Who should think twice

  • Healthcare/legal/finance schedulers: HIPAA and SOC 2 posture is stated and checkable, but you should download their DPA/pen-test artifacts and run them past your compliance owner — not trust a blog post, ours included.
  • Self-hosters: the platform you can actually self-host today is Cal.diy (MIT, feature-stripped); evaluating “Cal.com security” for self-hosting means evaluating Cal.diy, which is a different codebase than the cloud’s auth-rewritten production code.
  • Anyone whose model is “transparency = safety”: closed source removed the option to audit; if that’s a hard requirement, Cal.com no longer qualifies post-April 2026 regardless of its patch record.

Sources: cal.com/security and cal.com/blog/cal-com-goes-closed-source-why (both captured 2026-09-02); cal.com blog technical-changes post (Apr 15, 2026); gecko.security blog (Aug 27, 2026); alphasignalai.substack.com (Apr 17, 2026); our own test log (Aug 31, 2026). See testing methodology.

More of our Cal.com guides: