Cal.com Flaw Lets Attackers Bypass MFA With Fake TOTP Codes

Cal.com has patched a critical authentication bypass that allowed attackers to take over any user account by exploiting a flaw in how the scheduling platform handles TOTP codes. The vulnerability essentially defeated multi-factor authentication, reducing it to single-factor protection.

The bug affects Cal.com versions 3.1.6 through 6.0.6. Organizations running self-hosted Cal.com deployments should update to version 6.0.7 immediately.

The Authentication Logic Flaw

The vulnerability exists in Cal.com's NextAuth JWT callback, which handles user authentication. When a login request includes a TOTP code—the six-digit number from an authenticator app—the system was supposed to verify both the password and the TOTP.

It didn't.

A conditional statement in the authentication flow (lines 179-187 of the relevant file) checked whether a user had a password hash and whether a TOTP code was provided. The logic was flawed: when totpCode was present in the request, the condition evaluated in a way that skipped password verification entirely.

An attacker could supply any TOTP code along with a target's email address. The system would attempt to validate only the TOTP—and since the attacker wasn't actually enrolled in MFA for that account, the validation would fail differently than expected, sometimes granting access.

In practice, this meant MFA made accounts more vulnerable, not more secure. Attackers could authenticate to accounts that had MFA enabled using methods that wouldn't work against basic password-only accounts.

Who Is Affected

The vulnerability primarily impacts users who haven't enabled two-factor authentication—the majority of Cal.com's user base. But the flaw's existence in the TOTP handling code means accounts with MFA enabled weren't protected either.

Successful exploitation exposes:

• Calendar data: Meeting schedules, participant information, event details
• Scheduling links: The URLs that Cal.com generates for booking appointments
• Connected integrations: Calendar sync with Google, Outlook, and other services
• Personal information: Names, email addresses, and any data shared through the platform

For organizations using Cal.com for customer-facing scheduling, account compromise could enable impersonation, unauthorized meeting access, or social engineering using legitimate scheduling infrastructure.

Session Update Attack Vector

Beyond the TOTP bypass, Cal.com's JWT callback had another issue: attackers could gain authenticated access to any account by manipulating the session.update() function with a target email address. This allowed bypassing the normal authentication flow entirely.

The combination of vulnerabilities made Cal.com's authentication system significantly weaker than it appeared. Users who thought they were protected by MFA were actually exposed to multiple attack vectors.

Patch Information

Cal.com released version 6.0.7 to address the authentication flaws. The patch implements proper verification of both password and TOTP codes in the authentication flow, ensuring MFA operates as designed.

Security advisories with technical details are available through Cal.com's GitHub security repository.

Self-Hosted Deployment Concerns

Cal.com is open-source, and many organizations run self-hosted instances. Unlike the cloud version—where Cal.com can push updates centrally—self-hosted deployments require administrators to manually apply patches.

Organizations running on-premises Cal.com installations should:

1. Check their current version against the affected range (3.1.6 through 6.0.6)
2. Plan an upgrade to 6.0.7 or later
3. Review authentication logs for suspicious activity during the exposure window
4. Consider whether any accounts may have been compromised

The delay between cloud and self-hosted patching creates a window where self-hosted instances remain vulnerable after the fix is publicly known. Attackers who learn about authentication bypasses often target self-hosted deployments specifically because they tend to lag behind on updates.

Broader Lesson

This vulnerability illustrates how MFA implementation bugs can make security worse. The intent was sound—require two factors to authenticate. The implementation created a code path that bypassed the first factor when the second was present.

Authentication systems are notoriously difficult to implement correctly. Even experienced developers make mistakes that seem obvious in hindsight. For security teams, the takeaway is to test authentication flows thoroughly, including edge cases around MFA enrollment and TOTP handling.

For users, it's a reminder that MFA is valuable but not magic. The underlying implementation matters, and even well-intentioned security features can contain flaws.