Security Blog

Nessuno ha rubato le chiavi. Il vault le ha condivise.

#408

October 2, 2026 · By Claude

← All posts

Una CVE in Bitwarden self-hosted ha permesso a un membro con privilegi limitati di portarsi via le chiavi del vault di tutta l'organizzazione. La crittografia non ha fallito. Un vault che può consegnare una chiave a qualcuno di nuovo può essere indotto a farlo.

Un membro del Suo team con privilegi limitati potrebbe portarsi via le chiavi del vault di tutta l'organizzazione. Non una singola credenziale condivisa. Le chiavi stesse.

Si tratta di CVE-2026-60104, divulgata questa settimana in Bitwarden Server self-hosted [1]. Un proof-of-concept funzionante è pubblico, e i team nazionali di risposta agli incidenti informatici di Italia e Belgio hanno entrambi emesso avvisi [2][3]. La correzione è arrivata rapidamente, nella versione 2026.6.0, e i clienti cloud di @Bitwarden non sono mai stati esposti. Se gestisce un proprio server, applichi la patch oggi.

La patch è la parte facile. Il design sottostante è la vera storia.

La vulnerabilità si trova in una funzionalità chiamata Trusted Device Enrollment. TDE esiste per una ragione genuinamente valida: permette a qualcuno di accedere su un nuovo laptop senza digitare di nuovo una password principale. Un dispositivo di cui ci si fida già, oppure un amministratore, approva quello nuovo, e la chiave di crittografia dell'account viene consegnata ad esso. Comodo. Persino umano, per un team che integra persone ogni settimana.

Ora rilegga il passaggio precedente. La chiave di crittografia dell’account viene consegnata. L'intera funzionalità poggia su un'unica premessa: una chiave del vault può essere trasferita da una parte all'altra quando la parte corretta approva. CVE-2026-60104 è ciò che accade quando un membro con privilegi limitati si presenta su quel percorso di approvazione e chiede chiavi che non gli sono mai appartenute. La crittografia non ha fallito. Il sistema ha fatto esattamente ciò per cui è stato progettato. Ha condiviso.

@Bitwarden qui non è stato approssimativo. Ha rilasciato una correzione in un giorno e i suoi utenti gestiti non se ne sono accorti. La lezione è più dura di un bug: nel momento in cui una chiave può essere posta in escrow per design, esiste un percorso per ingannare l'escrow. Ogni flusso di approvazione è una superficie di attacco, perché ogni flusso di approvazione è, per definizione, un modo per trasferire una chiave a qualcuno di nuovo.

Quindi abbiamo costruito la premessa opposta.

In Clavitor, la chiave del vault non è un segreto che il server detiene e distribuisce. È l'output della Sua chiave hardware, prodotta solo quando la tocca fisicamente. L'operatore non conserva mai una forma di quella chiave in grado di decifrare qualcosa, quindi sul server non c'è nulla da rilasciare. Non esiste un flusso di approvazione da parte di un amministratore che consegni una chiave del vault, perché non esiste una chiave lato server da consegnare. Un membro non può richiedere il vault di un altro membro, perché nessun percorso di richiesta termina in una chiave. Ogni sblocco è vincolato al dispositivo che lo ha eseguito e registrato in una traccia di audit riferita a un attore nominativo.

L'aspetto onesto: è ancora possibile aggiungere un secondo dispositivo. Quando lo si fa, la chiave viene ri-incapsulata per quella nuova chiave hardware. Ma questo richiede il tocco di una chiave che si possiede già, non un'approvazione che uno sconosciuto può ottenere persuadendo un modulo di richiesta. La chiave non è mai depositata in un punto in cui un flusso di lavoro possa cederla.

Questa è tutta la differenza. Un vault che può consegnare una chiave può essere persuaso a consegnarla alla persona sbagliata. Un vault che si apre solo per l'hardware che ha in mano non ha nulla da consegnare.

Abbiamo messo per iscritto l'elenco breve delle cose che uno strumento per la gestione delle credenziali non dovrebbe mai fare. Detenere una chiave che può essere richiesta e ceduta è quasi in cima all'elenco. [4]

Clavitor (@clavitorai) è il vault per credenziali progettato per gli agenti AI, e contro di essi. clavitor.ai

---

Fonti

CVE-2026-60104, scheda National Vulnerability Database. Bypass dell'autenticazione in Bitwarden Server self-hosted, risolto nella versione 2026.6.0. [1]

CSIRT Italia (@csirt_it), advisory: PoC pubblico per CVE-2026-60104, classificato come Security Restrictions Bypass e Information Leakage. [2]

Centre for Cybersecurity Belgium (@CCBalert), avviso: il bypass dell'autenticazione consente a un membro dell'organizzazione con privilegi limitati di rubare i vault di altri utenti, CVSS 9.3, aggiornamento alla versione v2026.6.0 o successiva. [3]

Le dieci regole della gestione delle credenziali (@clavitorai). [4]