CVE-2026-23478 is a critical flaw (CVSS 9.8) in Cal.com, the open source scheduling software. A custom NextAuth JWT callback lets attackers gain full authenticated access to any user's account by supplying a target email address through session.update(). Versions 3.1.6 up to before 6.0.7 are affected, and 6.0.7 fixes it.
What's affected
Cal.com versions from 3.1.6 up to, but not including, 6.0.7 are affected. The fixed version is 6.0.7.
This matters most for people who self host Cal.com, because they control when updates reach their deployment. The advisory says Cal.com hosted deployments were patched immediately on discovery, and that the vendor has no indication of exploitation. It also says two factor authentication and external identity providers do not prevent the attack, so those controls are not a substitute for the upgrade.
Because the attack gives access to any user's account, admins, team owners and anyone with connected calendars are in scope, along with the booking data and integrations tied to them.
How to check if you're exposed
Find the version of your deployment: the tag or commit you built from, the image tag you run, or the version in the repository's package files.
git describe --tags
docker image ls | grep -i cal
If it falls in the 3.1.6 to 6.0.6 range, plan an upgrade now. After upgrading, review your user list for accounts or sessions you do not recognize, and review connected calendar and video integrations.
What to do now
- Upgrade Cal.com to 6.0.7 or later and redeploy.
- Rotate the NextAuth secret so existing session tokens stop being valid.
- Review account activity, changed emails, new API keys and new integrations.
- Ask users to check their connected calendars and revoke tokens they do not recognize.
- Put the instance behind a monitoring alert for unusual sign ins.
Why it matters
The record lists CWE-602 (Client-Side Enforcement of Server-Side Security) and CWE-639 (Authorization Bypass Through User-Controlled Key). The callback trusted a value sent from the client side, an email address, to decide whose identity the session should carry. When a server accepts the client's claim about who it is, the client can claim to be anyone.
Authentication code that customizes a framework deserves careful review, because the framework's own checks no longer apply to the custom path. The safe pattern is to derive identity from verified, server side data and never from what a request says about itself. Rotating the signing secret is a sensible cleanup step after a flaw like this, because tokens minted by an attacker would otherwise stay valid. The record does not mark this CVE as exploited in the wild.
Try it yourself
Click through it at your own pace, or open it full screen.
Quick check
Who is most at risk?
Self hosted deployments in the affected range, since any user account can be targeted.
Why rotate the secret after upgrading?
It invalidates existing session tokens, including any an attacker may have created.
Sources
Last reviewed: 19 October 2026.
