Gli sviluppatori dell'XRP Ledger hanno rivelato un grave bug di overflow che avrebbe potuto consentire a un attaccante di creare XRP dal nulla, superando il limite rigido di 100 miliardi di token della rete. La vulnerabilità interessava xrpld, il software server principale del ledger, nelle versioni 3.4.0 e precedenti. È stata corretta silenziosamente a settembre e resa pubblica il 9 ottobre 2026. Gli investigatori non hanno trovato prove che sia mai stata sfruttata su una rete pubblica.

Come funzionava il bug

La vulnerabilità risiedeva nel modo in cui xrpld calcolava gli importi dei pagamenti. Quando un singolo pagamento attingeva liquidità da più offerte sul libro ordini decentralizzato, il software utilizzava un intero a 64 bit per tenere il totale corrente degli XRP coinvolti. Se quel totale superava il numero massimo che l'intero poteva contenere, si verificava un wrap-around verso un valore molto inferiore alla realtà. Errori di overflow come questo sono una categoria classica di difetto software—un'aritmetica che supera la dimensione fissa della variabile che memorizza il risultato—e sono tra i primi rischi che i revisori cercano nel codice che movimenta denaro.

Un attaccante avrebbe potuto sfruttare questa lacuna per spendere XRP inesistenti. Poiché i saldi gonfiati erano distribuiti su molti account, i controlli di sicurezza esistenti del ledger non hanno segnalato la discrepanza—consentendo ai registri di apparire bilanciati mentre l'offerta effettiva aumentava silenziosamente.

Il costo per realizzare un simile attacco era sorprendentemente basso. Secondo la divulgazione, lo sfruttamento richiedeva offerte appositamente costruite da centinaia di account, per un costo di poche centinaia di XRP in riserve e commissioni, in gran parte recuper. La quantità di XRP che avrebbe potuto essere generata in una singola transazione potrebbe aver superato l'intera offerta totale del token.

Una correzione silenziosa, poi la divulgazione pubblica

La vulnerabilità è stata segnalata il 22 settembre 2026 dal ricercatore Cayden Liao tramite il programma XRPL Bug Bounty. RippleX, il braccio di sviluppo di Ripple, ha confermato il problema e riprodotto l'attacco su un server autonomo, verificando che gli XRP in eccesso potevano essere spesi in transazioni successive.

Tre giorni dopo la segnalazione, il 25 settembre 2026, è stata rilasciata una versione di emergenza: xrpld 3.4.1. La correzione ha anche saltato il consueto processo di emendamento del ledger, in base al quale le modifiche alle regole della rete normalmente entrano in vigore solo dopo una procedura di voto dei validator. Questa patch è stata invece distribuita immediatamente.

La divulgazione pubblica è seguita il 9 ottobre, circa due settimane dopo il rilascio del software corretto. Il team ha riferito nessuna perdita di fondi, nessuna chiave compromessa e nessun problema di consenso legato al bug. Questa sequenza segue la divulgazione coordinata delle vulnerabilità, la pratica standard nella sicurezza del software di rilasciare le correzioni prima di pubblicare i dettagli, offrendo agli operatori una finestra per aggiornarsi prima che informazioni che potrebbero guidare un attacco diventino pubbliche. Il programma XRPL Bug Bounty che ha prodotto la segnalazione fa parte dello stesso apparato—uno che paga ricercatori indipendenti per segnalare i difetti privatamente anziché sfruttarli o divulgarli per conto proprio.

Un decennio nascosto

Si ritiene che la vulnerabilità esista dalla prima realizzazione del motore di pagamento, intorno al 2015—il che significa che il codice ha elaborato pagamenti per anni con un overflow latente al suo interno. I bug in grado di gonfi l'asset nativo di una blockchain sono rari, ma non senza precedenti: nel 2018, gli sviluppatori di Bitcoin Core hanno rilasciato una patch di emergenza per un difetto che avrebbe potuto anch'esso consentire a un attaccante di creare bitcoin al di fuori delle regole di emissione della rete.

Cosa significa per i possessori di XRP e per il ledger

Per i possessori di XRP, la conclusione immediata è rassicurante: non ci sono prove che il bug sia mai stato sfruttato, e l'integrità dell'offerta di token appare intatta. L'episodio ricorda inoltre che un limite rigido dell'offerta è in ultima analisi applicato dal codice—ed è affidabile solo quanto quel codice.

La decisione di bypassare il processo di emendamento, tuttavia, merita attenzione. Un percorso noto per la creazione illimitata di XRP non è qualcosa che può attendere un voto di governance, ma le patch di emergenza che saltano le procedure normali ripongono una fiducia significativa nel team di sviluppo principale. In questo caso, la sicurezza della rete dipendeva dal rapido aggiornamento dei validator e degli operatori dei nodi.

Gli operatori di nodi che utilizzano ancora xrpld 3.4.0 o versioni precedenti sono il pubblico più direttamente interessato da questa notizia. La versione corretta, la 3.4.1, è disponibile dal 25 settembre, e chiunque non si sia aggiornato sta utilizzando un software con un difetto che compromette l'offerta, ora pubblicamente documentato.

Fonte: CryptoBriefing