Ledger corregge una vulnerabilità dell'app Ethereum: rischio di firme su transazioni diverse da quelle mostrate a schermo

Chi utilizza un dispositivo Ledger per gestire Ether o token ERC20 dovrebbe aprire Ledger Live e verificare quale versione dell'app Ethereum è installata. Le versioni precedenti alla 1.22.2 non includono una correzione di sicurezza. Il problema colpiva il presupposto centrale di un hardware wallet: che lo schermo del dispositivo mostri esattamente ciò che sta per essere firmato. Il caso è diventato pubblico il 24 agosto 2026, quando la società di sicurezza TestMachine ha pubblicato la propria analisi. La patch era già pronta a quel punto. Tra le due date si è aperta una disputa su chi abbia individuato per primo la falla e su quando Ledger abbia effettivamente distribuito la correzione. Per l'utente, il punto decisivo resta la versione installata e il tema di eventuali autorizzazioni (approvals) concesse in passato. Che cosa è successo, in concreto La vulnerabilità non riguardava il firmware del dispositivo né la custodia della chiave privata. Il problema era nell'app Ethereum, il componente installabile sul device per Ether e token ERC20, che prepara la transazione, la visualizza e raccoglie la conferma. Nelle versioni vulnerabili l'ordine delle operazioni poteva essere alterato. Un'applicazione web malevola, con accesso al dispositivo collegato, poteva inviare un secondo comando di firma mentre la prima transazione era ancora a schermo in attesa di revisione. L'app sostituiva allora i dati in memoria senza aprire una nuova schermata di verifica: sul display rimaneva la transazione "innocua" appena controllata, ma la conferma dell'utente finiva per applicarsi ai dati sostituiti. Secondo i ricercatori, lo schema è stato riprodotto su Ledger Flex. Poiché i dispositivi condividono in larga parte il codice dell'app Ethereum, Nano X, Nano S Plus, Stax e Apex sono considerati potenzialmente esposti. Ledger non ha indicato quale versione abbia introdotto l'errore; il confronto dei ricercatori parte dalla 1.22.1, la versione etichettata in precedenza con data 27 maggio 2026. "Clear signing": perché lo schermo è la vera promessa di sicurezza Per clear signing si intende la visualizzazione in chiaro sul display dell'hardware wallet dei dati completi della transazione prima della conferma: indirizzo del destinatario, importo e, in caso di chiamate a smart contract, l'azione richiesta. È il motivo per cui un hardware wallet ha senso: anche con un PC compromesso, un browser manipolato o un sito fasullo, lo schermo indipendente del dispositivo dovrebbe rendere visibile qualsiasi alterazione prima della pressione del pulsante. La chiave privata non esce dal dispositivo, che firma internamente. La falla colpiva proprio questo anello: la chiave restava al sicuro e il firmware non veniva toccato, ma l'utente poteva finire per firmare qualcosa di diverso da quanto letto. Se il display non è più vincolante, sotto questo profilo il dispositivo perde il vantaggio rispetto a un software wallet su una macchina infetta. Il nucleo tecnico: race condition e comandi APDU Una race condition è un bug il cui esito dipende dall'ordine con cui vengono processati due comandi quasi simultanei. È insidiosa perché, nella maggior parte dei casi, tutto sembra funzionare correttamente; emerge quando qualcuno forza intenzionalmente la sequenza. APDU è il formato dei comandi con cui smart card e hardware wallet comunicano con il computer. Ogni firma è composta da più passaggi di questo tipo. L'app Ethereum manteneva uno stato interno su quale transazione fosse in revisione, ma tale stato poteva essere sovrascritto mentre la revisione era ancora in corso. WebHID nel browser: perché un sito può parlare con il device WebHID è un'interfaccia del browser che permette a un sito di comunicare direttamente con un dispositivo USB collegato, dopo che l'utente ha concesso esplicitamente il permesso. È un tassello chiave per usare un hardware wallet in una dApp, ma avvicina il sito al dispositivo più di quanto molti utenti immaginino. L'attacco descritto richiede che l'utente abbia già autorizzato l'accesso a un sito manipolato o dirottato e che avvii una transazione da lì. Non è un attacco remoto contro un dispositivo scollegato. Questo restringe la platea, ma non riduce la rilevanza: chi usa spesso DEX, bridge o interfacce di staking concede questi permessi di frequente. Approval al posto di transfer: perché le autorizzazioni illimitate sono un rischio In uno scambio di firma, il danno raramente nasce dal trasferimento in sé, ma da ciò che può sostituirlo. Un token approval è l'autorizzazione data a uno smart contract a spendere una certa quantità di token in futuro senza confermare ogni singolo addebito. Molte applicazioni richiedono approvals "illimitate" per comodità. Un approval non scade: resta valido finché non viene revocato. La differenza è netta: - Un transfer ti costa esattamente l'importo confermato. - Un approval illimitato può, nel peggiore dei casi, esporre l'intero saldo del token, nel momento scelto dal beneficiario. Aggiornare l'app Ethereum alla 1.22.2: come fare via Ledger Live La versione 1.22.2 chiude il vettore con due misure: l'app rifiuta una nuova sessione di firma mentre una revisione è in corso e scarta una conferma in ingresso se lo stato non coincide più con quanto mostrato a schermo. L'aggiornamento è semplice: collegare il dispositivo, aprire in Ledger Live il gestore delle applicazioni installate e aggiornare l'app Ethereum. I saldi non cambiano: le chiavi derivano dalla recovery phrase e non risiedono nell'app. Anche rimuovere e reinstallare l'app non comporta perdita di fondi. Come verificare la versione installata Ledger Live mostra il numero di versione di ogni app nel device manager. Se l'app Ethereum è alla 1.22.2 o superiore, la correzione è presente. Se è alla 1.22.1 o inferiore, manca. Controllare solo la versione di Ledger Live non basta. Perché un aggiornamento firmware non aggiorna anche l'app Ethereum Firmware, Ledger Live e le singole app (coin apps) vengono mantenuti e aggiornati separatamente. È un punto che in pratica genera spesso confusione: si può aggiornare il firmware e restare comunque con un'app Ethereum obsoleta. Questo distingue anche i casi di sicurezza: nel caso Coldcard il problema riguardava la generazione del seed (quindi era necessario un nuovo seed); le vulnerabilità BitBox erano nel firmware. Qui l'errore è a un livello superiore, in un'app sostituibile, quindi basta aggiornare l'app. Non è necessario rigenerare la recovery phrase. Revocare le vecchie autorizzazioni: il secondo passo dopo l'update L'aggiornamento protegge le firme future, ma non annulla ciò che è stato approvato in passato. Se negli ultimi mesi sono state usate dApp, conviene controllare le autorizzazioni ancora aperte sul proprio indirizzo. Block explorer e interfacce specializzate mostrano quali contratti possono spendere quali token. Le autorizzazioni a contratti non più utilizzati possono essere revocate una per una. La revoca è una normale transazione e comporta fee di rete; per questo la pulizia si fa meglio in momenti di commissioni basse. Un effetto collaterale spesso sottovalutato: ogni revoca compare nello storico e genera costi. Chi tiene una documentazione ordinata delle operazioni avrà meno problemi in fase di dichiarazione; i comuni strumenti fiscali e di portfolio importano questi eventi in automatico. La disputa sulla disclosure tra Ledger e TestMachine Esistono due ricostruzioni, non coincidenti, entrambe riportate come dichiarazioni di parte e non confermate indipendentemente. Il CTO di Ledger, Charles Guillemet, ha affermato che il laboratorio interno Ledger Donjon avrebbe individuato la falla e che la correzione sarebbe stata distribuita circa due settimane prima della pubblicazione. Secondo la sua versione, TestMachine avrebbe contattato il programma bug bounty solo in un secondo momento. Ha inoltre descritto le affermazioni della società di sicurezza come un tentativo di generare timori per ottenere attenzione. TestMachine replica che il proprio sistema di test, Azimuth, avrebbe scoperto la debolezza durante un run automatizzato su Ledger Flex e che i risultati sarebbero stati condivisi con Ledger. Al momento della pubblicazione, sostiene, non era disponibile alcuna correzione. Alcuni elementi verificabili stanno nel mezzo: il changelog della 1.22.2 riporta la data 12 agosto 2026; il tag firmato nel repository sorgente è del 13 agosto. La release è risultata visibile come pubblicata solo intorno al 24 agosto, in concomitanza con l'analisi della società di sicurezza. Nel frattempo, un utente non avrebbe potuto trovarla nell'overview delle release. La ricostruzione tecnica della sequenza, con queste date, è stata assemblata da CryptoSlate. Ci sono state perdite? Cosa si sa finora Sulla base delle informazioni rese disponibili da entrambe le parti, non esistono casi confermati di sfruttamento della falla. Non risultano perdite documentate e, in ogni caso, questo vettore non consentiva di estrarre le chiavi private. Resta una cautela: una firma ottenuta in questo modo apparirebbe on-chain come una firma volontaria. Un utente se ne accorgerebbe probabilmente solo quando, in seguito, i token iniziassero a uscire, attribuendo l'evento a un phishing ordinario. L'assenza di casi confermati non consente quindi di concludere con certezza che non ci siano stati. Cosa insegna l'episodio su hardware wallet e autocustodia La conclusione utile non è respingere gli hardware wallet. L'attacco richiedeva accesso già concesso al dispositivo e un'applicazione malevola; non toccava la chiave; ed è stato corretto. La lezione è che un hardware wallet sposta la fiducia dal computer a un dispositivo con schermo, ma quel dispositivo è composto da firmware, applicazioni e software di supporto, aggiornati separatamente. La sicurezza non è uno stato acquisito con l'acquisto: è manutenzione continua. Include aggiornare le app, ripulire periodicamente le autorizzazioni e, per importi elevati, aggiungere un secondo livello di conferma. Cosa fare ora - Controllare la versione e aggiornare: in Ledger Live, verificare l'app Ethereum. Sotto la 1.22.2 va aggiornata; il solo update del firmware non basta. - Ripulire gli approvals: controllare quali contratti possono spendere i token e revocare ciò che non serve. - Documentare le operazioni: revoche e riallocazioni generano fee e restano nello storico; conviene registrarle man mano. (Aggiornato al 25 agosto 2026. Questo articolo non è consulenza finanziaria. Prezzi e strutture commissionali cambiano; verificare le condizioni con il fornitore prima dell'acquisto.)