XRP Ledger, bug decennale poteva creare XRP dal nulla e aggirare il supply cap

🛡️ Executive Summary

• Un integer overflow presente nel payment engine di XRP Ledger dal 2015 permetteva di creare XRP spendibili senza disporre del corrispondente saldo.
• Anche l’invariante progettata per impedire la creazione di nuovi XRP falliva, perché utilizzava la stessa aritmetica a 64 bit vulnerabile all’overflow.
• XRPL ha distribuito xrpld 3.4.1 come patch d’emergenza senza attendere il normale processo di amendment; non risultano prove di sfruttamento sulle reti pubbliche.

XRP Ledger ha corretto una vulnerabilità critica rimasta nel proprio payment engine per circa undici anni e capace, in condizioni costruite deliberatamente, di creare nuovi XRP senza che l’attaccante disponesse del valore corrispondente. Il problema non riguarda una chiave privata rubata, un wallet compromesso o uno smart contract difettoso: nasce dall’aritmetica utilizzata dal protocollo per sommare gli importi di molte offerte durante un singolo pagamento. L’aspetto più grave è che anche il controllo progettato per impedire la creazione di XRP utilizzava una logica vulnerabile allo stesso overflow. XRPL non ha trovato prove di sfruttamento sulle reti pubbliche, ma ha giudicato il rischio abbastanza elevato da modificare eccezionalmente il processo normale di aggiornamento del protocollo.

L’overflow era nel payment engine dal 2015 e poteva creare XRP spendibili

Il Vulnerability Disclosure Report pubblicato da XRP Ledger ricostruisce una falla introdotta con l’attuale payment engine nel 2015 e scoperta soltanto il 22 settembre 2026 attraverso il bug bounty del progetto. Il problema emerge quando un pagamento attraversa un order book composto da molte offerte: il motore calcola quanto il compratore deve complessivamente pagare sommando gli importi attraverso normali interi a 64 bit. Ogni singola offerta può essere perfettamente valida, ma la somma di alcune centinaia di valori estremamente elevati può superare il massimo rappresentabile e tornare a un numero molto piccolo. Il sistema continua però ad accreditare ai proprietari delle offerte l’intero valore previsto, mentre al compratore viene addebitato soltanto il totale ormai corrotto dall’overflow. La differenza diventa XRP nuovo, validato dal ledger e successivamente spendibile come qualsiasi altro saldo. XRPL ha riprodotto internamente il proof of concept e ha elevato la vulnerabilità da Major a Critical.

Leggi anche: XRP Ledger supera un milione di pagamenti AI mentre Bitcoin prepara il dopo-quantum

L’attacco richiedeva centinaia di offerte ma pochissimo capitale iniziale

L’exploit non poteva verificarsi durante un normale pagamento. L’attaccante avrebbe dovuto creare alcune centinaia di account e collocare offerte artificiali nelle quali quantità minime di un token venivano vendute in cambio di importi enormi di XRP. Un ulteriore account avrebbe poi effettuato un pagamento costruito appositamente per attraversare tutte quelle offerte nella stessa operazione. Il punto più pericoloso è che non serviva possedere in partenza la quantità di XRP destinata a essere creata: i valori giganteschi erano quelli richiesti dalle offerte, mentre il saldo del compratore poteva rimanere minimo perché il totale finale veniva ridotto dall’overflow. XRPL stima come costo reale poche centinaia di XRP necessarie per riserve di account e offerte, in larga parte recuperabili dopo la rimozione degli oggetti, oltre alle commissioni ordinarie. Una vulnerabilità di questo tipo diventa particolarmente delicata mentre XRP Ledger viene utilizzato sempre più come infrastruttura per pagamenti automatizzati e agenti AI, perché il valore della rete dipende direttamente dalla certezza che il ledger non possa creare unilateralmente nuovi asset oltre le regole previste.

Anche il controllo “no XRP created” utilizzava la stessa aritmetica sbagliata

