Electrum 4.8.3 corregge la falla che trasformava il tasto delle commissioni in un furto di bitcoin

blockchain that runs exactly as written when it is called, holding and moving funds according to its code, without an intermediary able to change the outcome.">smart contract holding reserves of two or more tokens, supplied by users, that a decentralized exchange uses to execute trades automatically at a price set by a formula.">pool diverge, compared with simply holding the same tokens in a wallet. It becomes permanent when the provider withdraws.">Il wallet Electrum ha rilasciato la versione 4.8.3 per chiudere una falla che permetteva a un server malevolo di nascondere un pagamento appena inviato dall’utente e di mostrarne al suo posto uno falso, del tutto simile. Quando l’utente premeva il pulsante per alzare la commissione, il wallet autentico firmava il furto. Lo sviluppatore di Electrum SomberNight ha reso noto il problema in un advisory di sicurezza su GitHub pubblicato il 24 ottobre 2026 alle 12:52 UTC e valutato High, cioè di gravità alta. Nelle sue note si legge che «alcuni server stanno eseguendo questo attacco nel mondo reale». Almeno un utente ha perso dei fondi. Né l’advisory né gli articoli usciti finora indicano un importo, un numero di vittime o i nomi dei server coinvolti.

Tutte le versioni di Electrum precedenti alla 4.8.3 sono colpite. Secondo le note di rilascio del progetto, la versione è stata etichettata il 23 ottobre, mentre i binari sono usciti insieme alla divulgazione pubblica il 24 ottobre. Non è stato assegnato alcun numero CVE.

In questa vicenda non c’è alcun malware e nessun falso aggiornamento, il metodo dietro i grandi furti ai danni di Electrum tra il 2018 e il 2020. L’attacco del 2026 funziona contro il wallet autentico e non modificato. Gli servono due cose: la fiducia che Electrum riponeva nel proprio server per i pagamenti non ancora inclusi in un blocco, e un utente che vuole far passare più in fretta un pagamento rimasto in sospeso.

Electrum si fidava del server sui pagamenti non confermati

Electrum è un client leggero. Non scarica la blockchain di bitcoin. Si collega a un server, che gli indica quali transazioni riguardano gli indirizzi del wallet. Per le transazioni già incluse in un blocco, il wallet verifica ciò che gli viene detto confrontandolo con le intestazioni dei blocchi, un metodo chiamato simplified payment verification (SPV): l’advisory precisa che le transazioni già minate erano controllate in questo modo. I pagamenti ancora in attesa di un blocco no.

Le transazioni non confermate stanno nella mempool, la sala d’attesa dei pagamenti che i miner non hanno ancora preso in carico. Per quelle, Electrum si affidava al racconto del server. L’advisory descrive questa scelta come una parte documentata del progetto, non come un bug sfuggito agli sviluppatori. Il bug era ciò che quella fiducia consentiva una volta combinata con un’altra funzione.

Quella funzione è la Replace-by-Fee, o RBF. Un pagamento inviato con una commissione troppo bassa può restare fermo per ore. La RBF permette a chi invia di trasmettere una nuova versione dello stesso pagamento con una commissione più alta, che sostituisce la precedente nelle code dei miner. Electrum la propone come aumento della commissione su qualsiasi pagamento in uscita ancora in sospeso. La nostra guida su come le transazioni crypto viaggiano dal wallet al blocco spiega più nel dettaglio commissioni e mempool.

Come funziona lo scambio, passo per passo

Il titolo stesso dell’advisory riassume lo schema: «Malicious server can replace a just-broadcast tx and try to trick user into RBF-ing it», cioè un server malevolo può sostituire una transazione appena trasmessa e tentare di indurre l’utente a sottoporla a RBF. In ordine, secondo il meccanismo descritto dall’advisory:

