Hack del terzo trimestre 2026: 1,18 miliardi di dollari persi, e il 77% è passato fuori dalle revisioni di sicurezza

Tra il 1° luglio e il 28 settembre 2026 sono stati rubati 1.180,8 milioni di dollari in 107 incidenti, il 55% in più del secondo trimestre. Lo dice Hacken, società di sicurezza blockchain, nel suo report trimestrale. Il dato che merita di essere letto da vicino non è il totale: secondo Hacken il 77% delle perdite, 906,8 milioni, è passato da un fornitore compromesso, da una correzione già pubblica ma non ancora distribuita, o da un componente fuori dall'ultima revisione di sicurezza. Questo articolo ricostruisce i casi, uno per uno, con le fonti primarie dove esistono, e separa ciò che è documentato da ciò che è ancora stima.

I numeri del trimestre secondo Hacken

Il report copre il periodo dal 1° luglio al 28 settembre 2026. Ecco le cifre principali, tutte tratte dal documento di Hacken:

• 1.180,8 milioni di dollari rubati in 107 incidenti, il 55% in più in valore rispetto al secondo trimestre.
• Gli smart contract applicativi hanno pesato per 71 incidenti su 107, ma solo per 228,2 milioni, il 19% delle perdite. La maggior parte del valore è uscita da codice a livello di rete, fornitori, custodia e wallet.
• Per categoria di attacco, Hacken attribuisce il 48% delle perdite agli exploit di smart contract e il 40,4% (477,6 milioni) a controllo degli accessi e operazioni.
• Le multe comminate ai fornitori di servizi crypto in tutto il mondo sono state di soli 450.000 dollari.

Un confronto prudente: altre società di monitoraggio contano cifre diverse per lo stesso periodo, perché cambiano date di riferimento, soglie di inclusione e criteri di valutazione. Resoconti secondari citano per esempio CertiK intorno a 1,26 miliardi. Non abbiamo letto direttamente quel report, quindi lo segnaliamo solo come ordine di grandezza. Quello che conta è che le stime convergono su un trimestre vicino ai 1,2 miliardi.

Il 77%: tre vie, undici incidenti

La tabella di Hacken è il cuore del documento. Dice che tre percorsi d'attacco hanno concentrato la maggior parte delle perdite in appena 11 incidenti:

Due considerazioni sulla lettura corretta. Primo: il 77% non significa «77% di colpa dei fornitori». I fornitori compromessi sono la prima via, con il 35%. Le altre due riguardano correzioni già pubbliche ma non ancora applicate e componenti che nessuna revisione recente aveva coperto. Chi cita «il 77% degli hack arriva dai fornitori» sta leggendo male la tabella. Secondo: due incidenti di fornitori da soli, 411,5 milioni, superano gli altri 96 incidenti messi insieme (274,0 milioni). È questa sproporzione, più che il totale, a spiegare perché il tema è importante.

Una precisazione utile per chi guarda i casi: la tabella delle tre vie non include il caso Coldcard. Hacken lo tratta a parte, nella sezione sugli incidenti in cui revisioni precedenti non hanno visto le condizioni del problema. Lo racconteremo più avanti.

Bitget: 387,5 milioni da un prodotto di sicurezza di terze parti

Cosa è documentato. Il 24 settembre 2026 alle 18:31 UTC un attaccante ha avviato i primi trasferimenti non autorizzati da hot wallet e warm wallet di Bitget; alle 19:05 il sistema di riconciliazione ha rilevato l'anomalia e il controllo del rischio ha bloccato in automatico i prelievi. Lo afferma la pagina ufficiale di Bitget sull'incidente. Secondo Hacken sono stati sottratti 387,5 milioni di dollari su 11 blockchain, tra cui Ethereum, XRP Ledger, TRON, Arbitrum, Base e BNB Chain; XRP è stato l'asset più colpito, per circa 158 milioni. Bitget indica una cifra finale «verificata» di circa 388 milioni su 12 indirizzi.

Come, secondo Bitget. L'azienda sostiene che l'attaccante ha sfruttato una vulnerabilità zero-day in un prodotto di sicurezza di terze parti, ha ottenuto credenziali interne ad alto privilegio e ha scritto nel sistema dei wallet comandi di prelievo falsificati, che il sistema ha trattato come prelievi normali, aggirando i controlli di rischio. Dopo i trasferimenti, aggiunge Bitget, i responsabili hanno cancellato le tracce. Le chiavi private e i cold wallet, dice l'exchange, non sono stati toccati. Il 30 settembre Bitget ha pubblicato due rapporti indipendenti, di Mandiant (Google Cloud) e SlowMist, che a suo dire confermano il percorso. Hacken precisa che i rapporti, rilasciati da Bitget, collocano l'ingresso nel prodotto di terze parti e datano la prima attività malevola nei log disponibili al 31 agosto, quasi quattro settimane prima del furto.