Il caso è tecnicamente più grave perché XRP Ledger disponeva già di un’invariante progettata precisamente per verificare che una transazione non generasse nuovi XRP. Quel controllo, però, sommava le variazioni dei saldi utilizzando anch’esso un contatore a 64 bit. Quando i valori superavano il limite, il controllo subiva lo stesso overflow del payment engine e concludeva erroneamente che la differenza complessiva corrispondesse soltanto alla normale commissione di transazione. Nemmeno il controllo sul saldo massimo del singolo account era sufficiente, perché l’attaccante poteva distribuire gli XRP appena creati tra centinaia di account mantenendo ciascun saldo sotto la soglia prevista. È un classico fallimento di defense in depth: due barriere apparentemente indipendenti condividevano in realtà la stessa assunzione matematica e potevano quindi fallire contemporaneamente. La distinzione è importante in una blockchain che sta entrando nella tokenizzazione di fondi e infrastrutture finanziarie istituzionali, dove un’invariante economica non è un controllo accessorio ma parte della fiducia attribuita al protocollo.

XRPL ha saltato il normale processo di amendment per chiudere la falla subito

La correzione è arrivata con xrpld 3.4.1, pubblicato il 25 settembre. Il payment engine controlla ora esplicitamente l’overflow durante la somma degli importi delle offerte e interrompe il percorso prima che possa essere creato valore inesistente. Anche l’invariante è stata modificata utilizzando un contatore più ampio, in modo da poter individuare errori analoghi provenienti eventualmente da altre parti del protocollo. La decisione più significativa riguarda però il deployment: XRPL ha scelto di non utilizzare il consueto processo di amendment, nel quale una modifica alle regole transazionali viene pubblicata, votata dai validator e attivata soltanto dopo il supporto superiore all’80% per due settimane. Pubblicare prima il codice avrebbe infatti mostrato esattamente dove si trovava la vulnerabilità lasciando aperta una finestra di sfruttamento. Il fix è quindi entrato in funzione appena ciascun server è stato aggiornato, una scelta che il progetto definisce eccezionale e mai deliberatamente adottata per una modifica di transaction processing da quando esiste il sistema degli amendment. Il 25 settembre oltre l’80% dei validator della default UNL risultava già aggiornato.

Lo stesso aggiornamento chiude anche un rischio di consensus sulle Batch transaction

Il disclosure di xrpld 3.4.1 documenta anche una seconda vulnerabilità, differente dall’overflow ma utile per capire perché la release sia stata considerata emergenziale. Nelle Batch transaction il server non verificava correttamente che ogni transazione interna fosse incapsulata nel campo RawTransaction; versioni differenti di xrpld potevano quindi accettare o rifiutare lo stesso oggetto in modo diverso, creando potenzialmente una divergenza capace di fermare la validazione del ledger su una rete composta da server non omogenei. Il problema non ha interessato transazioni Mainnet perché BatchV1_1 non era ancora stato attivato. In questo caso XRPL ha utilizzato invece il normale meccanismo di governance attraverso l’amendment fixBatchV1_2, diventato operativo il 9 ottobre. La differenza tra le due remediation è istruttiva: per il bug Batch era possibile bloccare l’attivazione della funzionalità prima che diventasse utilizzabile; per l’overflow XRP il codice vulnerabile era già da anni nel percorso di pagamento ordinario.

Continua con:

Crypto diventa infrastruttura: HSBC, Ripple e Robinhood cambiano scala

Stablecoin, banche e azioni 24/7 accelerano la tokenizzazione dei mercati

Per gli utenti italiani il rischio è corretto, ma il precedente resta pesante

Non risultano evidenze che la vulnerabilità sia stata sfruttata su XRP Ledger Mainnet o su altre reti pubbliche e, con xrpld 3.4.1 distribuito e i validator principali aggiornati, il rischio descritto dal disclosure è stato corretto. Il caso resta però rilevante anche per investitori, exchange e operatori europei perché dimostra quanto la sicurezza economica di una blockchain possa dipendere da poche righe di aritmetica inserite dieci anni prima. XRP dispone di un’offerta definita dal protocollo e la possibilità di creare nuove unità senza rispettarne le regole avrebbe colpito direttamente una delle proprietà fondamentali dell’asset. Il problema non era la crittografia delle firme e non richiedeva il controllo dei validator: bastava costruire una transazione capace di portare il motore matematico oltre i propri limiti. La lezione non è che XRP sia oggi inflazionabile, ma che anche una blockchain matura può conservare per anni una vulnerabilità capace di violare la propria regola economica più elementare e, contemporaneamente, ingannare il controllo creato per impedirlo.