Cal.com account takeover exposes the cost of broken access control

At a glance

What this is: This is an analysis of a Cal.com account takeover chain that combined signup logic flaws and route exposure to bypass access controls and reach sensitive user and booking data.

Why it matters: It matters because identity and access teams need to treat broken access control as a layered governance failure that can defeat both account protection and API boundary enforcement.

By the numbers:

• 100% of the applications tested were found to have some form of broken access control, according to OWASP cited by Gecko Security.
• Cal.com had nearly 1,000 contributors and aims to connect 1 billion people by 2031, according to Gecko Security.

Context

Broken access control appears when an application checks permissions in one place but leaves another execution path open. In this case, the problem spans signup validation, organisation scoping, and route-level authorization, so the control failure is architectural rather than a single coding mistake.

For identity and access management teams, the important question is not just whether a user can authenticate, but whether every path into user data, admin functions, and internal handlers enforces the same authorization rules. A broken decision in one workflow can reset passwords, move accounts between organisations, and expose sensitive records.

This article is about account takeover and API access exposure in an application used for scheduling, but the underlying lesson applies broadly to human IAM and application authorization programmes. The starting point is typical of modern web applications that rely on multiple validators and middleware layers.

Key questions

Q: What breaks when signup logic treats an existing account as available?

A: When signup logic can mistake an existing verified account for a new one, an attacker can overwrite credentials, reassign tenant membership, and inherit the victim's access. The failure is not just account creation abuse. It is a broken identity boundary that lets an unauthorised party replace the authentic user without triggering a defensive control.

Q: Why do scoped validation and global uniqueness create takeover risk?

A: Because the validator and the database are answering different security questions. If the application checks whether an email exists only inside one tenant, but the write operation targets a globally unique user record, an attacker can pass the check and still update another tenant's account. The mismatch turns a local rule into a cross-tenant takeover path.

Q: What are the signs that route-level authorization is failing?

A: Look for internal handlers, fallback routes, or framework-generated endpoints that behave differently from the main controller path. If a request can bypass middleware and still reach the same object or record, authorization is not consistently enforced. The sign is not just a missing permission check in code. It is any alternate route that exposes protected data.

Q: How should teams test for account takeover paths in multi-tenant apps?

A: Test every workflow that can alter identity state, including signup, invite acceptance, password reset, and organisation transfer, against an account that already exists in another tenant. The point is to prove that no path can overwrite credentials or ownership without explicit authorization. If one path succeeds, the identity boundary is too weak.

Technical breakdown

Signup flow bypasses authorization boundaries

The first failure sits in the signup logic, where organisation membership changed the validation outcome from deny to allow. A user already linked to an organisation was treated as if the email and username were still available, even though an active identity already existed. That is a classic authorization boundary failure: the system used context too narrowly and allowed a new registration flow to overwrite an existing account. In identity terms, the application confused signup eligibility with account existence, which should never be the same question.

Practical implication: treat signup, invite, and account recovery flows as authorization checkpoints, not just UX steps.

Scoped validation and global uniqueness do not mix

The second failure came from a validator that searched only within the attacker's organisation scope, then relied on a globally unique email address later in the workflow. That created an inconsistent trust model: one component asked whether the address existed in this organisation, while the database ultimately answered whether the address existed anywhere. When those assumptions differ, the attacker can pass the front-door check and still target a victim record in another tenant. This is not a mere bug chain; it is a broken tenancy model.

Practical implication: align application-level tenant checks with database uniqueness rules before a credential-changing operation can proceed.

Internal route handlers became direct attack surface

The API exposure shows a different class of control failure. Next.js treated underscore-prefixed files as internal handlers, but the platform exposed them as reachable routes, bypassing middleware that the main entry point had applied. In practice, this meant authorization existed in code but not on the actual request path used by the attacker. That pattern matters because security controls tied to the intended code path do not protect alternate execution routes. The result was broad read and delete access across bookings and calendar objects.

Practical implication: verify authorization at every externally reachable route, not just the primary application entry point.

Threat narrative

Attacker objective: The attacker sought to seize user accounts and then read or modify sensitive scheduling data, calendar integrations, and API-linked secrets.

1. Entry began when the attacker generated a shareable organisation invite link and used it to reach the signup flow with a victim email address.
2. Credential access occurred when the signup and validation logic accepted the request and overwrote the victim's password hash, effectively replacing the legitimate account secret.
3. Escalation followed immediately because the attacker gained the victim's authenticated session and inherited access to bookings, OAuth tokens, API keys, and calendar integrations.
4. Impact was complete account takeover, plus read and modification access to private meetings, attendee metadata, and booking records across the platform.

Breaches seen in the wild