Cosa non è documentato. Nelle fonti che abbiamo potuto leggere il fornitore del prodotto non è nominato. Non possiamo quindi attribuire responsabilità a un'azienda specifica, e non lo facciamo. Hacken riferisce inoltre che Bitget ritiene «molto probabile» un coinvolgimento nordcoreano, citando il comportamento degli indirizzi IP. È una valutazione di parte, non un'attribuzione confermata da un'autorità, e la riportiamo come tale. I rapporti di Mandiant e SlowMist li abbiamo letti solo attraverso la pagina di Bitget e il report di Hacken.

Gli utenti. Bitget afferma che i saldi degli utenti non sono stati toccati e che l'impatto è coperto dal proprio fondo di protezione. Hacken registra che gli operatori hanno coperto circa 410 milioni di dollari con fondi propri, di cui 387,5 milioni del fondo utenti di Bitget. I prelievi sono stati ripristinati a scaglioni: BTC il 28 settembre, ETH il 29, USDT il 30, il resto il 2 ottobre. Un'osservazione di lettura: la pagina di Bitget riporta per il fondo di protezione cifre diverse in punti diversi (nell'intestazione 3.705 BTC e oltre 314 milioni, nelle domande frequenti 5.500 BTC e oltre 464 milioni). Possono riferirsi a momenti diversi, ma chi vuole verificare il dato dovrebbe guardare gli indirizzi on-chain che l'exchange dichiara, non il riepilogo.

Il recupero. Secondo Hacken dal furto di Bitget sono stati congelati da Circle e Tether appena 0,34 milioni di dollari. Il tracciamento dei fondi, dice Bitget, prosegue, e l'azienda offre una ricompensa del 5% sugli importi congelati o recuperati grazie a segnalazioni.

Liquid Network: 36 minuti e una correzione a metà

Il caso Liquid è quello che meglio illustra la seconda via di Hacken, «correzione pubblica sfruttata prima del rilascio». La ricostruzione, tratta dal report e dal repository del software Elements su cui Liquid si basa:

• 1° settembre: una correzione parziale, che aggiungeva il contesto della transazione alla chiave della cache, è pubblica nel repository di Elements. Lascia però ambigua la codifica.
• 6 settembre: un attaccante sfrutta l'ambiguità nella cache di verifica delle range proof, cioè i controlli che dimostrano la validità di un importo senza rivelarlo. Una prova validata per un asset e un contesto viene riusata in un altro. Risultato: coniati 3.998,5 L-BTC senza i BTC corrispondenti. Un prelievo di circa 4.000 BTC viene poi confermato su Bitcoin.
• 7 settembre: l'attaccante, che si definisce white hat, restituisce circa 3.400 BTC (272 milioni di dollari) a condizione che il difetto venga corretto, e trattiene 598,5 BTC, circa 47 milioni, come «ricompensa» che si è assegnato da solo.
• 8 settembre: la correzione completa viene integrata nel codice (pull request n. 1600 del repository Elements, verificata da noi). 9 settembre: esce Elements 23.3.4.

Due note di cautela. La restituzione dell'85% è un fatto documentato da Hacken, ma la definizione di «white hat» è quella dell'attaccante, non un giudizio di terzi: nelle fonti che abbiamo letto non risulta alcuna autorizzazione preventiva a trattenere quei 47 milioni, e chiamarli ricompensa è una definizione dell'attaccante stesso. Secondo, la lezione di Hacken riguarda la gestione del ciclo di correzione: tra una patch pubblica ma incompleta e il rilascio della correzione definitiva sono passati otto giorni. I registri pubblici mostrano la cronologia; non stabiliscono come l'attaccante abbia individuato il difetto, e noi non lo affermiamo.

Tectonic e Cronos: un prezzo corretto e inutilizzabile

Il 30 agosto, secondo il post-mortem pubblicato da Cronos e riportato da crypto.news, un attaccante ha manipolato il prezzo di TONIC, il token di governance del protocollo di prestiti Tectonic, poco scambiato, e lo ha usato come garanzia per prendere in prestito 120,4 milioni di dollari su nove mercati. Hacken precisa che il prezzo è stato spinto in alto contro una liquidità sottile in circa 11 minuti e che Tectonic ha accettato il prezzo gonfiato come valore della garanzia.

Il punto, che Hacken ricava dai parametri pubblicati dal protocollo, è che nessuno dei tre controlli che avrebbero potuto fermare l'operazione era attivo: un limite di profondità di liquidità, un limite di velocità sulla crescita della capacità di prestito, e un tetto ai prestiti funzionante. I parametri di Tectonic indicano un tetto ai prestiti pari a 0 per ogni mercato, e nel suo codice derivato da Compound uno zero significa «nessun tetto». Il cofondatore di RedStone, Marcin Kazmierczak, ha detto a crypto.news che non si è trattato di un guasto dell'oracolo: l'oracolo ha riportato correttamente il prezzo del mercato che monitorava, e il protocollo lo ha accettato senza considerare se ci fosse liquidità sufficiente per vendere la garanzia a quel valore. Il codice di Tectonic aveva ricevuto quattro audit, uno sul nucleo della logica di prestito. Hacken ne trae una distinzione importante: verificare che un contratto calcoli correttamente la garanzia non dimostra che i parametri di un singolo asset siano sicuri nel suo mercato reale. Sono quelli che la tabella chiama «componente fuori dall'ultima revisione».

La risposta è stata insolita. I validatori di Cronos hanno fermato la catena al blocco 90.907.150 e l'hanno riportata al blocco 90.896.188, l'ultimo prima dell'attacco, cancellando 10.961 blocchi, cioè 1 ora e 54 minuti di storia. Sono stati annullati circa 111,2 milioni dei 120,4 coinvolti. Restano fuori 9,19 milioni (il 7,6%) che avevano già lasciato la catena. Il post-mortem di Cronos riconosce che la scelta è stata «difficile» e che l'operazione ha cancellato anche le transazioni di utenti normali nella stessa finestra. Il prezzo del recupero è stato rinunciare, in quel caso, all'irreversibilità della storia già registrata, un principio che molti considerano centrale per le blockchain pubbliche. Hacken lo segnala come una lacuna regolatoria: nessuno dei quadri normativi esaminati richiede alle aziende di dichiarare se il regolamento su una catena possa essere annullato.

Coldcard: un errore di build rimasto cinque anni

Qui Hacken non parla di fornitori compromessi. Il caso Coldcard riguarda l'entropia, cioè la casualità con cui vengono generate le seed. Per questo lo trattiamo separatamente dalla tabella del 77% e lo teniamo distinto dal caso Ledger, che è un attacco alla distribuzione e non un difetto di progetto.

Cosa dice il produttore. Coinkite, che produce Coldcard, ha pubblicato un'analisi tecnica. Secondo l'azienda, una modifica del 2021 al passaggio a una libreria di operazioni su curva ellittica ha fatto sì che la generazione delle seed attingesse a un generatore pseudocasuale software di MicroPython invece che al generatore hardware. Coinkite parla di un errore di integrazione in fase di build e di collegamento, non di una scelta di progetto: nel suo testo, «non c'è stato alcun fallback intenzionale» verso un generatore debole. La condizione di controllo del codice verificava se un'impostazione fosse definita anziché se fosse attiva, quindi il compilatore non si è fermato. Le versioni interessate sono il firmware 4.0.1-4.1.9 per Mk2 e Mk3 e le release equivalenti per i modelli successivi. Coinkite stima, in via preliminare, un'entropia effettiva di circa 40 bit sui Mk2 e Mk3 e di circa 72 bit su Mk4, Mk5 e Q, contro i 128 bit previsti per una seed di 12 parole. L'azienda afferma anche che i dispositivi non sono stati hackerati o controllati da remoto: gli attaccanti hanno rigenerato offline le chiavi corrispondenti.

Cosa dicono i dati sul furto. Le prime sottrazioni sono iniziate il 30 luglio. TRM Labs, in un'analisi del 5 agosto, contava già circa 1.816 BTC (circa 116 milioni) da oltre 5.200 indirizzi in quattro ondate, citando il conteggio di Galaxy Research, e precisava che i dati erano preliminari e che i modelli di transazione suggerivano più di un attaccante: TRM non ha attribuito il furto a un attore specifico. Nel report successivo, Hacken indica 1.789,28 BTC su 8.865 indirizzi attribuiti da Galaxy Research all'incidente, circa 114,7 milioni di dollari al momento del furto, e stima le perdite in circa 115 milioni. I numeri sono diversi perché hanno date e metodi diversi. Una stima di circa 130 milioni circolava a inizio agosto tra ricercatori esterni; Coinkite ha detto di non voler speculare sull'entità delle perdite e di voler pubblicare un'analisi completa quando sarà sicuro farlo.

Il punto che interessa l'inchiesta. Hacken scrive che una revisione a pagamento del marzo 2022 aveva coperto il rafforzamento dell'entropia ma non aveva individuato la condizione di build. Coinkite lo conferma nella sostanza: la revisione «ha verificato che il codice del generatore hardware fosse presente nel binario, ma non ha verificato quale implementazione venisse raggiunta dal percorso di generazione delle seed». È il tema del report: un controllo che guarda il componente giusto può non vedere il collegamento sbagliato. Il difetto, dice Hacken, è rimasto non rilevato per oltre cinque anni. Coinkite sostiene inoltre di aver usato, poche settimane prima dell'incidente, uno dei migliori modelli di intelligenza artificiale disponibili per rivedere il codice, senza che trovasse il problema. È un'affermazione dell'azienda, non verificata da noi.

Cosa cambia per chi la possiede. L'aggiornamento del firmware non ripara le seed già generate. Secondo Coinkite, le seed create su firmware interessato senza almeno 50 lanci di dadi indipendenti e privati, e senza una passphrase BIP-39 forte e unica, vanno considerate a rischio e sostituite generando una nuova seed su firmware corretto e spostando i fondi. L'azienda non considera a rischio, per questo solo difetto, le seed create con almeno 50 lanci di dadi. Le istruzioni complete sono nel suo avviso ufficiale: seguile da lì, non da un riassunto.

Cosa non è nei dati del trimestre: il caso Ledger

Il periodo coperto da Hacken finisce il 28 settembre. L'incidente Ledger/CryptoBilis è di ottobre: i primi svuotamenti segnalati risalgono al 9 ottobre, e sulle perdite esistono solo stime di terzi, tra 86 e 103 milioni di dollari. Non è dunque nei numeri di questo articolo, e Ledger non ha pubblicato un totale. È però lo stesso schema in forma diversa: una parte della filiera, in questo caso la distribuzione, esce dal campo di ciò che le revisioni di sicurezza ispezionano. Abbiamo ricostruito il caso, con ciò che è confermato e ciò che no, nel nostro articolo Ledger e l'impianto LTE.

C'è un passaggio del report di Hacken che collega i due mondi. L'analisi delle norme europee osserva che nessuno dei quadri esaminati copre i dispositivi che i clienti acquistano per l'autocustodia, e che il regolamento DORA raggiunge un fornitore di hardware solo quando presta servizi a un'azienda regolata. Il difetto di Coldcard, nota Hacken, è rimasto non rilevato per oltre cinque anni. Chi compra un hardware wallet oggi è, in sostanza, fuori da quasi tutte le tutele regolamentari sulla sicurezza dei componenti.

Il recupero: un terzo, e con meccanismi molto diversi

Hacken calcola che circa 387 milioni di dollari, il 33% delle perdite lorde, siano stati restituiti o annullati. Il report distingue tre meccanismi, che funzionano in modo diverso e non sono equivalenti:

• Restituzione da parte dell'attaccante: 272 milioni (Liquid Network, l'85% dei 319 milioni sottratti). Dipende interamente dalla volontà di chi ha sottratto.
• Intervento sullo stato della catena: circa 116 milioni, tra cui il rollback di Cronos (111,2 milioni dei 120,4 coinvolti), un ripristino da snapshot su BounceBit e un sequestro di 2,1 milioni in ATOM su Cosmos Hub. Dipende dai validatori, e costa in termini di finalità.
• Congelamento da parte degli emittenti: circa 0,34 milioni (Circle e Tether, dal furto Bitget). Dipende dall'emittente e dalla velocità.

