- Top reward
- $1,500
- Top severity paid
- Critical
- Assets in scope
- 13
- Public CVEs
- 6
- Last change
- No changes yet
At a glance
What to know before you start testing.
- Pays from $1,500
- for critical bugs.
- Report on Sorona
- Submit through the program page.
- Partial safe harbor
- Some legal protection; read the terms.
- Publish after a fix
- Coordinate the timing with the company.
Rewards
What Sorona lists as the payout for each severity.
| Severity | Relative size | Reward |
|---|---|---|
| Critical | $1,500+ | |
| High | $700+ | |
| Medium | $300+ | |
| Low |
|
$100 $100 / 1 month Claude Max |
- Safe harbor
-
Partial
Sorona will not pursue legal action against you for good-faith research submitted to us in line with this policy. We cannot speak for the upstream project, its vendor, or any third party, and we do not grant authorization on their behalf.
- Hall of fame
-
Yes
The policy commits to legal safe harbour, confidentiality and credit by name, and it commits to no payment
Summarised with AI from the program policy on Sorona, read 12 Nov 2026, and checked word for word against it. Read the original
Scope
13 assets you may test, 6 excluded.
Web 1
- https://cal.com
Products and areas 12
- Authentication in full, covering password login, SSO and SAML where configured, session issuance and impersonation features
- Booking creation, rescheduling and cancellation, plus the tokens and links that authorise those actions from an email
- Payment collection for bookings and the provider integrations behind it
- Public booking pages, the anonymous surface of the product, including availability lookup and the data a booking page discloses about a user who never authenticated the visitor
- Team and organisation membership: invitations, roles, and the checks meant to keep one team's bookings and availability out of another's reach
- The API, both the public API keys used by scripted consumers and the internal endpoints the web application calls
- The app store and the installed-app framework, where third-party integrations receive credentials and callbacks
- The calendar integration layer end to end: the OAuth authorisation flow, the storage of refresh tokens and every call the server makes to a connected Google or Microsoft account on a user's behalf
- The embed, which puts Cal.com inside somebody else's page and inherits that page's origin problems
- The published policy takes private reports on Cal.com at [email protected] and pairs them with its own out-of-scope list. Inside that boundary it names no component carve-out, so the application as a whole is the target
- Webhooks and outbound requests the server makes on a user's behalf, including any user-supplied destination URL
- Workflows, reminders and the email and messaging paths that render user-supplied content
Out of scope (6)
- Anything named in the policy's own out-of-scope list, which the project publishes in SECURITY.md and updates independently of this page. Read it first
- Google, Microsoft and other calendar providers' own systems, which are third-party estates rather than Cal.com code
- Self-hosting and deployment configuration choices, including an instance run without the environment variables the documentation requires
- Testing against other users' live booking pages or connected calendars
- Third-party apps in the app store that are not maintained in the Cal.com repository
- Upstream dependency issues, unless Cal.com's own use of the dependency is what makes the defect reachable
Rules
What the policy asks of you, and the bug types it won't reward, quoted from Sorona's policy. "We" in these lines means Sorona, not this site.
While testing
-
Submit through sorona.xyz. This project runs no bounty of its own; we validate, coordinate disclosure with the maintainers, and pay you directly.
-
Report privately through GitHub private vulnerability reporting on calcom/cal.com, or by email to the address on the policy page .
-
Read the policy's own out-of-scope list before filing; it is published in SECURITY.md and the project maintains it independently
-
Say whether you reproduced on the hosted service at cal.com or on a self-hosted deployment.
-
Name the calendar integration involved.
-
Do not test against other people's live booking pages; use your own tenant and your own connected calendars
Summarised with AI from the program policy on Sorona, read 12 Nov 2026, and checked word for word against it. Read the original
Changes
Tracked since 11 Nov 2026. Last checked 1 hour ago.
No changes yet. When the rewards or scope move, you will see it here and in the RSS feed.
Public CVEs
Published vulnerabilities in this vendor's products, from the NVD.
Sorona credits this project with 6 CVEs, 3 of them recent. The individual records appear here after the next sync.
Original policy
Copied from sorona.xyz on 12 Nov 2026. The summaries on this page are made from it; the live page may have changed since.
Skip to content What this pays This project runs no bounty of its own. sorona.xyz pays you directly on qualified, reproduced findings. Severity │ sorona.xyz pays Critical │ $1,500+ High │ $700+ Medium │ $300+ Low │ $100 / 1 month Claude Max Submit a vulnerability CVE history 3 Last 12 months 6 Lifetime Access control 35 % Auth/token handling 30 % Info disclosure 20 % XSS 15 % Latest advisories Loading the feed Overview Cal.com is the open-source scheduling layer teams run in place of Calendly, either on the hosted service or self-hosted next to their own identity provider. To do its job it custodies OAuth refresh tokens for users' Google and Microsoft accounts, so a server-side flaw does not stop at booking data. It reaches the calendar and the mailbox sitting behind that token. The security policy is unusually complete for a project this size, with stated response times, legal safe harbour and credit by name, and it promises no money at any severity. sorona.xyz pays you directly on qualified, reproduced findings. In scope The published policy takes private reports on Cal.com at [email protected] and pairs them with its own out-of-scope list. Inside that boundary it names no component carve-out, so the application as a whole is the target The calendar integration layer end to end: the OAuth authorisation flow, the storage of refresh tokens and every call the server makes to a connected Google or Microsoft account on a user's behalf Public booking pages, the anonymous surface of the product, including availability lookup and the data a booking page discloses about a user who never authenticated the visitor Booking creation, rescheduling and cancellation, plus the tokens and links that authorise those actions from an email Team and organisation membership: invitations, roles, and the checks meant to keep one team's bookings and availability out of another's reach The API, both the public API keys used by scripted consumers and the internal endpoints the web application calls Authentication in full, covering password login, SSO and SAML where configured, session issuance and impersonation features The app store and the installed-app framework, where third-party integrations receive credentials and callbacks Webhooks and outbound requests the server makes on a user's behalf, including any user-supplied destination URL Workflows, reminders and the email and messaging paths that render user-supplied content Payment collection for bookings and the provider integrations behind it The embed, which puts Cal.com inside somebody else's page and inherits that page's origin problems Out of scope Anything named in the policy's own out-of-scope list, which the project publishes in SECURITY.md and updates independently of this page. Read it first Google, Microsoft and other calendar providers' own systems, which are third-party estates rather than Cal.com code Third-party apps in the app store that are not maintained in the Cal.com repository Self-hosting and deployment configuration choices, including an instance run without the environment variables the documentation requires Upstream dependency issues, unless Cal.com's own use of the dependency is what makes the defect reachable Testing against other users' live booking pages or connected calendars Most-valued findings Anything that exposes or reuses a stored OAuth refresh token. That token is the highest-value object in the product because it reaches a user's real calendar and, with the scopes commonly granted, their mail Cross-tenant access on a multi-team instance: reading another organisation's bookings, availability, attendee lists or integration credentials Unauthenticated disclosure through the public booking surface, where availability, attendee identity or event detail leaks to a visitor who is only supposed to see free slots Booking manipulation through a rescheduling or cancellation link that authorises more than the recipient should hold API key scope defects, where a key issued for one user or team acts on another's data Authentication and SSO flaws, identity binding above all, since attaching an attacker-controlled identity to an existing account takes the calendar with it Server-side request forgery through webhooks or any other outbound fetch the user controls the destination of Stored cross-site scripting in a booking field, an event title or a workflow template that later renders in the organiser's session Privilege escalation inside a team, member to admin to owner, on an instance that holds several teams' integration credentials at once Program rules Submit through sorona.xyz. This project runs no bounty of its own; we validate, coordinate disclosure with the maintainers, and pay you directly. Report privately through GitHub private vulnerability reporting on calcom/cal.com, or by email to [email protected] . The live security.txt points at the GitHub advisory channel, and SECURITY.md gives the address Read the policy's own out-of-scope list before filing; it is published in SECURITY.md and the project maintains it independently Say whether you reproduced on the hosted service at cal.com or on a self-hosted deployment. The two share a codebase but differ in configuration and in which integrations are wired up Name the calendar integration involved. A defect in the Google connector and the same-shaped defect in the Microsoft connector are separate findings with separate blast radii The policy commits to legal safe harbour, confidentiality and credit by name, and it commits to no payment Do not test against other people's live booking pages; use your own tenant and your own connected calendars Disclosure Coordinated privately and published as a GitHub Security Advisory once a fix ships. Cal.com's own policy sets out what the project promises in return, including response commitments, confidentiality while the issue is open and credit under your name in the advisory. There is no published day count for embargo. Hold the detail until the advisory is out and the hosted service has been rolled forward, which for self-hosted operators is the point the fix becomes available to them. Safe harbor Sorona will not pursue legal action against you for good-faith research submitted to us in line with this policy. We cannot speak for the upstream project, its vendor, or any third party, and we do not grant authorization on their behalf. You are responsible for understanding and following the laws that apply to you, wherever you are, and for staying within any scope the project has defined. Submit a vulnerability