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

At a glance

What this is: Gecko Security’s research shows how three chained access-control flaws in Cal.com Cloud enabled full account takeover and exposure of booking data.

Why it matters: IAM, NHI, and application security teams need to treat authentication bypass and object-level authorization as linked controls, because chained failures can collapse both account integrity and data isolation at once.

By the numbers:

• 100% of the applications tested were found to have some form of broken access control.
• Only 44% of developers are reported to follow security best practices for secrets management, exposing a significant developer behaviour gap.

👉 Read Gecko Security's analysis of the Cal.com account takeover chain

Context

Broken access control is not just an application bug class, it is an identity governance failure when authentication, authorization, and object ownership are not enforced consistently across flows. In this case, a signup path, org-scoped validation, and an upsert operation combined to let one user overwrite another user’s credentials and organization membership.

For identity practitioners, the lesson is that account lifecycle, session trust, and object-level access decisions cannot be treated as separate layers. A system can look secure at the login edge and still fail catastrophically when downstream handlers, hidden routes, or scoped queries do not preserve the same authorization boundary.

This is a typical failure pattern in modern SaaS systems that mix developer-friendly APIs with layered frameworks and multiple trust boundaries. The primary control problem is not complexity alone, but inconsistent enforcement across the full request path.

Key questions

Q: What breaks when signup validation can be bypassed in a multi-tenant app?

A: A bypass in signup validation can let an attacker overwrite an existing account instead of creating a new one. In multi-tenant systems, the risk is amplified when tenant-scoped checks are used for global identity attributes like email. The result can be credential reset, tenant reassignment, and silent takeover of the victim’s account state.

Q: Why do broken access controls create such large identity risks?

A: Because access control is often the last boundary between a user’s session and the records that define account ownership, authentication state, and data visibility. If that boundary fails on one route or object type, attackers can move from ordinary authenticated access to credential manipulation, data exposure, or destructive actions.

Q: How do security teams find object-level authorization failures?

A: They need to test every method and route variant against the same record under different users, tenants, and roles. Manual testing should include direct requests to internal handlers, not only the intended UI path. If a request can reach a record without proving ownership, the authorization model is incomplete.

Q: Who is accountable when account takeover happens through a chained application flaw?

A: Accountability usually spans application owners, platform engineers, and identity governance leads, because the failure crosses authentication, authorization, and persistence layers. Frameworks such as the NIST Cybersecurity Framework and OWASP guidance make clear that identity controls must be enforced consistently across the full request path, not only at login.

Technical breakdown

Authentication bypass in invite-based signup flows

Invite-based signup flows often assume the token proves both intent and entitlement. In this case, username and email validation were allowed to pass for existing users under certain organization conditions, which meant the signup flow could proceed even when a verified account already existed. The problem is structural: the flow treated membership scope as a proxy for identity existence, which is unsafe when email uniqueness and account ownership are global properties. Once validation is scoped incorrectly, the rest of the workflow can become an overwrite path instead of an onboarding path.

Practical implication: validate account existence before any signup or password-reset path can reach state-changing operations.

Scoped validation and global identity mismatches

A common failure mode in multi-tenant systems is asking whether a user exists inside one tenant when the security question is whether the identity exists anywhere. When validation queries are filtered by organization before checking verified users, the code can mistakenly treat an existing account as available. That mismatch between tenant scope and identity scope is what creates room for credential overwrite. The issue is especially dangerous when downstream logic later assumes global uniqueness for email or username while earlier checks treated those fields as tenant-local.

Practical implication: align tenant-scoped checks with global identity rules before any credential mutation is allowed.

Hidden route handlers and direct object access

Framework internals can become public attack surface when direct route access bypasses the middleware that normally protects them. In this case, underscore-prefixed handlers were meant to be internal, but direct requests reached them without the authorization layer applied at the main entry point. That is a classic object-level authorization failure, not just a routing mistake. Once a user can directly call a handler that was intended to be internal-only, the application loses the boundary between authenticated access and authorized access, which is where bookings, calendars, and other user records become exposed.

Practical implication: block direct access to internal handlers and test object-level authorization on every route variant.

Threat narrative

Attacker objective: The attacker’s objective was to seize the victim’s account and inherit access to all associated bookings and integrations.

1. Entry through an invite-token signup flow let the attacker present a valid-looking request against Cal.com Cloud and reach credential-changing logic.
2. Credential overwrite occurred when org-scoped validation missed an existing verified user and the global upsert matched the victim’s email address.
3. Escalation followed immediately because the attacker-controlled password and organization membership replaced the victim’s account state.
4. Impact was complete account takeover with access to bookings, attendee metadata, OAuth tokens, API keys, and calendar integrations.

Breaches seen in the wild

• 230M AWS environment compromise — 230M AWS environments compromised via exposed .env files with cloud credentials.
• MongoBleed breach — MongoBleed exposed secrets across 87K MongoDB servers.

