Un difetto dell’XRP Ledger avrebbe potuto permettere la creazione di XRP spendibili oltre il limite originario di 100 miliardi. La vulnerabilità è stata corretta con xrpld 3.4.1, pubblicato il 25 settembre 2026, e divulgata il 9 ottobre. Nel rapporto ufficiale, gli sviluppatori dichiarano di non aver trovato prove di sfruttamento su reti pubbliche. Il problema riguarda quindi un rischio dimostrato nei test, non un’emissione abusiva accertata sulla rete.
Perché il difetto non emergeva nei pagamenti normali
Secondo il rapporto, le operazioni ordinarie non raggiungevano i valori necessari a provocare l’errore. Una combinazione costruita appositamente poteva invece far superare a una somma la capacità di un contatore a 64 bit: il totale risultava molto più piccolo del dovuto. È il cosiddetto overflow, un traboccamento numerico.
Il caso mostra il limite di un controllo che osserva soltanto ciò che succede normalmente. Un pagamento frequente può funzionare correttamente milioni di volte senza mettere alla prova una condizione estrema. La lunga anzianità del codice non costituisce, da sola, una prova della sua sicurezza.
Due controlli, una debolezza condivisa
Nell’analisi tecnica di Veria Labs, che ha segnalato la falla, il codice di aggregazione risale a novembre 2015 e il controllo contro la creazione di XRP a febbraio 2017. Entrambi utilizzavano interi a 64 bit senza la protezione necessaria. Il motore accreditava importi completi ai destinatari, mentre addebitava al pagatore un totale errato; il controllo finale poteva subire lo stesso overflow e accettare il risultato.
La distribuzione degli accrediti tra molti account aggirava inoltre il limite per singolo saldo. Veria attribuisce al proprio agente di intelligenza artificiale l’individuazione e il collegamento dei difetti, dimostrati su una rete locale. Si tratta del resoconto dei ricercatori, non della prova di un attacco avvenuto sul mercato.
La lezione redazionale è concreta: avere più verifiche non basta se condividono la stessa debolezza. Un esempio intuitivo è un contabile che controlla una fattura usando una seconda calcolatrice con lo stesso limite numerico della prima. La verifica sembra indipendente, ma può ripetere il medesimo errore.
La correzione è precedente alla divulgazione
La segnalazione è del 22 settembre: tre giorni separano quella data dal rilascio, mentre altri quattordici precedono la pubblicazione del rapporto. La patch controlla le somme e amplia il contatore della verifica finale. È entrata in funzione all’aggiornamento dei server, senza la normale procedura di voto e attivazione dei validatori. Gli sviluppatori hanno motivato l’eccezione con il rischio di rendere pubblico un exploit ancora utilizzabile; segnalano anche il rischio temporaneo di disaccordo tra versioni.
Offerta massima e circolazione non sono la stessa cosa
La documentazione di XRP ricorda che i 100 miliardi di unità esistevano alla creazione della rete. Descrive anche token detenuti da Ripple e bloccati in escrow, un vincolo con rilascio regolato. Sbloccare unità già esistenti può cambiare la quantità disponibile sul mercato: non equivale a crearne di nuove.
Per questo il limite originario, l’offerta totale residua e la quantità in circolazione vanno tenuti distinti. Moltiplicare token ipoteticamente creati per una quotazione non misura neppure il ricavo ottenibile dalla loro vendita: liquidità e prezzo cambierebbero sotto pressione. Il fatto rilevante è l’integrità del registro, non una cifra spettacolare di profitto potenziale.
Per chi segue XRP, l’episodio invita a valutare sia le regole economiche sia il software che le applica. L’assenza di prove di sfruttamento non cancella la gravità della falla; la correzione di questa vulnerabilità, a sua volta, non certifica l’assenza di ogni altro difetto.
