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
- [email protected]
- Machine-readable policy
- https://stillhold.cloud/.well-known/security.txt
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.