Bitcoin.com News
Offerto da

Un bug nel registro XRP da dieci anni poteva creare XRP dal nulla

L'XRP Ledger ha risolto in sordina una vulnerabilità del motore di pagamento risalente al 2015 che avrebbe potuto consentire a un malintenzionato di creare XRP spendibili oltre l'offerta fissa della rete con una riserva di appena poche centinaia di XRP.

SCRITTO DA
CONDIVIDI
Un bug nel registro XRP da dieci anni poteva creare XRP dal nulla

Punti chiave

  • Cayden Liao e Veria AI hanno inizialmente segnalato il bug di overflow dell’XRPL tramite il programma di bug bounty il 22 settembre 2026.
  • RippleX ha classificato la vulnerabilità come critica e oltre l’80% dei validatori UNL predefiniti ha applicato la correzione xrpld 3.4.1 entro il 25 settembre.
  • La verifica dell’XRPL del 9 ottobre non ha rilevato alcun exploit, poiché l’aggiornamento fixBatchV1_2 è stato implementato lo stesso giorno.

Cosa non funzionava effettivamente?

Il problema risiedeva nel codice che gestisce i pagamenti all’interno dell’exchange decentralizzato (DEX) integrato nell’XRP Ledger. Secondo il rapporto ufficiale sulla divulgazione della vulnerabilità pubblicato ieri, quando un singolo pagamento consumava molte offerte, il motore sommava gli importi utilizzando un’aritmetica a 64 bit non controllata.

Portando quella somma a un valore sufficientemente alto, si verificava un “wrap-around”, ovvero ciò che accade in caso di overflow di un numero intero. Un numero gigantesco si trasformava quindi in uno molto piccolo e i venditori dall’altra parte della transazione venivano pagati per intero, mentre all’acquirente veniva addebitato solo il minuscolo totale risultante dal wrap-around. La differenza era costituita da XRP che non era mai esistito prima.

Il registro esegue effettivamente un controllo di sicurezza, noto come «invariante», che dovrebbe confermare che non venga mai creato alcun XRP. Tale controllo utilizzava la stessa matematica non verificata, quindi non era in grado di rilevare proprio l’errore che era stato progettato per individuare. Il rapporto fa risalire il difetto all’attuale motore di pagamento, scritto nel 2015.

Quanto sarebbe costato un attacco?

Il rapporto afferma che il costo consisteva in poche centinaia di XRP bloccati come riserve, che vengono restituiti una volta rimossi gli oggetti, oltre alle normali commissioni di transazione. Un aggressore avrebbe dovuto inserire centinaia di offerte con prezzi deliberatamente errati e poi instradare un pagamento attraverso di esse.

Il guadagno potenziale era la parte preoccupante: RippleX ha definito il bug critico perché in una singola transazione convalidata si sarebbero potuti creare XRP spendibili oltre il limite dell’offerta totale. L’intero modello di XRP si basa su un limite massimo (hard cap) di 100 miliardi di token, quindi una coniazione silenziosa avrebbe minato la promessa fondamentale dell’asset. Ecco perché post come quello di Whale Insider lo hanno descritto come un bug che avrebbe potuto generare “miliardi” di XRP.

Chi l’ha individuato e in quanto tempo è stato risolto?

La cronologia degli eventi è stata piuttosto breve e si è svolta come segue:

  • 22 settembre: Cayden Liao e Veria AI hanno segnalato la scoperta tramite il programma XRPL Bug Bounty, classificandola come “Major”.
  • 23 settembre: RippleX ha riprodotto il bug, ne ha aumentato il livello a «critico» e la correzione è stata integrata.
  • 25 settembre: è stata rilasciata la versione Xrpld 3.4.1, che quel giorno era già in esecuzione su oltre l’80% dei validatori predefiniti dell’Unique Node List (UNL).
  • 9 ottobre: divulgazione pubblica.

La patch non è stata sottoposta alla consueta votazione di modifica, ma è stata invece distribuita come modifica diretta del codice nella versione 3.4.1 ed è entrata in vigore man mano che ogni server veniva aggiornato. Il codice sorgente è stato pubblicato solo dopo l’implementazione, una mossa standard per evitare di fornire agli aggressori una mappa. Da allora, l’account XRPL Operations ha reso la versione 3.4.1 quella minima richiesta, aggiungendo:

Non abbiamo trovato alcuna prova che questo problema sia stato sfruttato su alcuna rete pubblica.

Nella stessa versione è stato risolto un secondo bug di gravità inferiore. Riguardava il modo in cui vengono raggruppate le transazioni in batch, e la sua correzione è contenuta nell’emendamento fixBatchV1_2, entrato in vigore sulla Mainnet il 9 ottobre insieme a BatchV1_1. Il rapporto afferma che non si è verificata alcuna perdita di fondi nemmeno in questo caso.

La notizia è arrivata in una settimana difficile per la sicurezza delle criptovalute, poiché le perdite relative ai dispositivi Ledger, come riportato da Bitcoin.com News, hanno raggiunto una cifra stimata di 93,4 milioni di dollari. Infine, Evernorth, sostenuta da Ripple, si appresta a debuttare lunedì sul Nasdaq con il simbolo XRPN, con circa 473 milioni di XRP nei propri libri contabili. XRP sta inoltre espandendosi nel settore della finanza decentralizzata (DeFi), con Firelight che ha recentemente attivato la protezione del vault sulla rete.

Un tribunale malese ha concesso a Ripple un diritto di pegno sulla quota del 60% detenuta da Seamless in Tranglo, al fine di recuperare 24 milioni di dollari relativi a fatture non pagate in XRP legate al suo servizio ODL.

Leggi ora: Ripple: causa per debito XRP da 24 mln, a rischio quota Tranglo da 400 mln

Questo articolo è stato tradotto dall'inglese tramite IA. La versione originale in inglese è la fonte autorevole; le traduzioni automatiche possono contenere imprecisioni, in particolare nella terminologia legale e normativa.