Responsible Disclosure Policy

Last updated: 19 July 2026 · Version 1.0 · HexVault Ltd, England & Wales

We take the security of HexVault seriously, and we rely on the security research community to help us keep it that way. This policy explains how to report a vulnerability, what you can expect from us, and the commitments we make to researchers who report in good faith. If you have found a security issue, thank you — we want to hear from you.

How to report

Email [email protected] with a description of the issue and enough detail for us to reproduce it — affected endpoint or component, steps, and any proof-of-concept. For sensitive reports you can encrypt to our published key at /.well-known/pgp-key.txt.

A good report includes: what you found, where, how to reproduce it, and what an attacker could do with it. Screenshots or a short proof-of-concept help. Please do not include real user data in your report.

What you can expect from us

Acknowledgement within 48 hours. A human will confirm we have received your report.
An assessment within 5 working days — whether we have reproduced it, our severity view, and expected next steps.
A fix timeline that matches severity. We aim to remediate critical issues within 7 days, and to keep you updated as we work through it.
Credit, if you want it. With your permission we will acknowledge your contribution in our disclosure acknowledgements. You are equally welcome to stay anonymous.

Safe harbour

We will not pursue or support legal action against researchers who act in good faith under this policy. Specifically, if you make a genuine effort to follow it — you avoid privacy violations, data destruction, and service degradation; you only interact with accounts you own or have explicit permission to test; and you give us reasonable time to respond before disclosing — we consider your research authorised, and we will not treat it as a violation of our terms or of the Computer Misuse Act.

If you are unsure whether a specific action is permitted, ask us first at [email protected]. We would far rather answer a question than have you hold back a valid report.

In scope

hexvault.co.uk and its subdomains
The HexVault web application and API
The browser extension and desktop applications
Authentication and session handling; authorisation and access control
Cryptographic weaknesses in the zero-knowledge architecture
Any path to vault-data exposure, injection, CSRF, or XSS

Out of scope

The following generally do not qualify on their own, unless you can chain them into a concrete, demonstrable impact:

Reports from automated scanners without a working proof-of-concept
Missing security headers, cookie flags, or TLS configuration with no demonstrated exploit
Social engineering, phishing, or physical attacks against our staff or infrastructure
Denial-of-service, rate-limiting, or volumetric issues
Self-XSS, or issues requiring a fully compromised device or a malicious browser extension
Vulnerabilities in third-party services we depend on — please report those to the relevant vendor

Coordinated disclosure

We ask that you give us a reasonable window to remediate before disclosing publicly — 90 days is the norm, and we are usually much faster. We are glad to coordinate a joint disclosure and a CVE where appropriate, and we will always credit your work if you would like us to. We commit to being transparent with you about our progress; we ask the same courtesy in return.

A note on our design

HexVault is zero-knowledge: your vault key is derived from your master password with Argon2id in your browser, and your entries are encrypted with AES-256-GCM before anything leaves your device. We never receive your master password or your plaintext. This means some classes of “server-side data exposure” do not apply in the way they would to a conventional service — but it also means the client-side cryptography matters enormously. Findings there are especially welcome.

Machine-readable version: /.well-known/security.txt