Una vulnerabilità esistente nell'XRP Ledger da circa un decennio avrebbe potuto consentire ad attaccanti di creare XRP spendibile senza pagarlo, mettendo a rischio la supply fissa di 100 miliardi di token della criptovaluta. Tale limite è fondamentale per l'asset: tutti i 100 miliardi di XRP esistevano già dal lancio del ledger, e le regole del protocollo sono progettate per spostare token tra holder piuttosto che coniarne di nuovi. Il team di sviluppo di Ripple ha distribuito un aggiornamento software di emergenza per eliminare la falla, e i ricercatori non hanno trovato prove che sia stata mai sfruttata sulle reti pubbliche.

Il bug è stato divulgato il 9 ottobre 2026 e, secondo quanto riferito, risale al 2015. I ricercatori Cayden Liao e Veria AI hanno scoperto il problema tramite il bug bounty program dell'XRP Ledger e l'hanno segnalato privatamente il 22 settembre. Programmi di questo tipo sono un pilastro della sicurezza delle criptovalute: offrono ai ricercatori esterni un canale privato per segnalare le falle agli sviluppatori prima che i dettagli diventino pubblici. RippleX, la divisione di sviluppo di Ripple, ha riprodotto l'attacco e confermato che l'XRP eventualmente creato avrebbe potuto essere speso in transazioni successive.

Come funzionava il bug sulla supply di XRP

Nella sua essenza, la falla era un integer overflow nel motore di pagamento dell'XRP Ledger — un difetto software classico in cui un calcolo supera la dimensione fissa del numero che lo memorizza. Il ledger elabora le transazioni tramite il suo exchange integrato, in cui gli utenti piazzano offer per scambiare un asset con un altro.

Un attaccante avrebbe potuto sfruttare questo meccanismo creando centinaia di account e piazzando offer con importi insolitamente elevati di XRP. Un singolo pagamento costruito con cura avrebbe poi potuto consumare tutte quelle offer in una volta.

Nel calcolare il totale di XRP dovuto attraverso le offer consumate, il contatore numerico del motore di pagamento poteva essere spinto oltre il valore massimo rappresentabile, facendo sì che il totale tornasse a un numero molto più piccolo. Di conseguenza, gli account venditori avrebbero ricevuto i pagamenti completi, mentre l'acquirente avrebbe pagato solo l'importo calcolato erroneamente — una discrepanza che avrebbe di fatto creato nuovo XRP.

La salvagia esistente del ledger, pensata per rilevare la creazione non autorizzata di XRP, si basava su calcoli vulnerabili allo stesso overflow e poteva quindi non rilevare i token appena creati. RippleX ha confermato che lanciare l'attacco avrebbe richiesto solo qualche centinaio di XRP per istituire gli account necessari, oltre alle commissioni di transazione.

La correzione di emergenza ha aggirato il consueto processo di voto

Ripple ha rilasciato il 25 settembre la versione 3.4.1 del software server dell'XRP Ledger per affrontare la vulnerabilità. A differenza delle modifiche protocolscript convenzionali, la correzione del motore di pagamento è entrata in vigore man mano che i singoli operatori aggiornavano i propri server. La divulgazione ufficiale è stata pubblicata sul blog dell'XRP Ledger all'indirizzo circa due settimane dopo il rilascio — un intervallo coerente con le prassi di coordinated disclosure, in base alle quali le correzioni vengono distribuite per prime, così che gli operatori possano proteggere i propri sistemi prima che i dettagli dell'attacco diventino pubblici.

La mossa ha segnato una partenza eccezionale dal processo di emendamento standard del ledger, che in genere richiede oltre l'80% di supporto dai validator fidati mantenuto per due settimane — un meccanismo progettato affinché nessuna singola parte possa riscrivere unilateralmente le regole del ledger. RippleX ha spiegato che seguire il processo normale avrebbe potuto esporre pubblicamente la vulnerabilità mentre la rete restava a rischio durante il periodo di voto e attivazione. Secondo la divulgazione ufficiale, oltre l'80% dei validator fidati predefiniti aveva effettuato l'aggiornamento già il giorno del rilascio.

Il report sulla vulnerabilità, pubblicato il 9 ottobre, ha confermato che gli investigatori non hanno trovato prove di sfruttamento sulle reti pubbliche. L'episodio sottolinea il valore della ricerca di sicurezza indipendente e del rapido coordinamento nell'infrastruttura delle criptovalute. Si inserisce inoltre in uno schema familiare del settore: nel 2018 gli sviluppatori di Bitcoin Core hanno corretto in silenzio un bug di consenso che avrebbe potuto consentire a un miner di gonfiare la supply di Bitcoin.

Sebbene Ripple abbia contenuto la minaccia immediata, l'episodio solleva interrogativi più ampi su come le reti decentralizzate debbano bilanciare le misure di sicurezza di emergenza con una governance trasparente. RippleX ha sottolineato che la risposta eccezionale non modifica l'approccio consolidato del ledger ai futuri emendamenti del protocollo.