Un flag di build lasciato dormiente nel firmware del wallet hardware COLDCARD per cinque anni è stato collegato al furto di circa 116 milioni di dollari in bitcoin, dopo che un'impostazione di compilazione errata ha indebolito silenziosamente la casualità utilizzata per generare i seed degli utenti. Quello che era iniziato come una scelta di configurazione trascurata si è trasformato in uno dei più grandi furti di autocustodia registrati nel 2026.

Secondo Block Engineering, il firmware COLDCARD interessato definiva la macro MICROPY_HW_ENABLE_RNG come zero, mentre la libreria libngu verificava solo se la macro esisteva — non il suo valore effettivo. Ciò ha causato il ripiego del sistema sul generatore di numeri pseudo-casuali deterministico Yasmarang di MicroPython, che produce output prevedibili e compromette fondamentalmente l'entropia che un wallet hardware è progettato per garantire.

Come il Flag di Build è Divenuto Centrale nell'Esploitazione

Un flag di build è un'opzione di compilazione che determina quali funzionalità vengono attivate quando il software viene assemblato in un binario distribuibile. In questo caso, il flag era destinato ad attivare un vero generatore di numeri casuali hardware. Invece, è stato impostato a zero e la logica di verifica a valle non ha mai rilevato la discrepanza.

Poiché il flag governava il modo in cui le chiavi private venivano generate (seeded), le conseguenze sono state gravi. I seed servono come segreto master dietro ogni indirizzo controllato da un wallet. Una casualità prevedibile al momento della generazione del seed significa che un attaccante che comprende la fallacia può ricostruire le chiavi private risultanti.

TRM Labs ha riportato che gli attaccanti hanno sottratto 1.816 BTC — valutati a circa 116 milioni di dollari — da oltre 5.200 indirizzi in quattro ondate separate. La portata della campagna indica che la vulnerabilità ha interessato un'ampia popolazione di dispositivi piuttosto che un gruppo isolato di utenti.

Block Engineering ha dichiarato che lo sfruttamento attivo era già in corso quando ha pubblicato la sua analisi il 30 luglio 2026, e ha indirizzato gli utenti al produttore del wallet, Coinkite, per il rapporto definitivo.

Cosa ha Fallito tra Sviluppo, Revisione delle Release e Controlli di Sicurezza

La sopravvivenza di un flag errato attraverso molteplici cicli di rilascio indica lacune nella pipeline di verifica. La sicurezza del wallet hardware dipende da una firma del codice rigorosa, build riproducibili e controlli di integrità rigorosi — proprio le salvaguardie che avrebbero dovuto identificare una macro RNG con valore zero.

Coinkite ha quantificato direttamente il deficit di entropia. I seed generati su dispositivi Mk4, Q ed Mk5 con firmware precedente alla correzione contenevano approssimativamente 72 bit di entropia invece dei 128 bit previsti — una riduzione che rende fattibile la ricostruzione brute-force delle chiavi private. In termini crittografici, 72 bit rappresenta uno spazio delle chiavi circa 2^56 volte più piccolo dello standard previsto a 128 bit, superando la soglia da computazionalmente infattibile a pratico per un attaccante ben dotato di risorse.

Coinkite ha avvertito che i fondi generati su firmware interessato rimangono a rischio a meno che il seed non sia stato creato con almeno 50 lanci di dadi indipendenti e privati, o che il wallet non fosse protetto con una passphrase BIP-39 forte e unica. La bonifica è ulteriormente complicata dalla frammentazione attraverso cinque tracce di rilascio firmware separate, anziché una singola patch universale.

La distinzione tra verificare l'esistenza di una macro e verificare il suo valore rappresenta il tipo di sottile fallacia logica che i controlli di integrità automatizzati e i processi di revisione del codice sono progettati per rilevare. La maggior parte degli attacchi documentati ai wallet hardware si è basata su manomissione fisica, tecniche side-channel o compromissione della catena di approvvigionamento; una fallacia di configurazione in fase di compilazione che indebolisce silenziosamente l'entropia nel corso di anni di produzione rappresenta una modalità di fallimento distinta che i modelli di minaccia esistenti potrebbero non aver anticipato adeguatamente. Gli utenti di wallet hardware si aspettano uno standard di protezione superiore rispetto alle applicazioni convenzionali proprio perché un seed compromesso non può essere ruotato con la stessa facilità di una password.

Implicazioni Più Ampie per gli Utenti di Wallet Hardware e per il Settore

Una perdita a nove cifre mette direttamente in discussione la proposta di valore fondamentale del cold storage. I tempi sono significativi: l'adozione dell'autocustodia è accelerata dopo il collasso di FTX nel novembre 2022 che ha eroso la fiducia negli scambi centralizzati, rendendo le vulnerabilità dei wallet hardware di questa entità particolarmente dannose per la credibilità dell'ecosistema. CoinDesk ha riportato il 31 luglio 2026 che l'esploitazione aveva già provocato il furto di quasi 600 BTC, del valore di circa 38 milioni di dollari all'epoca. Gli analisti hanno suggerito che l'incidente potrebbe fungere da catalizzatore per l'interesse verso custodi regolamentati ed ETF spot su bitcoin.

Il sentiment di mercato ha riflesso la perturbazione. Il Fear & Greed Index ha registrato un valore di 25, indicando Paura Estrema, mentre il bitcoin scambiava intorno ai 64.766 dollari.

Per gli utenti interessati, le domande pratiche immediate sono: quale traccia firmware si applica al loro dispositivo, se il loro seed soddisfaceva i criteri di esenzione per lanci di dadi o passphrase, e con quale rapidità i fondi possono essere migrati verso un ambiente sicuro. Al 6 agosto 2026, Coinkite non aveva ancora pubblicato la propria cifra cumulativa delle perdite o un elenco di indirizzi degli attaccanti, lasciando il conteggio di TRM Labs come riferimento principale.

L'incidente sottolinea che le configurazioni di build legacy non sono inerti. Un singolo valore in fase di compilazione, lasciato inesaminato attraverso anni di cicli di rilascio, si è tradotto in rischio sistemico per un prodotto commercializzato sulla base della sicurezza — un promemoria che il rigore operativo in fase di build è inseparabile dalla fiducia riposta nelle soluzioni di autocustodia.