1. L’utente invia bitcoin da Electrum. Il wallet firma il pagamento e lo trasmette.
2. Un server malevolo inghiotte quel pagamento reale: non lo inoltra mai alla rete bitcoin e smette di segnalarlo al wallet.
3. Il server passa al wallet un’altra transazione, che spende gli stessi coin ma paga l’attaccante. Questa transazione falsa non è valida, perché l’attaccante non può produrre le firme dell’utente.
4. Electrum prima della 4.8.3 non controllava mai le firme delle transazioni non confermate. Mostrava il pagamento falso nella cronologia come una normale transazione in sospeso e nascondeva quello vero.
5. L’utente vede quello che sembra un pagamento fermo in coda e chiede al wallet di aumentare la commissione.
6. Per costruire l’aumento, il wallet parte dalla transazione falsa e ne firma una nuova versione con una commissione più alta. Quella versione porta firme autentiche, paga l’attaccante ed è valida sulla rete.

Tutto poggia sull’ultimo passaggio. La transazione falsa da sola non sposta nulla, perché qualsiasi nodo bitcoin la rifiuterebbe. È la firma dell’utente sull’aumento della commissione a trasformare la bozza dell’attaccante in un pagamento che la rete accetta.

Dal lato dell’utente, niente sembra rotto. Il wallet è il vero Electrum, scaricato dal vero sito. La cronologia mostra un solo pagamento in uscita, più o meno dell’importo previsto, ancora in sospeso. Premere il pulsante della commissione è la correzione di routine in una situazione del genere.

L’advisory pubblica gli appunti del primo utente che ha segnalato l’incidente, e mostrano quanto fosse credibile lo scambio. Il wallet era un multisig 2-di-3 protetto da due hardware wallet Trezor, e spendeva 31 input verso un unico output. L’utente ha controllato l’output su entrambi i Trezor e ha trasmesso. La cronologia ha poi mostrato l’importo intero, non confermato, diretto a un indirizzo sconosciuto. Il falso riutilizzava gli stessi input e gli stessi dati di firma del pagamento reale, ma nessuna delle sue 62 firme corrispondeva. Pagava quasi tutto all’indirizzo simile, rimandava una piccola somma a uno degli indirizzi del wallet e lasciava una commissione vicina a zero. Il pagamento reale non è mai arrivato nella mempool, e questo utente non ha aumentato la commissione.

Commissione zero e un indirizzo con il finale giusto

Le transazioni false erano costruite per essere ritoccate. Nella seconda segnalazione, quella con una perdita, il server ha costruito il falso con commissione zero, «presumibilmente nella speranza che l’utente ne aumentasse la commissione», scrive l’advisory. Un pagamento senza commissione non si conferma, e questo dà a chi guarda la cronologia un buon motivo per intervenire.

Erano anche costruite per reggere a un’occhiata veloce. Secondo l’advisory, entrambi gli utenti hanno detto che l’indirizzo dell’attaccante era stato «macinato», cioè generato per tentativi, finché gli ultimi quattro caratteri coincidevano con quelli dell’indirizzo che intendevano pagare. Nel primo caso finivano entrambi con GyQ3. Chi controlla solo il finale vede una corrispondenza. La nostra guida ai formati degli indirizzi crypto e agli errori da evitare spiega perché conta tutta la stringa.

Dalla prima segnalazione privata dell’11 ottobre alla correzione del 24 ottobre

Due persone hanno segnalato il problema in privato a ottobre, a una settimana di distanza, e la seconda aveva già perso denaro, risulta dall’advisory.

Entrambe le segnalazioni erano private, e l’advisory è l’unica traccia pubblica. La segnalazione del 18 ottobre è la più antica perdita documentata. L’advisory non dice quando i server ostili siano entrati in azione, quanti fossero, né se i due utenti vi si fossero collegati attraverso l’elenco pubblico dei server di Electrum.

Cosa cambia con la 4.8.3: le firme si controllano prima di mostrare un pagamento in sospeso

La correzione si trova nel commit 90fe308, la fusione di un ramo chiamato verify_sigs, scritto da SomberNight. Tocca sette file, con 446 righe aggiunte e 13 rimosse.

Per le transazioni ancora nella mempool, Electrum ora verifica le firme ECDSA di ogni input che appartiene al wallet prima di aggiungere la transazione alla cronologia. Il controllo gestisce i wallet multisig, dove l’ordine delle firme conta, sia i vecchi scriptSig sia i dati witness SegWit. Una transazione che non lo supera genera un errore InvalidTxSignature e viene rimossa.

