Security disclosure policy.
We take security reports seriously and we treat the people who report them well. This page describes how to contact us, what's in scope, what we commit to, and what we ask in return.
Contact
Email 0trustvpn@proton.me, encrypted to our PGP key. Don't use the support address — vulnerability reports get faster triage on a dedicated channel.
The key fingerprint:
Verify it via /.well-known/security.txt, on keys.openpgp.org, and the WKD URL also linked from security.txt. If you're unsure whether you've reached the right key, ask us to sign a one-off challenge with the fingerprint above.
Our commitments to you
- Acknowledgement within 24 hours — even on weekends. If you don't hear back in 24h, the report didn't reach us; please try a different channel (Mastodon, Bluesky, signed Tor onion submission).
- Initial triage within 72 hours — we'll tell you whether we can reproduce, our severity estimate, and our expected timeline.
- You set the disclosure timeline within reason. The default is 90 days from acknowledgement before public disclosure; we'll negotiate longer for hard-to-fix architectural issues, or shorter for active exploitation.
- Credit your work in the resulting advisory unless you prefer to remain anonymous. We don't run a bounty program at our current scale, but we will offer free subscription extensions and we will not be the operator who shortchanged you on attribution.
- Never threaten you with legal action for good-faith research within the scope below. This commitment is non-revocable.
In scope
✓ Welcome
- The control-plane API surface (
api/v1/*) - The client binaries (CLI, GUI, mobile export)
- BTCPay integration (webhook verification, invoice handling)
- Mesh-node syncer and ephemeral-node provisioning flow
- Cryptographic weaknesses in our protocol or implementation choices
- Information leakage in nginx, our static pages, or DNS
- Privacy regressions vs. the claims in our audit pack
✗ Out of scope
- Findings against BTCPay Server itself — report to BTCPay upstream
- Findings against WireGuard — report to WireGuard upstream
- Vulnerabilities requiring physical access to a customer device
- Issues only exploitable with phishing or social engineering of our customers
- Missing security headers without a demonstrated impact
- SPF / DMARC / DKIM nits on the support inbox (controlled by the mail provider)
What we ask in return
- Don't access customer data. If a vulnerability would allow it, demonstrate the path without retrieving real customer records.
- Don't degrade service for others. No load testing, no fuzzing the live API at high volume, no traffic generation that would impact paying customers. Hit us up first if you want a test environment.
- Coordinate disclosure. Give us a reasonable window to fix before publishing. We'll work with you on timing.
- Encrypt your report. The mail provider is encrypted at rest, but PGP-to-PGP is end-to-end. Use the key above.
Safe harbor
Research conducted within this policy is authorized. We will not pursue civil or criminal action against researchers who:
- Make a good-faith effort to follow this policy
- Avoid privacy violations, data destruction, and service degradation
- Provide us with reasonable disclosure timelines
- Don't extort us with the report
This commitment binds the legal entity operating 0trust and any successor entity, regardless of the jurisdiction we operate from. It is published here, in our security.txt, and in our warrant canary archive, so a future operator cannot quietly revoke it.
Out-of-band verification
If you suspect any of our public infrastructure is compromised — including this page — and you want to verify a key fingerprint or our identity:
- Cross-check the fingerprint with our most recent warrant canary; it includes the active signing key fingerprint and is itself PGP-signed.
- Look at recent Mastodon posts (link from our home page) — same fingerprint published there.
- Request signed responses from us via Tor onion (when available) which uses a separate certificate chain.