In più, gli operatori hanno coperto circa 410 milioni di dollari agli utenti con fondi propri, e questi utenti sono stati rimborsati mentre i beni sottratti sono rimasti agli attaccanti. Il quadro finale è chiaro: il recupero reale dal mercato è stato piccolo, e la rete di salvataggio è stata soprattutto la solidità patrimoniale di chi gestiva i fondi.

Cosa dicono i regolatori, secondo Hacken

La parte regolatoria del report è più breve ma contiene due indicazioni. Primo, i regolatori cominciano a verificare se i controlli reggano nel funzionamento continuo e non solo in un singolo momento di revisione. Secondo, Hacken segnala che i regolatori attribuiscono sempre più spesso responsabilità personali a fondatori e dirigenti per exploit e incidenti. Le multe a livello mondiale ai fornitori di servizi crypto, 450.000 dollari, sono molto piccole rispetto a 1,18 miliardi sottratti. Segnaliamo il confronto, senza trarne una conclusione sul sistema sanzionatorio: sono dati su cose diverse (sanzioni emesse e perdite subite) e coprono giurisdizioni diverse.

Che cosa significa per te

Questa sezione è informazione generale, non consulenza finanziaria.

Se tieni fondi su un exchange

Il caso Bitget mostra che le prove di riserve misurano una cosa e un attacco ne colpisce un'altra. Una proof of reserves dice se l'exchange dichiara asset sufficienti a coprire i saldi; non dice nulla su quanto siano protetti gli accessi interni e i sistemi di prelievo. Resta uno strumento utile, ma non risponde alla domanda su come un'azienda gestisca i propri fornitori. Come si legge e come si verifica lo spieghiamo nella guida alla proof of reserves. In questo trimestre, secondo Hacken, gli utenti degli exchange coinvolti sono stati rimborsati dagli operatori: non è una garanzia valida per tutti i casi futuri, è un fatto osservato di questo periodo.

