Nobody stole the keys. The vault shared them.

A low-privileged member of your team could walk off with the whole organization’s vault keys. Not one shared login. The keys themselves.

That is CVE-2026-60104, disclosed this week in self-hosted Bitwarden Server [1]. A working proof-of-concept is public, and the national response teams in Italy and Belgium both pushed alerts [2][3]. The fix shipped fast, in version 2026.6.0, and @Bitwarden’s cloud customers were never exposed. If you run your own server, you patch today.

The patch is the easy part. The design underneath it is the story.

The hole lives in a feature called Trusted Device Enrollment. TDE exists for a genuinely good reason: it lets someone sign in on a new laptop without retyping a master password. A device you already trust, or an administrator, approves the new one, and the account’s encryption key is delivered to it. Convenient. Humane, even, for a team onboarding people every week.

Now read that again. The account’s encryption key is delivered. The whole feature rests on a single premise: a vault key can be handed from one party to another when the right party approves. CVE-2026-60104 is what happens when a low-privileged member walks up to that approval path and asks for keys that were never theirs. The cryptography did not fail. The system did exactly what it was built to do. It shared.

@Bitwarden did not get sloppy here. They shipped a fix in a day and their managed users never felt it. The lesson is harder than a bug: the moment a key can be escrowed by design, a path exists to trick the escrow. Every approval workflow is an attack surface, because every approval workflow is, by definition, a way to move a key to someone new.

So we built the opposite premise.

In Clavitor, the vault key is not a secret the server holds and hands out. It is the output of your hardware key, produced only when you physically tap it. The operator never stores a form of that key that can decrypt anything, so there is nothing on the server to release. There is no admin-approval flow that delivers a vault key, because there is no server-side key to deliver. One member cannot request another member’s vault, because no request path ends in a key. Each unlock is bound to the device that did it and written to an audit trail against a named actor.

The honest edge: you can still add a second device. When you do, the key is re-wrapped for that new hardware key. But that takes a tap of a key you already hold, not an approval a stranger can talk a request form into granting. The key is never sitting somewhere a workflow can give it away.

That is the whole difference. A vault that can deliver a key can be talked into delivering it to the wrong person. A vault that only opens to the hardware in your hand has nothing to deliver.

We wrote down the short list of things a credential tool should never do. Holding a key it can be asked to hand over is near the top of it. [4]

Clavitor (@clavitorai) is the credential vault built for AI agents, and against them. clavitor.ai

---

Sources

CVE-2026-60104, National Vulnerability Database record. Self-hosted Bitwarden Server authentication bypass, fixed in 2026.6.0. [1]

CSIRT Italia (@csirt_it), advisory: public PoC for CVE-2026-60104, classified as Security Restrictions Bypass and Information Leakage. [2]

Centre for Cybersecurity Belgium (@CCBalert), alert: auth bypass lets a low-privileged org member steal other users’ vaults, CVSS 9.3, update to v2026.6.0+. [3]

The Ten Rules of Credential Management (@clavitorai). [4]