Il risultato è circoscritto, ma chiude la falla. Un server ostile può ancora nascondere un pagamento. Non può più inventarne uno che spende i coin dell’utente, perché il wallet si accorgerà che le firme mancano o sono sbagliate, e quindi non resta alcun modello falso da far firmare con un aumento della commissione.

Lo scritto di SomberNight è esplicito su ciò che il controllo non copre. Vengono verificati solo gli input pagati da indirizzi del wallet stesso, quindi i pagamenti in entrata non sono validati così. Coprirli significherebbe controllare una per una le transazioni madri non confermate fino a risalire a una minata, e il client non ha un interprete di script completo per farlo, spiega l’advisory. Nel codice, il plugin watchtower, che non custodisce chiavi, salta la verifica. Un pagamento in arrivo sul wallet resta, finché non si conferma, soltanto ciò che il server riferisce.

Ogni versione di Electrum del 2026 è etichettata come aggiornamento di sicurezza

Le note di rilascio indicano la 4.8.3 come aggiornamento di sicurezza, con correzioni per segnalazioni di quattro persone, tra cui i due utenti del caso dell’aumento della commissione. Aggiunge anche mempool.space come fornitore dei tassi di cambio, include la chiave radice DNSSEC nota come KSK-2024, introduce un comando dscancel per annullare un pagamento spendendolo due volte e aggiunge controlli sugli HTLC Lightning in entrata. Una modifica risale al 2018: le interfacce grafiche ora disattivano per impostazione predefinita la resa del testo formattato. Non è una correzione isolata. Le tre versioni 4.8 precedenti portano la stessa etichetta, così come la 4.7.0, la 4.7.1 e la 4.7.2, pubblicate tra il 22 gennaio e il 1° aprile.

Chi ha installato la 4.8.0 a luglio e si è fermato lì è indietro di tre rilasci di sicurezza.

Electrum wallet è sicuro da usare adesso?

Con la 4.8.3, la strada del pagamento falso descritta nell’advisory è chiusa per i pagamenti inviati dall’utente. Le versioni precedenti restano esposte ogni volta che parlano con un server che l’utente non controlla. I passi pratici vengono dall’advisory e dalla pagina di download di Electrum:

• Aggiorna a Electrum 4.8.3, scaricandolo solo da electrum.org. La pagina di download dice di non usare altre fonti, fornisce le firme e afferma che i binari sono riproducibili e firmati da più builder. Controlla la firma GPG prima di installare.
• Ignora chiunque offra aiuto con un messaggio privato. La stessa pagina dice che Electrum non offre assistenza privata agli utenti e che chi lo fa è con ogni probabilità un impostore.
• Finché l’aggiornamento non è fatto, leggi per intero l’indirizzo di destinazione e l’importo prima di firmare qualsiasi transazione, compresi un aumento della commissione o un annullamento. Gli ultimi quattro caratteri non bastano: è proprio ciò che gli attaccanti hanno fatto coincidere.
• Diffida di un pagamento in sospeso che mostra commissione zero, o che sembra invitare a un aumento della commissione. Confronta il suo indirizzo con quello che volevi pagare prima di toccarlo.
• Collega Electrum a un tuo server o a uno di cui ti fidi. L’advisory dice che questi client non sono esposti.

Un hardware wallet non elimina la necessità di guardare. L’aumento della commissione del pagamento falso deve comunque essere firmato sul dispositivo, che mostra la destinazione; il caso del primo utente dimostra che l’indirizzo simile avrebbe lo stesso finale di quello vero. Con un wallet sul proprio computer, questi controlli toccano a te, il consueto compromesso dell’autocustodia.

Chi non era esposto: i wallet collegati a server fidati

L’advisory indica un solo gruppo fuori portata: i wallet collegati a server di cui i proprietari si fidano, come un server gestito da loro stessi. L’attacco richiede un server ostile all’altro capo della connessione.

Cosa non dice l’advisory

