Gli sviluppatori di Litecoin hanno rivelato che una grave falla di validazione nell'implementazione del blocco di estensione Mimblewimble della rete ha permesso a un malintenzionato di creare un pegout gonfiato di 85.034,47285734 LTC nel marzo 2026, prima che una risposta di emergenza coordinata recuperasse i fondi e neutralizzasse lo squilibrio contabile.
L'incidente, descritto in dettaglio in un'analisi post-mortem pubblicata dallo sviluppatore di Litecoin David Burkett il 28 aprile, ha anche preparato il terreno per un secondo evento verificatosi ad aprile, in cui un successivo tentativo di sfruttamento ha innescato una modalità di errore denial-of-service, ha interrotto i nodi di mining aggiornati e ha portato alla riorganizzazione di una catena non valida di 13 blocchi.
Errore critico di convalida MWEB di Litecoin
Secondo l'analisi post-mortem, il problema principale era la mancanza di un controllo di validazione nel percorso di connessione del blocco MWEB di Litecoin. Gli input MWEB dovrebbero fare riferimento agli output MWEB precedenti, trasportando al contempo metadati utilizzati dalla logica di validazione del saldo e della spesa. Tali metadati devono corrispondere all'UTXO MWEB effettivamente speso.
Nei normali percorsi di mempool e di costruzione dei blocchi, tale controllo era presente. Tuttavia, non veniva applicato completamente durante la connessione del blocco. Questa lacuna consentiva a un produttore di blocchi malevolo di includere un input MWEB i cui metadati forniti non corrispondevano al vero UTXO, facendo apparire un input di piccole dimensioni come se fosse in grado di supportare un pegout molto più grande.
"La regola prevista è semplice: quando un input MWEB spende un output precedente, i metadati forniti dall'input devono corrispondere all'UTXO MWEB effettivo identificato dall'ID di output dell'input", si legge nel rapporto post-mortem. "Tale controllo era presente in alcuni percorsi, inclusi i normali percorsi di mempool e di costruzione dei blocchi. Ma non veniva applicato completamente nel percorso di connessione dei blocchi."
L'attacco si è verificato al blocco numero 3.073.882. L'attaccante ha utilizzato un input MWEB con un valore effettivo descritto come sconosciuto, ma "non superiore a 1,2084693 LTC", mentre ha utilizzato dati di impegno falsi per generare un pegout di 85.034,47285734 LTC. I fondi gonfiati sono stati inizialmente inviati a un indirizzo Litecoin trasparente e successivamente suddivisi in tre punti di uscita sulla blockchain trasparente.
Poiché lo sfruttamento richiedeva di aggirare i normali controlli di inoltro delle transazioni e di creazione dei blocchi, l'attaccante doveva estrarre un blocco o controllare un miner disposto a includere dati MWEB non validi.
Coordinamento dei minatori, produzione congelata e recupero
Una volta identificata la vulnerabilità e confermato che era già stata sfruttata, gli sviluppatori si sono coordinati privatamente con i principali pool di mining. L'obiettivo era impedire ulteriori blocchi dello sfruttamento senza allertare immediatamente il responsabile, prima che i risultati gonfiati potessero essere contenuti.
Litecoin Core 0.21.5 e 0.21.5.1 sono state rilasciate come release di emergenza incentrate sui miner. Quest'ultima ha aggiunto un'eccezione storica per il blocco dell'exploit già accettato e ha temporaneamente rifiutato le spese dei tre output trasparenti controllati dagli aggressori.
Successivamente, l'attaccante ha tentato di spendere almeno un output congelato, ma i miner potenziati hanno rifiutato la transazione. Gli sviluppatori hanno quindi contattato l'autore del reato, il quale ha accettato di firmare una transazione di recupero che prevedeva la restituzione dei fondi ad eccezione di una ricompensa di 850 LTC.
"L'attore ha successivamente firmato una transazione di recupero", si legge nel rapporto post-mortem. "Tale transazione ha versato: 84.184,47278630 LTC in totale all'indirizzo di recupero, suddivisi in due uscite. 850,00000000 LTC a un indirizzo controllato dall'attore come ricompensa concordata."
L'analisi post-mortem aggiunge che Charlie acquistò 850 LTC per coprire il divario di taglie. L'intera quantità di 85.034,47285734 LTC fu quindi reimmessa in MWEB all'altezza del blocco 3.078.098 e la conseguente produzione di MWEB fu congelata. Questa operazione era stata progettata per ripristinare l'equilibrio interno dell'offerta di MWEB, garantendo al contempo che la produzione di riequilibrio non potesse essere spesa.
Gli sviluppatori di Litecoin hanno affermato che, in definitiva, nessun fondo degli utenti è andato perso a seguito dell'incidente di marzo. Ciononostante, la risposta ha richiesto un coordinamento di emergenza tra i miner, rilasci graduali e una gestione particolare dei dati storici relativi agli exploit.
Il tentativo di aprile ha innescato una catena non valida di 13 blocchi
Il secondo incidente è iniziato il 25 aprile al blocco numero 3.095.931, quando un altro utente ha tentato di utilizzare lo stesso percorso di exploit originale. I nodi aggiornati hanno rifiutato i dati MWEB non validi, ma il rifiuto ha messo in luce un problema distinto nella gestione dei blocchi mutati.
L'analisi post-mortem spiega che alcuni dati serializzati del corpo MWEB potevano essere modificati senza alterare l'hash canonico del blocco Litecoin. Quando un nodo aggiornato riceveva un blocco MWEB modificato tramite canali peer-to-peer, poteva verificarsi un errore durante l'applicazione del corpo MWEB, classificando l'errore come "BLOCK_MUTATED" e mantenendo i dati serializzati errati per quell'hash del blocco. Ciò poteva interferire con la successiva elaborazione di blocchi validi e con i flussi RPC di mining come submitblock.
"Durante l'incidente di aprile, ciò ha causato il rifiuto del blocco danneggiato da parte dei nodi di mining aggiornati, ma ha anche impedito loro di riprendere le normali operazioni di mining con la rapidità necessaria", si legge nell'analisi post-mortem. "I miner non aggiornati, che non avevano applicato la correzione MWEB, hanno continuato a estendere la catena non valida finché i miner aggiornati non si sono coordinati e l'hanno superata."
La catena non valida ha raggiunto il blocco numero 3.095.943, generando in totale 13 blocchi non validi prima di essere superata dalla catena valida. Gli sviluppatori di Litecoin hanno sottolineato che non si è trattato di un rollback della cronologia valida di Litecoin, bensì di una riorganizzazione di una catena non valida prodotta da miner che non avevano aggiornato il proprio sistema o non avevano applicato completamente le regole di validazione MWEB.
Le perdite causate da terzi rimangono una questione chiave ancora aperta.
Sebbene la vulnerabilità di marzo sia stata risolta internamente, la riorganizzazione di aprile ha interessato alcune infrastrutture esterne. L'analisi post-mortem rivela che NEAR Intents ha elaborato uno scambio di 11.000 LTC con 7,78814476 BTC prima che tali LTC venissero rimossi dalla blockchain valida, causando quella che Litecoin ha definito una "ingente perdita" per NEAR Intents. Anche THORChain è stata colpita: un utente malintenzionato ha scambiato 10 LTC con 0,00719957 BTC prima che la riorganizzazione invalidasse la parte Litecoin della transazione.
Secondo quanto riferito, altri tentativi di scambio sono stati sventati in tempo, ma si continuava a raccogliere gli ID esatti delle transazioni di terze parti e gli importi finali delle perdite.
Il 25 aprile è stata rilasciata la versione 0.21.5.4 di Litecoin Core per risolvere la vulnerabilità DoS relativa ai blocchi mutati, cancellando i dati memorizzati per i blocchi classificati come mutati e consentendo in seguito l'accettazione di dati validi per lo stesso hash del blocco. Utenti, miner, exchange e servizi sono stati invitati ad aggiornare Litecoin Core alla versione 0.21.5.4 o successiva e a verificare che i nodi si sincronizzino correttamente.
Al momento della pubblicazione, LTC era scambiato a 55,95 dollari.
