Un bug di overflow nell'XRP Ledger avrebbe potuto consentire a una singola transazione di creare più XRP dell'intera offerta esistente. RippleX, il ramo di sviluppo di Ripple, e la XRPL Foundation hanno divulgato e corretto il difetto, probabilmente presente dal 2015, alla fine di settembre 2026. Non ci sono prove che sia mai stato sfruttato.

Un tetto all'offerta che avrebbe potuto essere violato

L'XRP Ledger è la blockchain decentralizzata alla base di XRP. Gestisce pagamenti e trading attraverso un order book integrato, e il motore di pagamento è il componente che abbinai i pagamenti alle offerte ivi inserite. L'offerta totale al lancio era di 100 miliardi di XRP. Non esiste mining né inflazione; solo le commissioni di transazione bruciate riducono leggermente l'offerta. Questo tetto fisso si basa su un invariante a livello di ledger — la regola che nessuna transazione possa creare XRP — e questa è proprio la garanzia minata dal bug di overflow.

La versione 3.4.1 del software server xrpld è stata rilasciata il 25 settembre, e il rapporto di divulgazione è seguito 14 giorni dopo. Prima, oltre l'80% dei validatori della Default Unique Node List (UNL) si era già aggiornato. Il bug riguardava xrpld 3.4.0 e tutte le versioni precedenti. Veria Labs, che ha segnalato il bug, calcola che una singola transazione di exploit avrebbe potuto creare circa 18.000 miliardi di XRP.

Come si sarebbe potuto coniare XRP dal nulla

Il motore di pagamento sommava gli importi di tutte le offerte consumate da un pagamento nell'order book, utilizzando un'addizione di interi a 64 bit senza controllo di overflow. Se la somma diventava abbastanza grande, il valore ricominciava da un numero piccolo. Ogni proprietario di offerta avrebbe ricevuto il pagamento completo, mentre il ledger avrebbe addebitato all'acquirente solo la somma riconnessa. La differenza sarebbe nata come nuovo XRP.

Due salvaguardie avrebbero dovuto prevenirlo. Tuttavia, l'invariante che stabilisce che nessuna transazione possa creare XRP utilizzava la stessa aritmetica soggetta a overflow. Inoltre, il controllo del saldo per account si attiva solo al di sopra dell'offerta totale, ma il nuovo X sarebbe finito in molti account.

Per l'attacco, un malintenzionato avrebbe dovuto creare centinaia di account, ciascuno offrendo una piccolissima frazione di token in cambio di un'enorme quantità di XRP. Un singolo pagamento avrebbe quindi consumato tutte le offerte, e ogni account coinvolto poteva appartenere all'attaccante. I costi si riducevano a qualche centinaio di XRP in riserve recuperabili più le commissioni, quindi l'attaccante non necessitava di un saldo iniziale elevato.

Ciononostante, nessuno avrebbe potuto innescare l'overflow per errore. I pagamenti normali non raggiungono mai la somma richiesta, perché nessun trader reale quoterebbe prezzi simili. Il rapporto precisa inoltre che non ci sono prove di sfruttamento su nessuna rete pubblica. Cayden Liao di Veria Labs afferma che l'exploit concatena due bug che, presi singolarmente, avrebbero avuto gravità bassa, e sospetta che sia questo il motivo per cui nessuno aveva trovato prima il difetto.

Segnalato tramite il bug bounty program

Cayden Liao e Veria AI hanno segnalato la vulnerabilità il 22 settembre tramite il bug bounty program della rete, valutandola inizialmente come "Maggiore". RippleX ha riprodotto l'attacco e ha innalzato la valutazione a "critica", per poi sviluppare la correzione in privato. Un giorno dopo, la fix è arrivata nel ramo di rilascio della versione 3.4.1 ed è stata inclusa nella release candidate 3.4.1-rc1. Da allora, il motore di pagamento verifica la presenza di overflow quando somma gli importi delle offerte; se la somma va in overflow, quella parte del pagamento fallisce.

Solo Veria Labs ha fornito dettagli sulla scoperta vera e propria. L'azienda afferma che un agente AI ha trovato il bug e costruito un exploit funzionante. Al contrario, il rapporto di divulgazione nomina solo Liao e Veria AI come segnalatori. La cifra di circa 18.000 miliardi di XRP deriva dal calcolo di Liao e equivalrebbe a 184 volte l'offerta totale. Veria afferma inoltre di aver ricevuto il bounty massimo di 250.000 USD, sebbene il rapporto non indichi un importo. Programmi come questo sono un meccanismo standard sulle principali reti blockchain per premiare la divulgazione responsabile.

