Skip to content

Security disclosure

If you found a way to break Stillhold's security, we want to hear about it first. Thank you for telling us rather than the internet.

Last updated 15 November 2026

How to report

Include what you found, how to reproduce it, and what an attacker could do with it. Use a test account of your own. Don't include real users' data.

What we promise

  • We'll reply within 3 working days to confirm we have your report.
  • We'll keep you updated, tell you when it's fixed, and credit you if you want.
  • We won't take legal action against, or ask anyone to take action against, someone who follows this policy in good faith.

We don't run a paid bounty. We can offer thanks and credit.

What we ask

  • Give us reasonable time to fix it before you publish anything.
  • Only test accounts you own. Don't read, change or delete other people's data, and stop as soon as you've shown the problem.
  • No denial-of-service, spam, social engineering or physical attacks.
  • Stay out of other services that run on the same server; they aren't ours to test.

In scope

  • stillhold.cloud and the Stillhold apps and APIs behind it.
  • The sign-in, passkey, two-step, recovery and session logic.
  • The encryption in the browser, and the mail server.

Known limits, not vulnerabilities

These are design limits that we document openly, so please don't report them as new findings:

  • Sign-in isn't zero-knowledge: the server sees your password when you sign in. The encryption key is derived separately in your browser and never sent.
  • Mail from and to other providers isn't end-to-end encrypted; the server handles it as plaintext briefly.
  • Some metadata, such as sizes, times and folder structure, is visible to the server. The Privacy Policy lists it.
  • Reports from automated scanners with no demonstrated impact, or missing hardening headers with no attack.