Charles Hoskinson: SecondFi App compromessa, protocollo Cardano non compromesso
Charles Hoskinson ha presentato un nuovo aggiornamento tecnico sull'incidente del wallet SecondFi, separando il sospetto guasto a livello di applicazione dal protocollo di Cardano, dall'infrastruttura open source dei wallet e dalla crittografia di base.
By SongMarketCap
Charles Hoskinson ha diffuso un nuovo aggiornamento in diretta il 24 giugno 2026, dopo aver esaminato il TypeScript minificato dell'applicazione SecondFi e aver condotto un'analisi forense indipendente sull'incidente del wallet. L'aggiornamento si è concentrato su come sembra essersi verificato l'attacco, sul perché il caso indichi il codice dell'applicazione di SecondFi e sul perché le prove disponibili non indichino un guasto nel protocollo di Cardano, nei nodi core, nelle librerie wallet open source o nella crittografia fondamentale.
Sicurezza del protocollo Cardano separata dall'incidente SecondFi
La revisione di Hoskinson ha esaminato se l'incidente di SecondFi fosse limitato a una sola applicazione o collegato a un problema più ampio nella supply chain crittografica di Cardano. La sua valutazione non ha trovato indicazioni che le librerie crittografiche open source di Cardano usate dalla maggior parte dei wallet nell'ecosistema fossero compromesse.
La revisione tecnica ha coperto la derivazione delle chiavi, la costruzione delle firme, la generazione delle parole di recupero, i meccanismi dei wallet HD e la selezione UTXO. Tali componenti sono stati descritti come coerenti con l'infrastruttura open source utilizzata nei wallet Cardano prima dell'incidente.
Le transazioni anomale collegate a SecondFi erano invece legate alla codebase closed source dell'applicazione, che era stata modificata rispetto agli standard open source. La distinzione è centrale nell'aggiornamento, la rete di Cardano, i nodi, la crittografia a livello di protocollo e l'infrastruttura dei wallet open source sono stati separati dal presunto guasto all'interno di una specifica applicazione wallet.
Il codice di SecondFi e gli standard di audit dei wallet al centro dell'attenzione
La fase successiva del caso dipende ora da un audit indipendente. Ci si aspetta che tale processo spieghi come sia avvenuto l'incidente, chi ne sia responsabile e quale piano di rimedio sarà offerto agli utenti colpiti.
Hoskinson ha evitato di pubblicare il percorso tecnico specifico dell'attacco in attesa di ulteriori comunicazioni da Emurgo o dal team di SecondFi. L'aggiornamento ha invece posto la verifica formale, la disciplina di audit e la responsabilità a livello di applicazione al centro dell'indagine.
L'incidente ha anche riaperto la più ampia questione degli standard dei wallet nell'ecosistema Cardano. Lace e Daedalus sono stati citati come esempi di software wallet sviluppati con visibilità open source e revisione esterna. La posizione più ampia presentata nell'aggiornamento è che il codice dei wallet che gestiscono i fondi degli utenti dovrebbe essere open source, sottoposto ad audit regolari e mantenuto con uno scrutinio condiviso quando componenti crittografici interessano l'ecosistema più ampio.
La preoccupazione non riguardava solo l'esistenza di una vulnerabilità. Il problema più profondo è la modifica di codice crittografico sensibile al di fuori della revisione pubblica. Per i costruttori di wallet, il caso SecondFi pone ora il design dell'applicazione, l'implementazione crittografica, la storia degli audit e la trasparenza open source direttamente dentro la discussione sulla sicurezza.
Sicurezza degli utenti, affermazioni di white hat e piano di rimedio
L'aggiornamento ha affrontato anche le prime affermazioni secondo cui alcuni fondi potrebbero essere stati spostati da un attore white hat invece che dall'attaccante. Tale affermazione richiede ancora conferma tramite il processo di audit o un piano di rimedio ufficiale, lasciando irrisolte le procedure di recupero e restituzione dei fondi.
Hoskinson ha affrontato anche la questione se le 24 parole di recupero del wallet fossero compromesse. In base al codice che ha esaminato, le parole di recupero in sé non sembravano essere compromesse in quella fase. L'aggiornamento ha anche osservato che ciò è difficile da verificare senza pieno accesso all'intero processo di derivazione delle chiavi, soprattutto nei casi in cui i wallet possano essere stati generati in Yoroi e poi importati in SecondFi, oppure generati direttamente dentro SecondFi.
Fino al completamento dell'audit e del processo di rimedio, l'applicazione SecondFi dovrebbe essere considerata compromessa. L'approccio più sicuro descritto nell'aggiornamento è lasciare le chiavi a riposo ed evitare di effettuare transazioni tramite qualsiasi wallet SecondFi.
L'aggiornamento ha anche chiarito i limiti del ruolo di Input Output. L'azienda non ha alcuna autorità speciale per congelare, annullare o recuperare fondi a livello di protocollo. Cardano non include meccanismi di intervento di questo tipo, allineando la rete a un modello globale di criptovalute in cui nessuna singola azienda o individuo controlla i saldi degli utenti.
L'indagine ora si concentra su tre risultati concreti, un audit indipendente, una spiegazione tecnica dai team responsabili di SecondFi e un piano di rimedio per gli utenti. Per l'ecosistema Cardano più ampio, l'aggiornamento in diretta circoscrive il caso al codice dell'applicazione, alle modifiche ai wallet closed source e alla responsabilità di audit, mantenendo il livello di protocollo, le librerie dei wallet open source e l'infrastruttura crittografica core al di fuori del guasto segnalato.