Secondo il rapporto, il bug era probabilmente nel codice fin dallo sviluppo del motore di pagamento nel 2015, ed è rimasto inosservato per circa un decennio. Il caso si inserisce nella più ampia tendenza della ricerca di vulnerabilità assistita dall'AI, che porta alla luce i difetti più rapidamente — una prospettiva condivisa anche dagli sviluppatori di RippleX.

Una correzione senza emendamento

Le modifiche alle regole dell'XRP Ledger passano normalmente attraverso i cosiddetti emendamenti, che richiedono il supporto di oltre l'80% dei validatori fidati per un periodo di due settimane. Questa correzione, tuttavia, ha avuto effetto immediato man mano che ogni singolo server si aggiornava. Il rapporto la definisce la prima modifica deliberata di questo tipo all'elaborazione delle transazioni da quando sono stati introdotti gli emendamenti. Il giorno del rilascio, oltre l'% dei validatori della Default UNL eseguiva già la versione 3.4.1 o successiva.

RippleX ha giustificato la mossa con la finestra temporale: un normale rilascio open source avrebbe mostrato agli attaccanti dove si trovava il bug, settimane prima che la correzione avesse effetto. I membri della XRPL Foundation, RippleX e i validatori XRPL hanno quindi concordato in anticipo che il rischio giustificasse un approccio rapido. A loro avviso, solo i bug più gravi giustificano questo passo, mentre tutte le altre modifiche passano ancora per gli emendamenti.

"L'AI ha cambiato le cose. Non puoi infilare la correzione di un bug critico in un normale processo di rilascio pubblico: verrebbe individuata e sottoposta a reverse engineering immediatamente." — Mayukha Vadari, RippleX

Tuttavia, il team ha pubblicato il codice sorgente della 3.4.1 su GitHub solo circa due settimane dopo i binari. Justin Bons, fondatore di Cyber Capital, ha criticato su X che XRP era rimasto su codice closed-source per due settimane. Una patch silenziosa con divulgazione ritardata è una pratica comune nella sicurezza del software, ma resta controversa in una rete decentralizzata con ambizioni di governance.

Un secondo bug nella funzionalità batch

La versione 3.4.1 ha anche chiuso un secondo bug, nella funzionalità batch (XLS-56), che riguardava xrpld 3.3.0 e 3.4.0. Un batch contiene fino a otto transazioni interne, e secondo la specifica ciascuna deve trovarsi in un campo chiamato RawTransaction. Il server non lo verificava. Di conseguenza, poteva crearsi una voce di ledger permanentemente malformata che avrebbe potuto disturbare indexer, explorer e SDK.

Una variante legata al consenso era più seria. Con versioni software miste, una transazione appositamente costruita avrebbe potuto bloccare la validazione al costo di una sola commissione di transazione, sebbene l'attaccante non avrebbe guadagnato nulla on-chain. Il mainnet non ha subito impatti, poiché BatchV1_1 non era attivo lì.

Il riscontro è emerso per la prima volta al Sherlock Attackathon, inizialmente valutato "basso". Il 18 settembre, Denis Angell della XRPL Foundation ha confermato che una correzione precedente era incompleta. Quattro giorni dopo, Mayukha Vadari ha identificato il rischio per il consenso. Ripple e l'operatore di validatori Vet hanno quindi ritirato i loro voti per BatchV1_1, un emendamento originariamente previsto per l'attivazione il 29 settembre. Il rilascio ha avviato l'attivazione bi-settimanale di fixBatchV1_2, e dal 9 ottobre entrambi gli emendamenti sono attivi sul mainnet.

Processo di revisione rafforzato

RippleX sta pertanto modificando il proprio processo di revisione. D'ora in poi, ogni riscontro di sicurezza contrassegnato come corretto viene sottoposto a un nuovo test sulla release candidate, e il team lo chiude solo quando un test riproduce il bug originale e la candidate supera la verifica. Tra le ulteriori salvaguardie elencate nel rapporto figurano attackathon pubblici e red teaming assistito dall'AI.

Le versionienti sono considerate "amendment-blocked" e non restano più sincronizzate. Gli operatori devono quindi aggiornare i propri server a xrpld 3.4.1 o successiva. Come la rete gestirà il prossimo riscontro critico — tramite questa corsia rapida riservata o un emendamento regolare — mostrerà se l'approccio rimarrà l'eccezione che il rapporto descrive.

Fonte: rapporto di divulgazione della vulnerabilità XRPL tramite Crypto Valley Journal