Electrum, wallet Bitcoin per desktop e mobile, ha rilasciato la versione 4.8.3 (taggata il 23 ottobre 2026, con binari e divulgazione pubblica il 24) per correggere una falla di gravità alta: un server malevolo può sostituire una transazione appena inviata con una falsa. Secondo l’avviso di sicurezza GHSA-6jp4-8v48-cc5v, alcuni server sfruttano già il difetto “in the wild” (cioè in attacchi reali) e un utente ha perso fondi. Chi usa Electrum con server di terzi dovrebbe aggiornare.
I dettagli provengono dall’avviso GHSA-6jp4-8v48-cc5v e dalle note di rilascio della 4.8.3; la notizia è stata ripresa anche da The Defiant.
Electrum 4.8.3: cosa succede con il server malevolo
Il meccanismo, descritto dagli sviluppatori nell’avviso di sicurezza degli sviluppatori, ha quattro passaggi. Quando il client trasmette una nuova transazione (tx1), un server malevolo può trattenerla e aggiornare la cronologia del wallet con una transazione in conflitto (tx2), che sostituisce le uscite con l’indirizzo dell’attaccante. Le firme di tx2 non sono valide, ma il client non le controlla, perché è un client leggero. Il wallet mostra tx2 come transazione non confermata e tx1 sparisce. Se l’utente aumenta a mano la commissione di tx2 con la funzione RBF (replace-by-fee, la sostituzione con commissione più alta), il wallet la firma davvero e il denaro va all’attaccante.
Gli sviluppatori precisano che il software si fida del server principale per le transazioni non confermate, come scritto nella documentazione ufficiale di Electrum: le transazioni confermate sono verificate con SPV (verifica semplificata dei pagamenti), mentre per quelle non confermate il server è considerato affidabile. In sintesi, Electrum non si fida davvero dei server, ma su quel punto sì. La novità, scrivono, è che qualcuno ha trovato un modo pratico per sfruttare questo limite.
I due casi segnalati agli sviluppatori
Il avviso di sicurezza degli sviluppatori riporta due segnalazioni. Il primo utente, dannydeezy, ha scritto l’11 ottobre dopo aver notato che nella cronologia compariva una transazione diversa da quella inviata. Il suo wallet era un multisig 2 di 3 legacy P2SH con due Trezor e 31 input: l’utente aveva controllato le uscite su entrambi i dispositivi e poi premuto “Broadcast”. La cronologia ha mostrato l’intero importo come non confermato verso un indirizzo sconosciuto, poi la voce è passata a “Local”. La transazione reale, secondo il report, non è mai arrivata in mempool ed è ancora valida e non trasmessa.
Il secondo utente, Raju-K12, ha segnalato il 18 ottobre di aver perso denaro dopo aver aumentato la commissione di tx2. Nell’avviso non è indicato l’importo. Dalla ricostruzione degli sviluppatori il server aveva creato una tx2 a commissione zero, probabilmente sperando proprio in quel rilancio. In entrambi i casi l’indirizzo dell’attaccante era stato “macinato” (generato per tentativi) in modo da coincidere con gli ultimi quattro caratteri di quello legittimo: nel report del primo utente entrambi finiscono con GyQ3.
Nel caso del multisig, secondo il report, la transazione falsa aveva gli stessi input, versione e locktime dell’originale, con scriptSig identici byte per byte. Le 62 firme verificano contro la transazione vera e nessuna contro quella falsa: un dato coerente con la scelta degli sviluppatori di aggiungere la verifica delle firme per gli input del wallet.
| Elemento | Dato | Fonte |
|---|---|---|
| Versioni vulnerabili | precedenti alla 4.8.3 | Avviso GitHub |
| Gravità | alta (sev-high) | Note di rilascio |
| Segnalazione utente 1 | 11 ottobre 2026 (transazione reale non propagata, ancora valida) | Avviso GitHub |
| Segnalazione utente 2 | 18 ottobre 2026 (fondi persi) | Avviso GitHub |
| Tag della correzione | 23 ottobre 2026 | Avviso GitHub |
| Binari e divulgazione pubblica | 24 ottobre 2026 | Avviso GitHub |
Come funziona la correzione e chi non è a rischio
La correzione è nel commit 90fe308, incluso nella 4.8.3. Secondo l’avviso, il client ora verifica le firme degli input che appartengono al wallet (is_mine) per le transazioni in mempool, prima di aggiungerle alla cronologia locale. Le note di rilascio di Electrum 4.8.3 classificano il problema come “sev-high” e indicano come titolo: “Malicious server can replace a just-broadcast tx and try to trick user into RBF-ing it”.
Gli sviluppatori dichiarano che i client collegati a server di cui si fidano, per esempio uno gestito in proprio, non sono interessati. Ammettono anche un limite residuo: anche dopo la patch vengono validati solo gli input del wallet, quindi le transazioni in entrata non sono controllate, perché il client non ha un motore di consenso completo né un interprete di script e dovrebbe comunque validare ricorsivamente le transazioni genitrici non confermate fino a quelle minate.
La timeline dell’avviso indica la correzione taggata il 23 ottobre e binari e divulgazione pubblica il 24 ottobre. Per chi non può aggiornare subito, il workaround indicato è controllare indirizzi e importi di destinazione prima di firmare qualsiasi transazione, anche per un semplice rilancio di commissione. Il tema richiama altri incidenti di sicurezza dei wallet già trattati da BitcoinLive24, come Ledger e Trezor, impianti nei wallet e 60 Bitcoin persi nei Ledger manomessi, e il lavoro sulle falle descritto in la nuova policy di sicurezza di Bitcoin Core.
Cosa aspettarsi
Gli sviluppatori invitano a installare la 4.8.3 e ad aggiornare regolarmente. Resta da vedere quanti server malevoli siano attivi: l’avviso parla soltanto di “alcuni server” senza numeri. Per chi custodisce Bitcoin con un wallet leggero, l’episodio ricorda che la sicurezza dipende anche da chi gestisce il server a cui ci si collega.
Domande frequenti
Chi è colpito dalla falla di Electrum?
Le versioni di Electrum precedenti alla 4.8.3 collegate a un server non fidato, secondo l’avviso di sicurezza degli sviluppatori. I client che si connettono a server propri o fidati non sono interessati.
Come proteggersi?
Aggiornare alla 4.8.3 e controllare sempre indirizzi e importi prima di firmare, anche nei rilanci di commissione, come indicato dagli sviluppatori nell’avviso di sicurezza degli sviluppatori.
Le chiavi private sono state rubate?
L’avviso non riporta furti di chiavi: descrive un inganno sulla firma di una transazione. La documentazione ufficiale di Electrum precisa che il client non invia mai le chiavi private ai server.
Informazione di cronaca tecnica, non consulenza finanziaria. Scarica l’app BitcoinLive24 per ricevere avvisi sulle notizie che contano.