Se usi l'autocustodia

• Se possiedi una Coldcard, controlla l'avviso ufficiale di Coinkite per il tuo modello e la data di creazione della seed. Aggiornare il firmware non basta.
• Se compri un hardware wallet, compra dal produttore e diffida dei canali non ufficiali. Il caso Ledger ne è la dimostrazione.
• Non affidarti a un solo dispositivo per una somma importante. TRM Labs, commentando il caso Coldcard, osserva che configurazioni multisignature che combinano dispositivi progettati in modo indipendente e con entropia generata in modo indipendente offrono una difesa in profondità, perché riducono la dipendenza da una sola implementazione. È una configurazione che richiede attenzione: la nostra guida al multisig 2 di 3 spiega come impostarla. E ricorda che un piano di custodia completo include anche chi può accedere ai fondi se tu non ci sei: il piano ereditario per Bitcoin.

Se usi la finanza decentralizzata

Il caso Tectonic non riguarda un codice sbagliato in senso stretto. Riguarda i parametri di un singolo asset in un protocollo a prestito. Quando un protocollo accetta un token poco scambiato come garanzia, il prezzo «corretto» può non essere un prezzo utilizzabile. Prima di depositare fondi in un protocollo, vale la pena sapere quali asset accetta come garanzia e se esistono limiti di prestito reali, non a zero.