Questa è una storia di sicurezza, non ancora una storia di perdite. I fatti noti si fermano a una vittima confermata, un nome utente GitHub e una somma non precisata. Nessun totale è stato pubblicato dall’advisory né da Bitcoin.com News, The Cryptonomist o TokenPost.

Non sono stati resi pubblici nemmeno un indirizzo dell’attaccante, un indirizzo della vittima, un ID di transazione o il nome di un server. Senza questi dati, nessuno al di fuori del caso può seguire i coin rubati su un block explorer, e qualsiasi cifra sulla perdita sarebbe una stima a caso. Le domande aperte sono l’importo sottratto, il numero delle vittime, l’identità e il numero dei server ostili, se gli utenti abbiano usato server pubblici e la data di inizio degli attacchi.

Server ostili di Electrum, 2018-2020: i furti con falso aggiornamento

Server ostili avevano già preso di mira gli utenti di Electrum, con un’arma diversa. Dalla fine di dicembre 2018, gli attaccanti hanno gestito molti server malevoli i cui messaggi di errore, mostrati come testo formattato dalle versioni di Electrum precedenti alla 3.3.3, invitavano a installare un aggiornamento urgente. Il link portava a false pagine GitHub e a un trojan al posto del wallet.

Decrypt ha ricordato che 202 BTC, circa 2,3 milioni di dollari all’epoca, risultavano rubati nei primi attacchi di dicembre 2018. Al 16 aprile 2019, Malwarebytes Labs contava più di 771 BTC sottratti dalla campagna, circa 4 milioni di dollari di allora, e ha chiamato le varianti del malware OSX.ElectrumStealer ed Electrum.Stealer.

Tra marzo e aprile 2019, gli sviluppatori di Electrum hanno sfruttato una falla di denial of service dei vecchi client per allontanare dai server pubblici le versioni precedenti alla 3.3, in modo che non potessero ricevere i messaggi falsi. Gli attaccanti hanno risposto con una botnet che inondava di traffico i server legittimi per spingere i vecchi client verso quelli ostili. The Hacker News ha riferito il 30 aprile 2019 che la botnet, chiamata ElectrumDoSMiner, girava su più di 152.000 macchine infette secondo Malwarebytes, che i furti avevano raggiunto 4,6 milioni di dollari e che agli utenti veniva chiesto di passare alla 3.3.4.

La campagna è tornata nel 2020. A fine agosto, un utente ha dichiarato su GitHub di aver perso 1.400 BTC; un altro ne ha dichiarati 36,5 il giorno dopo. ZDNet ha poi riferito di oltre 25 milioni di dollari rubati, e circa 1.980 BTC, intorno a 22,9 milioni di dollari, si trovavano in wallet collegati agli attaccanti, secondo Decrypt del 12 ottobre 2020. Lo sviluppatore di Electrum Thomas Voegtlin ha detto alla testata: «C’è un’indagine di polizia in corso in Germania e nel Regno Unito».

Gli importi in dollari sono quelli riportati all’epoca, non convertiti al prezzo attuale di bitcoin.

Stesso server ostile, un trucco diverso

I due episodi condividono il punto di partenza: un server che mente al wallet. Tra il 2018 e il 2020 la bugia era un messaggio, e per il furto serviva che la vittima sostituisse Electrum con un malware. Nel 2026 la bugia è una transazione, e il wallet autentico firma da solo il furto. Non c’è alcun file da scaricare, quindi non c’è niente che un antivirus possa intercettare. L’unica difesa su una versione vecchia è la lettura dell’indirizzo da parte dell’utente prima di firmare.

Come spiega la nostra guida su dove avvengono davvero gli attacchi crypto, di rado il punto debole è la catena in sé; lo sono i wallet e le persone che li usano. Nella stessa settimana, Bitcoin Core ha cambiato il modo in cui rende noti i bug, abbandonando l’embargo di un anno per le falle che un’IA può trovare con un solo prompt.

Al 25 ottobre, l’advisory non riporta né nomi di server né ID di transazione. Se gli sviluppatori o i due utenti li pubblicheranno, l’entità del furto potrà finalmente essere misurata sulla blockchain.