• Gitloker GitHub extortion campaign: Phishing via GitHub notifications tricked developers into authorising malicious OAuth apps; Gitloker then wiped repos and demanded contact.
• DeepSeek database exposure 2025: An unauthenticated DeepSeek ClickHouse database exposed over a million log lines with plaintext chat history and API keys in 2025.

Read and download The State of NHI & AI Agent Breach Report 2026, covering 200+ breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

Broken access control becomes systemic when identity checks disagree across layers: The Cal.com case shows how signup logic, tenancy scoping, and route authorization can each appear defensible in isolation while failing together. That is not a point defect but a control architecture failure. Practitioners should read it as evidence that authorization must be consistent from user entry point to database write path, or the stack will inherit the weakest decision.

Tenant boundaries are only real when the data model and the access model match: A validator that searches only within one organisation but updates a globally unique account record creates a false sense of tenant isolation. The same pattern appears in many multi-tenant SaaS environments where application logic and persistence rules are designed separately. The implication is that tenant-aware access control must be tested against the actual write operation, not just the pre-check.

Route-level authorization failures are a reminder that middleware is not a security boundary by itself: When internal handlers remain reachable outside the intended request path, the application's own structure creates an alternate attack route. That matters for API governance, because many teams assume the primary controller is the only enforcement point. In practice, every public handler, fallback route, and indirect execution path must be covered by the same authorization decision.

Broken access control is an identity governance problem, not just an application bug: The incident spans authentication, authorization, account recovery, and object access in one chain. That makes it relevant to IAM, PAM, and application security teams together, because the same user boundary was compromised at multiple points. The lesson for practitioners is to evaluate access control as a lifecycle control plane rather than as isolated application checks.

Cal.com's failure mode is a useful name for the field: access path divergence: The same identity was treated differently depending on which path evaluated it, which let an attacker use one path to override another. This is a practical label for a recurring problem in distributed applications and a useful lens for code review, threat modelling, and authorization testing. Teams should look for any place where one workflow can create state that another workflow assumes already exists.

What this signals

Access path divergence: The same identity can be judged differently by signup logic, middleware, and database persistence unless teams deliberately align those layers. That is where account takeover and object exposure begin: not with a single missing permission, but with inconsistent enforcement across the request path.

For practitioners, the immediate programme question is whether account-changing flows are tested as security-critical control paths. If password resets, invite acceptance, tenant switching, and internal routes are not covered by the same authorization model, broken access control will remain a recurring exposure rather than an exception.

For practitioners

• Harden signup and invite workflows Require explicit existence checks before any signup path can create or overwrite an account tied to a verified email address. The rule should hold even when the user belongs to an organisation or arrives through an invite token.
• Align tenant checks with write operations Test whether the same tenant scoping logic that gates lookup also protects the database upsert or update that finalises the change. If the write path can target a globally unique identifier, the pre-check is not sufficient.
• Protect internal handlers as public routes Audit framework-generated or underscore-prefixed endpoints as if they were user-facing APIs, and confirm that middleware cannot be bypassed by alternate path access. A protected controller is not enough if another route reaches the same data object.
• Add authorization tests for account overwrite paths Create tests that attempt password reset, account recovery, invite acceptance, and organisation transfer against an already existing account. Each should fail unless the requester is explicitly authorised for that exact identity and tenant.

Key takeaways

• The incident shows that broken access control can cascade from a single signup flaw into full account takeover and broad data exposure.
• The compromise reached bookings, attendee details, OAuth tokens, API keys, and calendar integrations, which demonstrates how wide the blast radius can become when identity checks are inconsistent.
• Teams need to test the same authorization rules across signup, tenancy scoping, persistence, and internal routes, because any mismatch can become a takeover path.

Key terms

• Broken Access Control: Broken access control occurs when a system fails to restrict what an authenticated user, service, or workload can do. The issue often appears as missing checks, inconsistent enforcement, or excessive permissions. It is a structural weakness because attacks exploit the gap between verified identity and permitted action.
• Account Takeover: Account takeover is unauthorized use of a legitimate account after an attacker obtains valid access through stolen credentials, tokens, or trusted integrations. The key security problem is that the resulting activity often looks normal to logs and controls, which makes containment and attribution harder than in a forced-entry breach.
• Direct Object Reference: A direct object reference is a request pattern where an attacker can reach a record or resource by knowing or guessing its identifier. When authorization is weak, the identifier becomes a shortcut to protected data instead of a harmless label, especially in APIs and internal route handlers.
• Authorization Middleware: Authorization middleware is the control layer that inspects a request before the target system acts on it. In container platforms, it should enforce policy on the same body and headers that the runtime will execute, otherwise the decision can diverge from reality and create a bypass.

Deepen your knowledge

NHI governance, identity lifecycle management, and workload identity security are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are building or maturing an IAM programme, it is worth exploring.