Calemander Reporting a vulnerability
Last reviewed 19 September 2026.
If you have found a security problem in Calemander, email security@calemander.com. This page says what we do with the report, how fast, and what we will not do to you for sending it.
How to report
Email security@calemander.com. Plain text is fine. What makes a report fast to act on is the same four things every time: the URL or endpoint, what you did, what happened that should not have, and how you know it mattered. A short proof beats a scanner export.
Please do not open a public issue, post the detail publicly, or tell a customer before we have had the time below to fix it. If you would rather not email, the machine-readable version of this page is at /.well-known/security.txt.
We do not run a bug bounty and we do not pay for reports. We say so here rather than let you find out after the work.
What we aim to do
The times on this page are targets we set ourselves. They are not promises and not terms of any contract. We publish them so you know what to expect; we may change them, and we say so here when we do.
- We aim to acknowledge your report within 5 business days. A human reply, not an auto-responder.
- We aim to give you our severity assessment within 10 business days, and why we reached it. If we disagree with yours, we say so and explain rather than going quiet.
- We aim to update you at least every 30 days until the issue is closed, even when the update is that nothing has moved.
- We tell you when the fix is deployed, and we may credit you by name on request.
Calemander is a very small company in Chicago. There is no security team and no overnight rota, and promising one would be a lie you could check. The targets above are ones a small company can usually meet, and they are targets.
Severity and patch timelines
Severity is ours to assign, from the impact on customer data and customer money rather than from a scanner's label. The clock starts when we confirm the issue, the resolution column is calendar days, and every figure is a target rather than a promise.
| Severity | What it means here | First response | Resolution |
|---|---|---|---|
| Critical | One workspace can reach another workspace’s data, authentication can be bypassed, or money can be moved or charged without authorisation. | Within 2 business days of confirming | Mitigation within 7 days, fix within 30 days |
| High | A stored credential can be read, a member can escalate their own role, or booking data can be read by someone outside the workspace. | Within 5 business days | Fix deployed within 30 days |
| Medium | An issue that needs an unusual precondition, an authenticated account, or user interaction to exploit, and whose impact is limited. | Within 10 business days | Fix deployed within 60 days |
| Low | A hardening gap or a defence-in-depth weakness with no demonstrated path to data or money. | Within 15 business days | Fix deployed within 90 days |
A critical issue we cannot fix within a day gets mitigated first — the feature is disabled, the credential is rotated, the route is closed — and fixed properly afterwards. Taking something away from customers beats leaving it exploitable, and we would rather explain a missing button than an exposed database.
If a target above is going to be missed, we aim to tell you before it passes and say what the new one is.
How we find them ourselves
- Every push is gated on a dependency advisory scan of the production dependency tree, at moderate severity and above. A red scan fails the run. Nothing is allowlisted or suppressed.
- An advisory is triaged by reachability, not by its number. We check whether the vulnerable code path exists in what we actually deploy before deciding what to do, and we write down the answer. A version bump that breaks a payment flow is not a security improvement.
- The platform patches itself underneath us. Calemander runs on Cloudflare Workers, so there is no operating system, no web server and no container image of ours to patch. That removes a large class of this problem and we are not going to pretend otherwise.
- Deploys are small and frequent, which is what makes mitigating a critical issue within seven days and fixing it within thirty realistic. There is no release train to wait for.
Scope
In scope:
calemander.comand its workspace subdomains.- Published booking pages, including those on a customer's own booking domain.
- Our API, our OAuth authorization server, and our webhook endpoints.
- The integrations we operate: calendar sync, conferencing, payments, Clio.
Out of scope:
- Denial of service, volumetric testing, and anything that degrades the service for other people. Please do not load-test us.
- Social engineering of our staff, our customers or our suppliers, and anything physical.
- Vulnerabilities in a third party's own product — Cloudflare, Stripe, Square, Google, Microsoft, Zoom, Clio, LawPay. Report those to them. If the bug is in how we use them, that is ours and we want it.
- The content a customer publishes on their own workspace. If a workspace is being used abusively, that is support@calemander.com, not a vulnerability report.
- Scanner output with no demonstrated impact: a missing hardening header, a cookie flag, a version banner, an email configuration opinion. Show us what it lets someone do.
Safe harbour
If you research in good faith and comply with every rule below, we do not intend to pursue or support legal action against you for that research, and we will consider it authorised for the purposes of our own terms. That intention is limited in four ways. It applies only to conduct that complies with this page; anything outside it is not covered. It is ours alone: it binds nobody else, cannot authorise you to test anyone else's systems, and does not stop a customer, a supplier or an authority from acting. It yields to any law or lawful order we must comply with, including a duty to report. And it is a statement of intent by a very small company, not legal advice and not a contract; we may change or withdraw it at any time, and the version in force is the one published when you began your research.
We review this page at least once a year; the review date is in the machine-readable file linked above.
- Use your own account and your own test workspace. Signing up is free and takes a minute, which makes testing against somebody else's booking page unnecessary.
- Stop at proof. Once you can show access, stop. Do not read, copy, modify, keep or exfiltrate anyone else's data, and do not pivot further into the system than the proof requires.
- Do not degrade the service. No denial of service, no destructive testing, no spam through our forms or booking pages.
- Tell us before you tell anyone else, and give us the time on this page to fix it. We are not going to set a gag period beyond that; if we go silent, publishing is your call.
- If you accidentally reach real customer data, stop and say so in the report. Doing that will not get you into trouble. Not doing it will.
None of this is a licence over anyone else. It cannot authorise you to test a customer's systems, a supplier's systems, or anything else that is not ours, and we reserve every right we have against conduct that falls outside these rules.
If customer data was exposed
When we confirm that a vulnerability exposed customer data, we aim to notify the affected workspace owners without undue delay, and within any period a law we are subject to requires, with what we know at the time rather than waiting for a complete picture. The notice says what was reachable, for how long, whether we can tell if anyone reached it, and what we have done. Where a workspace's own clients are affected, the workspace owner is the one who holds that relationship and we give them what they need to tell their clients.
The rest of our incident handling is on the security policy.
See also the security policy, the privacy policy and security.txt.