Gli sviluppatori dell'XRP Ledger hanno divulgato una vulnerabilità critica che avrebbe potuto consentire a un attaccante di creare XRP spendibili dal nulla, aggirando le tutele progettate per impedire l'aumento dell'offerta della criptovaluta.

La falla si trovava nel payment engine del ledger ed è stata segnalata tramite il programma XRPL Bug Bounty il 22 settembre da Cayden Liao e Veria AI. Gli ingegneri di RippleX hanno riprodotto l'exploit su un server standalone, confermato che l'XRP appena creato poteva essere speso in un pagamento successivo e innalzato la gravità da major a critical. La gestione è avvenuta secondo la prassi standard della divulgazione coordinata: le segnalazioni di bug bounty giungono privatamente ai manutentori e i dettagli tecnici completi vengono pubblicati solo dopo il rilascio della correzione.

Secondo il rapporto di divulgazione pubblicato sul blog ufficiale di XRPL, non ci sono prove che la vulnerabilità sia stata sfruttata su alcuna rete pubblica dell'XRP Ledger. Gli sviluppatori hanno preparato privatamente una correzione e hanno rilasciato xrpld versione 3.4.1 il 25 settembre, due giorni dopo l'ingresso della patch nel ramo di rilascio d'emergenza.

Un integer overflow poteva aggirare i controlli sull'offerta di XRP

La falla era presente nel payment engine dell'XRP Ledger dal 2015 circa e riguardava un'aritmetica a interi a 64 bit non verificata quando un pagamento consumava più offerte dal order book della rete.

Un numero a 64 bit ha un massimo di circa 18,4 quintilioni, e gli overflow in questo tipo di aritmetica a larghezza fissa sono una classe di bug nota nel software di registro: nel 2010, un integer overflow nei controlli di valore di Bitcoin creò temporaneamente circa 184 miliardi di BTC prima che gli sviluppatori applicassero una correzione nel giro di poche ore.

Un attaccante poteva creare centinaia di account e piazzare offerte appositamente costruite che vendevano piccole quantità di un altro token in cambio di importi estremamente elevati di XRP. Un singolo pagamento che consumasse quelle offerte poteva spingere il totale calcolato oltre il valore massimo supportato dall'intero. Invece di rigettare la transazione, il totale sarebbe tornato a un numero piccolo. Ciascun proprietario dell'offerta avrebbe comunque ricevuto l'intero importo di XRP specificato nella propria offerta, mentre all'acquirente sarebbe stato addebitato solo il valore molto più piccolo risultante dal wrap-around.

L'attacco richiedeva solo qualche centinaio di XRP per le riserve di account e offerte, gran parte dei quali recuperabile in seguito, oltre alle ordinarie commissioni di transazione.

Il controllo integrato di XRPL, progettato per garantire che le transazioni non possano creare XRP, non avrebbe fermato l'exploit L'invariante utilizzava lo stesso tipo di aritmetica e poteva andare in overflow allo stesso modo, mentre un limite di saldo per account poteva essere aggirato distribuendo l'XRP appena creato su centinaia di account. La fragilità era rilevante per il funzionamento dell'offerta di XRP: tutti i 100 miliardi di token sono stati creati al lancio del ledger, le commissioni di transazione bruciano XRP anziché crearne di nuovi, e i controlli di invariante sono la garanzia che nessun percorso di pagamento possa aumentare il totale. La falla era limitata a transazioni appositamente costruite e non poteva essere innescata da pagamenti normali o attività di trading.

I validator sono passati alla 3.4.1 nel giro di poche ore

Gli sviluppatori hanno scelto di distribuire immediatamente la correzione dell'overflow di XRP anziché sottoporla al normale processo di emendamento di XRPL, che in genere richiede il supporto di oltre l'80% dei validator per due settimane prima che una modifica al protocollo si attivi. Lasciare la vulnerabilità esposta per tutto quel periodo avrebbe creato una finestra in cui il metodo d'attacco era noto pubblicamente ma ancora utilizzabile.

Oltre l'80% dei validator sulla Unique Node List predefinita era passato alla 3.4.1 il 25 settembre, lo stesso giorno del rilascio della versione d'emergenza. I tre giorni trascorsi dalla segnalazione privata all'adozione da parte della maggioranza dei validator hanno mostrato il percorso di rilascio d'emergenza del ledger operativo dall'inizio alla fine.

La versione 3.4.1 ora rigetta i pagamenti quando il totale delle offerte andrebbe in overflow e utilizza un contatore più ampio per l'invariante sulla creazione di XRP. Anche ulteriori calcoli di saldo sono stati irrobustiti contro simili errori aritmetici.

L'incidente fa seguito a un compromesso della supply-chain di xrpl.js, non correlato, scoperto nel 2025, che aveva interessato rilasci danneggiati di pacchetti JavaScript anziché il protocollo stesso dell'XRP Ledger. Il sistema di emendamenti di XRPL viene utilizzato anche per funzionalità più recenti, come il proposto XRPL Lending Protocol, in cui l'approvazione dei validator determina se il nuovo comportamento delle transazioni diventa attivo.

La falla da overflow non ha alterato l'offerta esistente di XRP. Non è stato individuato alcun XRP non autorizzato, e gli operatori dei server devono ora eseguire xrpld 3.4.1 o versioni successive per rimanere sincronizzati con la rete. Ciò che resta osservabile è operativo: i ritardatari su versioni precedenti che passano alla 3.4.1 o successive, e proposte come l'XRPL Lending Protocol che proseguono lungo il normale percorso di emendamento bypassato da questa correzione.

Fonte: XRP Ledger Patches Decade-Old Flaw That Could Create Spendable XRP — Crypto Adventure