Found a hole? Tell us.

Wundervault holds credentials, so the worst outcome is not a bug — it is a bug nobody told us about. This page is the address to send one to, what we promise in return, and what we will do if the thing we are guarding against actually happens.

What to send

• What you did, in enough detail to repeat it. A request, a sequence of clicks, a script — whatever it took. A finding we cannot reproduce is a finding we cannot fix.
• What you got. The response, the value, the screenshot. If you believe you accessed data that is not yours, tell us what and roughly how much, and please stop there.
• How to reach you. An email address is enough. Tell us if you want credit on the changelog entry, and under what name.

What we promise

• An acknowledgement within 3 business days (UK working days), from a person, saying whether we have reproduced it yet. If something has gone wrong at our end and we are slower, we will still answer — chase us and say so.
• No legal action for good-faith research. Test against your own account, do not run denial-of-service or spam, do not access or keep anyone else's data beyond what proves the bug, and give us a chance to fix it before you publish. Stay inside that and we will treat your report as a favour, which is what it is.
• A fix, or an honest reason there isn't one. If we cannot fix it, we will say so and write it into Known limitations rather than let it sit unlisted.
• Credit in the changelog when the fix ships, unless you would rather not be named.
• No bug bounty. There is no money behind this yet, and saying otherwise would waste your time. We would rather be plain about it than imply a reward that does not exist.

What we do if we are breached

Not a hypothetical worth being vague about, so here is the commitment.

• We email every account we believe is affected, and we say so publicly on @wundervault1. Both, not one — the email is for the people whose data it is, the post is for everyone else, and it goes up even when we think the blast radius is small. If we cannot yet scope who is affected, we email everyone and say that is why.
• Within 72 hours of the point we believe a breach is more likely than not — not the point we finish investigating, because that is a clock we could start whenever we liked. We will not wait for a complete picture: the first notice says what we know, what we do not know yet, and what you should do now. Details follow as we learn them.
• The notice will name what was exposed — which data, for which accounts, over what window — and what we have done to close it. If we cannot yet tell whether your account is affected, we will say that rather than let silence imply safety.
• What a breach of our server does not hand anyone — and what it does. Secret values are encrypted in your browser and we do not hold your passphrase, so a copy of the database yields ciphertext for those. Everything else in it is readable: secret names, timestamps, access patterns, declared purposes, email addresses, and the wrapped keys and tokens that belong to your agents. And a compromise of a running server is worse than a stolen database — an attacker in that position could serve modified JavaScript and capture what you type before it is encrypted, which is the browser-trust limit we describe on the limitations page. We would tell you which of these applied.
• Rotate anyway. If we are ever breached we will tell you to rotate the credentials you stored with us. Encrypted-at-rest is a good reason not to panic; it is not a reason to skip rotation.

Is it down, or is it me?

Availability is monitored from outside our infrastructure, and the record is public — including the bad days. Live status and uptime history →