Ingen stjålne nøgler. Boksen delte dem.
En CVE i selvhostet Bitwarden lod et medlem med lave rettigheder gå af sted med hele organisationens boksnøgler. Krypteringen fejlede ikke. En boks, der kan udlevere en nøgle til en ny person, kan narres til det.
Et medlem af dit team med lave rettigheder kunne gå af sted med hele organisationens boksnøgler. Ikke ét delt login. Selve nøglerne.
Det er CVE-2026-60104, offentliggjort i denne uge i selvhostet Bitwarden Server [1]. Et fungerende proof-of-concept er offentligt tilgængeligt, og de nationale responsenheder i både Italien og Belgien udsendte varsler [2][3]. Rettelsen kom hurtigt, i version 2026.6.0, og @Bitwardens cloudkunder blev aldrig berørt. Hvis du kører din egen server, patcher du i dag.
Rettelsen er den nemme del. Designet under den er historien.
Hullet ligger i en funktion kaldet Trusted Device Enrollment. TDE findes af en rigtig god grund: det lader nogen logge ind på en ny bærbar uden at skrive sin adgangskode igen. En enhed, du allerede stoler på, eller en administrator, godkender den nye, og kontoens krypteringsnøgle bliver afleveret til den. Praktisk. Ligefrem menneskeligt, faktisk, for et team der onboarder folk hver uge.
Læs det igen. Kontoens krypteringsnøgle bliver afleveret. Hele funktionen hviler på én forudsætning: en boksnøgle kan overdrages fra den ene part til den anden, når den rette part godkender. CVE-2026-60104 er, hvad der sker, når et medlem med lave rettigheder går op til den godkendelsesvej og beder om nøgler, der aldrig var deres. Krypteringen fejlede ikke. Systemet gjorde præcis, hvad det var bygget til. Det delte.
@Bitwarden var ikke sløsede her. De sendte en rettelse på en dag, og deres administrerede brugere mærkede det aldrig. Læren er sværere end en fejl: i det øjeblik en nøgle kan sættes i depot efter design, findes der en vej til at narre depotet. Enhver godkendelsesproces er et angrebsfelt, for enhver godkendelsesproces er per definition en måde at flytte en nøgle over til en ny person.
Så vi byggede på den modsatte forudsætning.
I Clavitor er boksnøglen ikke en hemmelighed, serveren gemmer og deler ud. Den er outputtet af din hardwarenøgle, og den produceres kun, når du fysisk trykker på den. Operatøren gemmer aldrig en form af den nøgle, der kan dekryptere noget som helst, så der er intet på serveren at frigive. Der er ingen administratorgodkendelse, der afleverer en boksnøgle, for der er ingen nøgle på serversiden at aflevere. Et medlem kan ikke anmode om et andet medlems boks, for ingen anmodningsvej ender i en nøgle. Hvert unlock er bundet til den enhed, der udførte det, og skrevet til et revisionsspor med et navngivet handlende.
Den ærlige kant: du kan stadig tilføje en anden enhed. Når du gør det, bliver nøglen genindpakket til den nye hardwarenøgle. Men det kræver et tryk på en nøgle, du allerede har, ikke en godkendelse, som en fremmed kan tale en ansøgningsformular til at give. Nøglen ligger aldrig et sted, hvor en proces kan give den væk.
Det er hele forskellen. En boks, der kan aflevere en nøgle, kan tales til at aflevere den til den forkerte person. En boks, der kun åbner for hardwaren i din hånd, har intet at aflevere.
Vi skrev den korte liste over ting, et værktøj til legitimationsoplysninger aldrig bør gøre. At holde en nøgle, som det kan blive bedt om at udlevere, ligger nær toppen af den. [4]
Clavitor (@clavitorai) er boksen til legitimationsoplysninger bygget til AI-agenter — og imod dem. clavitor.ai
---
Kilder
CVE-2026-60104, National Vulnerability Database-post. Autentificeringsbypass i selvhostet Bitwarden Server, rettet i 2026.6.0. [1]
CSIRT Italia (@csirt_it), advisory: offentligt PoC for CVE-2026-60104, klassificeret som Security Restrictions Bypass og Information Leakage. [2]
Centre for Cybersecurity Belgium (@CCBalert), varsel: auth bypass lader et medlem med lave rettigheder stjæle andre brugeres bokse, CVSS 9.3, opdater til v2026.6.0+. [3]
The Ten Rules of Credential Management (@clavitorai). [4]