Read our 52 NHI Breaches Analysis report for a comprehensive view of breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

Broken access control becomes identity compromise when the same user record can be both identity proof and overwrite target. The Cal.com chain shows that authorization failures are not isolated application defects when they can alter passwords, organization membership, and session trust in one transaction. For identity teams, the practical conclusion is that account state changes need the same control scrutiny as login itself.

Tenant-scoped validation is the wrong security model when the identity asset is globally unique. The article exposes a governance assumption that email or username checks can be safely localized to one organization. That assumption fails as soon as one tenant can modify a record owned by another tenant, which means identity scope and data scope must be validated as one boundary.

Internal route exposure is a control boundary failure, not merely a framework quirk. When direct requests can reach underscore-prefixed handlers, middleware-only protection is no longer a reliable authorization model. This is a reminder that application security and IGA are converging problems whenever object-level access determines who can alter identity state or related records.

Chained vulnerabilities are the real governance unit, not individual findings. Each bug in isolation looked survivable, but together they produced account takeover, data access, and silent lockout. Security programmes that triage findings one by one without modelling combined impact will continue to miss the path from minor defect to identity collapse.

Identity blast radius is the right named concept here: a single credential overwrite can expand into bookings, tokens, calendars, and PII in one move. That blast radius is what makes broken access control an identity governance issue, not just an application bug. Practitioners should evaluate whether their systems can prevent one compromised state transition from cascading into every adjacent entitlement.

From our research:

• The average estimated time to remediate a leaked secret is 27 days, despite 75% of organisations expressing strong confidence in their secrets management capabilities, according to The State of Secrets in AppSec.
• Only 44% of developers are reported to follow security best practices for secrets management, exposing a significant developer behaviour gap, according to The State of Secrets in AppSec.
• For a broader control lens, see Ultimate Guide to NHIs , Lifecycle Processes for Managing NHIs for lifecycle controls that limit how far one compromised identity state can spread.

What this signals

The governance lesson is that identity failures now emerge from the interaction of auth flows, persistence layers, and route handling, not from isolated bugs. Teams that still treat application security as separate from identity governance will miss the point at which a credential overwrite becomes a platform-wide trust failure.

Identity blast radius: this is the programmatic risk signal practitioners should watch. Once a single record update can alter password state, tenant assignment, and downstream access, the issue is no longer a vulnerability ticket, it is a control-design failure that should be reviewed alongside Top 10 NHI Issues and the OWASP Non-Human Identity Top 10.

For identity and platform teams, the practical move is to test whether any internal handler, scoped query, or state-changing operation can be reached with a valid but untrusted request. That is the boundary where application logic, IAM policy, and tenancy enforcement stop being separate disciplines and become one control surface.

For practitioners

• Map credential-changing code paths end to end Trace every signup, reset, invite, and upsert path to confirm that an existing verified identity cannot be overwritten by a new request in any tenant context.
• Enforce global identity checks before tenant checks Treat verified email existence, username ownership, and account recovery as global identity properties before applying any organization-scoped logic.
• Block direct access to internal handlers Add routing and middleware tests for underscore-prefixed or internal endpoints so direct requests cannot bypass authorization middleware.
• Test object-level authorization on every API method Verify that read, update, patch, and delete operations each enforce record ownership, not just the top-level route or session state.
• Model chained failure impact in reviews During security review, ask what happens if validation, routing, and persistence each fail once, because the combined effect can be account takeover rather than a single bug.

Key takeaways

• This incident shows that broken access control can become full identity compromise when validation, routing, and persistence are chained together.
• The scale of impact was severe enough to expose bookings, attendee metadata, OAuth tokens, API keys, and complete account state.
• The control that would have mattered most is consistent object-level authorization across every route and every account mutation 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.
• Broken Object-Level Authorization: A failure to check whether an authenticated identity may access a specific object, record, or device. The request succeeds because the credential is valid, but the application does not enforce per-object entitlement. In NHI environments, this turns a legitimate token into cross-resource exposure.
• Identity Blast Radius: The amount of damage a compromised identity can cause across systems, data, and infrastructure. In NHI environments, it is shaped by permissions, network reach, and administrative capability rather than by the credential alone. Reducing blast radius is a containment strategy that limits lateral movement and data exposure.

What's in the full article

Gecko Security's full post covers the operational detail this post intentionally leaves for the source:

• Line-by-line exploit chains for the signup bypass and account overwrite path
• Code excerpts showing where org-scoped validation diverged from global identity checks
• Request-path and middleware details for the exposed internal route handlers
• Patch notes and the specific fix Cal.com applied in v6.0.8

👉 The full Gecko Security post covers the exploit chain, code paths, and remediation details

Deepen your knowledge

NHI governance, agentic AI identity, and machine identity lifecycle 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.