Il 21 settembre 2026 Trezor ha aggiornato la sua pagina di notifica incidenti con un dettaglio che ha allargato ulteriormente una crepa aperta a metà agosto: la violazione dati partita dal fornitore logistico ShipMonk non riguarda più 14.000 clienti, ma 80.689, arrotondati nella cronaca a 81.000. Dietro il numero c’è una catena di responsabilità che si è spezzata in tre punti: una falla SQL injection in Metabase con punteggio massimo di gravità, un fornitore di fulfillment che non l’aveva corretta, e il gruppo di estorsione ShinyHunters che ne ha approfittato. Nessun portafoglio è stato svuotato, nessuna chiave privata è stata sottratta. Ma la vicenda racconta qualcosa di più ampio sul modo in cui le aziende che vendono sicurezza finiscono comunque per esporre i propri clienti attraverso la parte meno protetta della filiera: il magazzino.
Cosa è successo davvero: la cronologia del breach Trezor-ShipMonk
La falla alla base dell’incidente è nota come CVE-2026-72898, una SQL injection non autenticata nell’endpoint di reimpostazione password di Metabase, la piattaforma di business intelligence usata da ShipMonk per gestire ordini e spedizioni. Il punteggio CVSS assegnato è 10.0, il massimo possibile sulla scala, perché lo sfruttamento consente di ottenere privilegi amministrativi sull’istanza e di leggere qualunque dato collegato al database sottostante senza bisogno di credenziali valide.
Trezor ha comunicato l’incidente per la prima volta il 13 agosto 2026, parlando di circa 14.000 clienti coinvolti attraverso il proprio partner di spedizione ShipMonk. Il 2 settembre l’azienda ceca ha appreso che la portata reale era superiore, e tra il 5 e il 7 settembre ha reso pubblico l’impatto aggiuntivo su 67.000 clienti statunitensi, portando il totale a 80.689 record. Il 21 settembre è arrivata una ripartizione più precisa della prima tranche: 11.742 clienti con esposizione completa (nome, email, telefono e indirizzo di spedizione) e 1.947 con esposizione parziale (nome, città ed email). I dati coinvolti riguardano ordini piazzati tra novembre 2019 e agosto 2021, un dettaglio che solleva domande sul perché quelle informazioni fossero ancora conservate cinque anni dopo.
Sul fronte delle responsabilità, Trezor ha voluto tracciare subito una linea netta. “Our systems were not compromised, and your Trezor device is secure” (“i nostri sistemi non sono stati compromessi e il vostro dispositivo Trezor è sicuro”), ha scritto l’azienda nella notifica ai clienti pubblicata sul proprio blog. È una distinzione tecnicamente corretta: l’attacco ha colpito l’infrastruttura di ShipMonk, non i server o il firmware di Trezor, e non risultano evidenze di accesso a seed phrase, chiavi private o PIN dei dispositivi.
Chi ha attaccato e cosa ha chiesto: il ruolo di ShinyHunters
Secondo le fonti giornalistiche che seguono il caso, tra cui BleepingComputer, ShipMonk ha ricevuto email di estorsione attribuite al collettivo ShinyHunters, lo stesso gruppo che nelle scorse settimane è stato collegato a diverse campagne di furto dati su larga scala contro piattaforme SaaS e provider cloud in Europa. Le comunicazioni disponibili non specificano in modo verificabile l’importo richiesto, una scadenza per il pagamento o se un riscatto sia mai stato versato. Non risulta nemmeno che i sistemi di ShipMonk siano stati cifrati: la dinamica descritta è quella di un furto di dati seguito da estorsione, non di un ransomware in senso classico.
La catena tecnica ricostruita dai ricercatori è lineare: vulnerabilità Metabase, accesso all’istanza analitica di ShipMonk, estrazione dei dati di fulfillment collegati agli ordini Trezor, tentativo di estorsione contro il fornitore logistico. È il manuale di un attacco alla supply chain: il bersaglio finale, Trezor, non è mai stato toccato direttamente. È bastato colpire il fornitore che gestiva gli scatoloni.
I numeri della violazione in una tabella
| Elemento | Dato |
|---|---|
| CVE della vulnerabilità sfruttata | CVE-2026-72898 |
| Punteggio CVSS | 10.0 (critico) |
| Sistema colpito | Metabase, istanza gestita da ShipMonk |
| Clienti coinvolti (prima disclosure, 13 agosto) | circa 14.000 |
| Clienti aggiuntivi (disclosure 5-7 settembre) | 67.000 (utenti USA) |
| Totale clienti coinvolti | 80.689 (~81.000) |
| Esposizione completa (prima tranche) | 11.742 record |
| Esposizione parziale (prima tranche) | 1.947 record |
| Periodo ordini coinvolti | novembre 2019 – agosto 2021 |
| Gruppo di estorsione attribuito | ShinyHunters (secondo reporting giornalistico) |
| Chiavi private o seed phrase esposte | Nessuna evidenza riportata |
Cosa è stato rubato e cosa resta al sicuro
I dati esposti comprendono nome completo, indirizzo email, numero di telefono, indirizzo di spedizione e, per il gruppo di clienti statunitensi, numero d’ordine. Non ci sono evidenze pubbliche che indichino la sottrazione di chiavi private, seed phrase, PIN dei dispositivi o saldi in criptovaluta. Trezor lo ribadisce anche nella comunicazione istituzionale sul proprio funzionamento: “Even if your computer or smartphone is compromised, the private keys stored in your hardware wallet remain safe, as they never interact directly with your online device” (“anche se il computer o lo smartphone sono compromessi, le chiavi private conservate nel wallet hardware restano al sicuro, perché non interagiscono mai direttamente con il dispositivo online”), spiega l’azienda nella sezione educativa del proprio sito.
Il punto, però, è che il rischio principale di questo tipo di violazione non è mai stato l’accesso diretto al wallet. È la possibilità di costruire un attacco di ingegneria sociale credibile: sapere che una persona possiede un dispositivo per criptovalute, dove abita, quale numero di telefono usa e quando ha ricevuto la spedizione è più che sufficiente per una telefonata di phishing vocale convincente, una lettera fraudolenta recapitata a casa, o nei casi più gravi un tentativo di intimidazione fisica.
Il precedente Ledger del 2020: la stessa storia, cinque anni prima
Chi segue il settore degli hardware wallet ha già visto questo film. Nel luglio 2020 Ledger, il principale concorrente diretto di Trezor, ammise che un attacco al proprio database e-commerce e marketing aveva esposto dati personali di circa 272.000 clienti, insieme agli indirizzi email di altri 1 milione di iscritti alla newsletter. Anche in quel caso l’attacco non riguardò i dispositivi Ledger né le chiavi private, ma un database contenente nomi, indirizzi postali, numeri di telefono ed email.
Le conseguenze, in quel caso, andarono ben oltre lo spam ordinario. I truffatori usarono i dati esposti per campagne di phishing mirate che imitavano Ledger e cercavano di indurre gli utenti a rivelare la propria seed phrase di 24 parole. Ci furono segnalazioni di tentativi di SIM swap collegati ai numeri di telefono trapelati, e soprattutto emersero casi di intimidazione fisica contro possessori di criptovalute identificati proprio grazie all’indirizzo postale finito nel database rubato: i cosiddetti attacchi “a chiave inglese da 5 dollari”, dove la minaccia fisica sostituisce l’attacco informatico. È lo stesso profilo di rischio che oggi si ripropone con Trezor: a differenza di una password, un indirizzo di casa non si può cambiare con un clic.
Il caso SafePal: non è un incidente isolato
A complicare il quadro, nelle stesse settimane è emersa anche una violazione separata che ha coinvolto SafePal, altro produttore di wallet hardware e software per criptovalute. Secondo la ricostruzione pubblicata da Forbes, l’incidente SafePal avrebbe esposto dati di circa 39.798 clienti attraverso una falla di autorizzazione in un plugin di tracciamento ordini, un vettore tecnico diverso dalla SQL injection su Metabase che ha colpito ShipMonk. Sommando le due disclosure iniziali, Forbes ha parlato di 53.487 proprietari di wallet coinvolti nelle due vicende combinate, un numero salito ulteriormente dopo i successivi aggiornamenti di Trezor.
Il denominatore comune tra Ledger 2020, Trezor 2026 e SafePal 2026 non è la tecnica di attacco, che cambia ogni volta, ma il bersaglio: non il cuore crittografico del prodotto, sempre difficile da violare, ma i sistemi periferici che gestiscono ordini, spedizioni e assistenza clienti. Tre aziende diverse, tre fornitori o piattaforme diverse, lo stesso risultato: elenchi di clienti che possiedono criptovalute, completi di indirizzo di casa.
Il confronto con il resto del mercato degli hardware wallet
Non esistono cifre di mercato ufficiali e verificate per confrontare in modo puntuale Ledger, Trezor, Coldcard, OneKey, BitBox e Keystone: i produttori comunicano generalmente volumi di vendita cumulativi, non basi utenti attive verificate da terze parti, e quindi qualunque confronto percentuale sarebbe una stima non verificabile. Quello che si può osservare con certezza, però, è il modello operativo comune a quasi tutto il settore: la gestione delle chiavi crittografiche avviene su hardware isolato e offline, mentre la gestione degli ordini, delle spedizioni e del supporto clienti passa quasi sempre attraverso piattaforme di e-commerce, CRM e strumenti di logistica esterni.
| Produttore | Sede/area | Gestione dati di spedizione |
|---|---|---|
| Ledger | Francia | E-commerce proprio, storicamente affiancato da fornitori esterni di logistica e marketing (violato nel 2020) |
| Trezor (SatoshiLabs) | Repubblica Ceca | Fulfillment tramite fornitore terzo ShipMonk (violato nel 2026) |
| SafePal | Asia/globale | Plugin di tracciamento ordini con falla di autorizzazione (violato nel 2026) |
| Coldcard | USA/globale | Dati non pubblicamente dettagliati; modello misto commerce/logistica |
| OneKey | Asia/globale | Canali di vendita online e distribuzione regionale, dettagli non pubblici |
| BitBox (Shift Crypto) | Svizzera | Negozio proprio con distribuzione regionale, dettagli non pubblici |
La lezione che se ne ricava non è che un singolo marchio sia meno sicuro degli altri, ma che l’intero settore condivide lo stesso punto debole strutturale: la sicurezza del dispositivo è quasi sempre superiore alla sicurezza della filiera che lo consegna al cliente.
L’angolo GDPR: cosa rischia Trezor in Europa
Trezor è un marchio di SatoshiLabs, azienda con sede nella Repubblica Ceca, e questo colloca la vicenda pienamente dentro il perimetro del Regolamento generale sulla protezione dei dati (GDPR). I dati coinvolti, nome, indirizzo, telefono ed email, rientrano nella definizione di dati personali dell’articolo 4 del regolamento, e l’articolo 33 impone al titolare del trattamento di notificare l’autorità di controllo competente entro 72 ore dalla conoscenza della violazione, salvo che questa non comporti un rischio per i diritti e le libertà degli interessati. L’articolo 34 può inoltre richiedere la comunicazione diretta agli interessati quando il rischio è elevato.
Il fatto che l’accesso sia avvenuto tramite un fornitore esterno non esclude automaticamente la responsabilità di Trezor: se SatoshiLabs agisce come titolare del trattamento e ShipMonk come responsabile esterno, la normativa richiede comunque un controllo contrattuale e tecnico adeguato sul fornitore. Le domande che un’autorità di protezione dati come l’Úřad pro ochranu osobních údajů ceco potrebbe porre riguardano la due diligence su ShipMonk, i tempi di rilevamento e comunicazione dell’incidente, la proporzionalità della conservazione di dati relativi a ordini del 2019-2021 ancora presenti nei sistemi nel 2026, e la chiarezza delle comunicazioni inviate ai clienti europei coinvolti. L’esistenza di una violazione non equivale automaticamente a una sanzione: la valutazione dipenderà dalle misure di sicurezza effettivamente adottate e dalla tempestività della risposta.
Impatto sul mercato e fiducia dei consumatori
Per un’azienda che vende sicurezza come proposta di valore primaria, ogni violazione dati pesa in modo sproporzionato rispetto al danno tecnico reale. Trezor non ha comunicato un impatto sulle vendite o un calo di fatturato collegato all’incidente, ma la reazione della community su forum specializzati e social ha già mostrato un pattern ricorrente dopo ogni breach del settore: richieste di spiegazioni sulla data retention, domande sul perché dati di ordini vecchi di cinque anni fossero ancora conservati, e paragoni immediati con il precedente Ledger. In un mercato dove la fiducia è il prodotto, non solo un attributo del prodotto, la percezione pubblica conta quanto la sostanza tecnica dell’incidente.
Sul fronte assicurativo e di compliance, ci si può aspettare che i produttori di hardware wallet comincino a richiedere audit di sicurezza più rigorosi ai propri fornitori di fulfillment, in particolare sulle piattaforme di business intelligence come Metabase che, avendo accesso privilegiato a database di produzione, rappresentano un bersaglio ad alto valore ma spesso trascurato rispetto ai sistemi rivolti al cliente.
Perché Metabase continua a essere bersaglio di attacchi critici
CVE-2026-72898 non è un caso isolato nel 2026: le piattaforme di business intelligence self-hosted come Metabase, usate da migliaia di aziende per creare dashboard e report collegati direttamente ai database di produzione, sono diventate un bersaglio ricorrente proprio per la combinazione di due fattori. Primo, hanno quasi sempre accesso diretto e privilegiato ai dati grezzi delle aziende che le usano, spesso più ampio di quello concesso alle applicazioni rivolte al cliente. Secondo, vengono spesso distribuite come componente secondario dell’infrastruttura, con patching meno prioritario rispetto ai sistemi considerati “core”. Una SQL injection sull’endpoint di reset password, come in questo caso, è un difetto di validazione dell’input relativamente semplice da correggere, ma diventa devastante quando l’istanza vulnerabile è collegata a un database che contiene anni di cronologia ordini di clienti reali.
Confronto tecnico: SQL injection contro falla di autorizzazione
Vale la pena distinguere i due vettori usati nei casi Trezor e SafePal, perché raccontano rischi diversi. La SQL injection sfruttata contro l’istanza Metabase di ShipMonk (CVE-2026-72898) è un difetto che permette di manipolare le query verso il database senza autenticazione, ottenendo di fatto privilegi amministrativi: è il tipo di vulnerabilità che, con un CVSS di 10.0, consente un accesso pressoché completo se il sistema è raggiungibile da remoto e non aggiornato. La falla di autorizzazione riportata nel caso SafePal, riguardante un plugin di tracciamento ordini, è concettualmente diversa: non richiede di bypassare l’autenticazione con codice malevolo, ma sfrutta un controllo di accesso mal configurato che permette di vedere dati che non si dovrebbero poter vedere. Entrambe le tecniche, per quanto tecnicamente distanti, producono lo stesso risultato pratico: l’esposizione di database di clienti che nessuno considerava un bersaglio prioritario fino a quando non lo è diventato.
Cosa possono fare ora i clienti coinvolti
Per chi ha ricevuto una notifica da Trezor, le raccomandazioni pratiche restano quelle tipiche di ogni violazione di dati anagrafici e di contatto. Primo, diffidare di qualunque email, SMS o telefonata che chieda di confermare la seed phrase, il PIN o di installare un aggiornamento software: Trezor non chiede mai queste informazioni. Secondo, prestare attenzione a lettere fisiche o pacchi non richiesti che imitano comunicazioni ufficiali, uno schema già osservato nel caso SafePal secondo Forbes. Terzo, valutare l’attivazione di un blocco sulle richieste di portabilità del numero telefonico presso il proprio operatore, come misura preventiva contro il SIM swap, soprattutto per chi ha usato lo stesso numero associato all’ordine. Quarto, ricordare che nessuna delle informazioni esposte permette di per sé di accedere ai fondi: il rischio reale è l’ingegneria sociale successiva, non un attacco informatico diretto al wallet.
Cosa possono fare i fornitori e gli sviluppatori
Dal lato tecnico, il caso ShipMonk offre indicazioni chiare per chiunque gestisca un’istanza Metabase o strumenti di business intelligence simili collegati a dati di produzione. Aggiornare immediatamente alla versione patchata dopo la disclosure di una CVE con CVSS 10.0 non è negoziabile, ma non basta: serve segmentare l’accesso di rete in modo che gli strumenti analitici non abbiano visibilità diretta su tabelle contenenti dati personali completi, applicare mascheramento o pseudonimizzazione ai campi sensibili quando possibile, e soprattutto rivedere le policy di conservazione dei dati. Il fatto che ordini del 2019-2021 fossero ancora presenti ed esposti nel 2026 indica un problema di data retention più ampio della singola vulnerabilità tecnica: cancellare i dati che non servono più riduce automaticamente la superficie di attacco, indipendentemente da quanto sia sicura la piattaforma che li ospita.
Previsioni: cosa aspettarsi nei prossimi mesi
- È probabile che l’autorità ceca per la protezione dei dati o un’altra autorità europea competente apra una valutazione formale sul trattamento dei dati da parte di SatoshiLabs e sul controllo esercitato su ShipMonk come responsabile esterno.
- Altri produttori di hardware wallet, dopo i casi Ledger, Trezor e SafePal, accelereranno probabilmente audit di sicurezza sui propri fornitori di logistica e sulle piattaforme di business intelligence collegate, in particolare su Metabase e strumenti simili.
- Ci si può aspettare un aumento delle campagne di phishing mirate che sfruttano i dati trapelati nei prossimi mesi, replicando lo schema già visto dopo il breach Ledger del 2020, con picchi attesi soprattutto verso i clienti statunitensi coinvolti nella seconda tranche.
- È probabile che emergano ulteriori dettagli sulla richiesta di estorsione di ShinyHunters, incluso se un pagamento sia stato effettuato o rifiutato da ShipMonk.
- Il caso rafforzerà la pressione del settore verso politiche di data retention più aggressive, spingendo i produttori a cancellare più rapidamente i dati di ordini conclusi da anni invece di conservarli indefinitamente presso fornitori terzi.
Domande frequenti
I miei fondi in criptovaluta sono a rischio dopo il breach Trezor?
No. Non ci sono evidenze pubbliche che chiavi private, seed phrase o PIN dei dispositivi siano stati esposti. La violazione ha riguardato dati di contatto e spedizione gestiti dal fornitore logistico ShipMonk, non l’infrastruttura crittografica di Trezor.
Quanti clienti Trezor sono stati coinvolti in totale?
Il totale comunicato al 21 settembre 2026 è di 80.689 record, arrotondati a circa 81.000, dopo che la stima iniziale di agosto (circa 14.000) è stata ampliata con l’aggiunta di 67.000 clienti statunitensi.
Cos’è la vulnerabilità CVE-2026-72898?
È una SQL injection non autenticata nell’endpoint di reimpostazione password di Metabase, con punteggio CVSS 10.0, che ha permesso l’accesso amministrativo all’istanza usata da ShipMonk.
Chi è ShinyHunters e che ruolo ha avuto?
ShinyHunters è un collettivo noto per campagne di furto dati ed estorsione contro aziende SaaS e provider cloud. Secondo le fonti giornalistiche, il gruppo avrebbe inviato email di estorsione a ShipMonk dopo l’esfiltrazione dei dati, anche se l’attribuzione tecnica completa non è stata resa pubblica in dettaglio.
Il breach SafePal è collegato a quello di Trezor?
Sono due incidenti separati, con vettori tecnici diversi (SQL injection su Metabase per ShipMonk, falla di autorizzazione in un plugin di tracciamento ordini per SafePal), avvenuti nello stesso periodo del 2026 e con un profilo di rischio simile per i clienti coinvolti.
Trezor rischia sanzioni GDPR in Europa?
È possibile. SatoshiLabs, l’azienda ceca dietro Trezor, ricade sotto il GDPR per i dati dei clienti europei. Un’eventuale sanzione dipenderebbe dalla valutazione delle autorità sulla due diligence verso ShipMonk, sui tempi di notifica e sulla proporzionalità della conservazione di dati risalenti al 2019-2021.
Cosa devo fare se ho ricevuto una notifica di violazione da Trezor?
Diffidare di richieste di seed phrase o PIN, verificare l’autenticità di eventuali comunicazioni fisiche o digitali che sembrano provenire da Trezor, e considerare misure preventive contro il SIM swap se il proprio numero di telefono era associato all’ordine.
Questo tipo di attacco può ripetersi con altri produttori?
Sì. Il precedente Ledger del 2020 (272.000 clienti coinvolti) e il caso SafePal del 2026 mostrano che il punto debole ricorrente del settore è la filiera di fulfillment e i sistemi analitici collegati, non il dispositivo hardware in sé.
