Summary
Cal.com OSS contains a broken authorization flaw in its team webhook creation flow, allowing authenticated users to inject arbitrary teamIds and bind webhooks to teams they do not belong to.
Once a webhook is attached to a victim team, the attacker can receive booking payloads and siphon sensitive data such as organizer and attendee emails, custom form responses, and in some cases video call passwords when bookings are created.
Cal.com OSS contains a broken authorization flaw in its team webhook creation flow, allowing authenticated users to inject arbitrary teamIds and bind webhooks to teams they do not belong to.
Once a webhook is attached to a victim team, the attacker can receive booking payloads and siphon sensitive data such as organizer and attendee emails, custom form responses, and in some cases video call passwords when bookings are created.
Affected context
This vulnerability occurs in deployments where Cal.com is exposed to multiple authenticated users across different teams and where webhook configuration is available through an API or UI.
It manifests specifically in the webhook creation endpoint that accepts a teamId parameter without consistently verifying the caller's membership or authorization for that team.
Environments that rely on webhooks to forward booking events to external systems are particularly affected, as booking payloads can be redirected to attacker-controlled endpoints.
This vulnerability occurs in deployments where Cal.com is exposed to multiple authenticated users across different teams and where webhook configuration is available through an API or UI.
It manifests specifically in the webhook creation endpoint that accepts a teamId parameter without consistently verifying the caller's membership or authorization for that team.
Environments that rely on webhooks to forward booking events to external systems are particularly affected, as booking payloads can be redirected to attacker-controlled endpoints.
Exploit preconditions
- Attack surface: Cal.com webhook creation API/UI for team resources
- Required access: Any authenticated user account on the Cal.com instance
- Trigger point: Submission of a webhook creation request containing a forged or arbitrary teamId value
- Why exploitation is possible: The backend trusts the provided teamId without enforcing ownership or role checks, so webhooks are created for teams outside the attacker's scope, causing booking events to be delivered to attacker-controlled endpoints
- Attack surface: Cal.com webhook creation API/UI for team resources
- Required access: Any authenticated user account on the Cal.com instance
- Trigger point: Submission of a webhook creation request containing a forged or arbitrary teamId value
- Why exploitation is possible: The backend trusts the provided teamId without enforcing ownership or role checks, so webhooks are created for teams outside the attacker's scope, causing booking events to be delivered to attacker-controlled endpoints
Why this happens
The root cause is inadequate authorization on a multi-tenant resource operation, mapping directly to CWE-639 (Authorization Bypass Through User-Controlled Key).
The server-side logic accepts a caller-supplied teamId and uses it to associate newly created webhooks with that team, but fails to validate that the requester is a member or administrator of the specified team.
This pattern breaks the expected separation between teams, allowing one tenant to influence another tenant's configuration and consume their event data through improperly guarded indirect object references.
The root cause is inadequate authorization on a multi-tenant resource operation, mapping directly to CWE-639 (Authorization Bypass Through User-Controlled Key).
The server-side logic accepts a caller-supplied teamId and uses it to associate newly created webhooks with that team, but fails to validate that the requester is a member or administrator of the specified team.
This pattern breaks the expected separation between teams, allowing one tenant to influence another tenant's configuration and consume their event data through improperly guarded indirect object references.
Potential impact
- Attacker may receive booking payloads from victim teams via their own webhook endpoints
- Attacker could access organizer and attendee email addresses, names, and scheduling metadata
- Attacker can obtain custom booking responses, potentially including sensitive business or personal information
- In some configurations, attacker may collect video-call passwords or joining details for scheduled meetings
- Attacker could aggregate booking data to profile users, perform targeted phishing, or undermine confidentiality agreements
- Attacker may receive booking payloads from victim teams via their own webhook endpoints
- Attacker could access organizer and attendee email addresses, names, and scheduling metadata
- Attacker can obtain custom booking responses, potentially including sensitive business or personal information
- In some configurations, attacker may collect video-call passwords or joining details for scheduled meetings
- Attacker could aggregate booking data to profile users, perform targeted phishing, or undermine confidentiality agreements
General mitigation guidance
Effective mitigation focuses on enforcing strict authorization for all operations involving tenant-scoped identifiers and webhook configuration.
Common defensive patterns include:
- Validating that the authenticated user is a member or has an appropriate role for the team referenced by any teamId in requests
- Avoiding direct trust of user-provided identifiers; instead derive team context from a session or ownership mapping whenever possible
- Centralizing access control checks in shared middleware or service layers to reduce inconsistent enforcement
- Applying least-privilege principles so only designated roles can create or modify webhooks and other data-exfiltration mechanisms
- Auditing and limiting the sensitive fields included in webhook payloads, especially secrets like meeting passwords
Effective mitigation focuses on enforcing strict authorization for all operations involving tenant-scoped identifiers and webhook configuration.
Common defensive patterns include:
- Validating that the authenticated user is a member or has an appropriate role for the team referenced by any teamId in requests
- Avoiding direct trust of user-provided identifiers; instead derive team context from a session or ownership mapping whenever possible
- Centralizing access control checks in shared middleware or service layers to reduce inconsistent enforcement
- Applying least-privilege principles so only designated roles can create or modify webhooks and other data-exfiltration mechanisms
- Auditing and limiting the sensitive fields included in webhook payloads, especially secrets like meeting passwords
How teams detect issues like this
Detection typically involves a mix of code-level and behavioral analysis:
- Static analysis and manual code review to identify endpoints that accept user-controlled teamId or similar identifiers without explicit authorization checks
- Verifying that all multi-tenant operations use centralized access control routines rather than custom per-endpoint logic
- Implementing logging around webhook creation, changes, and unusually broad team associations, then alerting on patterns such as cross-team bindings or high-volume webhook registrations
- Periodic access control testing, including automated security tests that attempt arbitrary teamId injection to confirm enforcement
Detection typically involves a mix of code-level and behavioral analysis:
- Static analysis and manual code review to identify endpoints that accept user-controlled teamId or similar identifiers without explicit authorization checks
- Verifying that all multi-tenant operations use centralized access control routines rather than custom per-endpoint logic
- Implementing logging around webhook creation, changes, and unusually broad team associations, then alerting on patterns such as cross-team bindings or high-volume webhook registrations
- Periodic access control testing, including automated security tests that attempt arbitrary teamId injection to confirm enforcement
Sources
| Source | Link |
|---|---|
| github. | github.com/ |
| vokecyber. | vokecyber.com/ |