Cosa ancora non sappiamo

• Il nome del fornitore del prodotto di sicurezza usato da Bitget. Nelle fonti consultate non compare.
• L'identità degli attaccanti di Bitget, Liquid, Tectonic e Coldcard. Bitget ritiene probabile una responsabilità nordcoreana, ma è una valutazione di parte.
• Il bilancio finale di Coldcard: TRM e Hacken parlano di dati preliminari, e Coinkite deve ancora pubblicare la sua analisi completa.
• Se i rapporti di Mandiant e SlowMist su Bitget verranno resi pubblici per intero. Li abbiamo letti solo nei riassunti di Bitget e di Hacken.
• La parte di perdite del trimestre non ancora censita. Hacken e TRM avvertono che le vittime emergono spesso dopo mesi.
• Quanto della scelta di Hacken, una società che vende revisioni di sicurezza, di classificare le perdite per «fuori dall'ultima revisione» dipenda dal modo in cui ha definito le categorie. La classificazione è sua, e un altro analista potrebbe tracciare i confini in modo diverso.

La nostra valutazione

I fatti documentati dicono una cosa precisa e meno comoda del solito racconto sugli hack. Nel terzo trimestre 2026 la parte più grande del denaro non è uscita da un contratto scritto male, ma da punti della filiera che nessuna revisione stava guardando: uno strumento di sicurezza di un fornitore, un difetto la cui correzione era pubblica ma incompleta, un parametro di rischio, una riga di configurazione del compilatore. Gli smart contract applicativi, il bersaglio tradizionale degli audit, hanno prodotto la maggior parte degli incidenti ma solo il 19% delle perdite.

Questo non rende inutili gli audit, e non autorizza a dire che la responsabilità sia dei fornitori. Chi gestisce un exchange o un protocollo sceglie i propri fornitori, e Hacken stessa nota che le revisioni non coprivano componenti che pure potevano toccare prezzi, messaggi, governance o prestiti. Il lettore comune ricava invece un criterio pratico: la domanda da farsi su un servizio non è solo «è stato verificato?», ma «che cosa non è stato verificato?». Pochi operatori rispondono a questa seconda domanda in modo esplicito, e i dati di questo trimestre suggeriscono che sia quella che conta di più.

Aggiorneremo l'articolo se Coinkite pubblicherà l'analisi completa, se Bitget renderà pubblici i rapporti indipendenti o nominerà il fornitore coinvolto, o se Hacken rivedrà le cifre.

Domande frequenti