Gli sviluppatori dell'XRP Ledger hanno rilasciato una patch di sicurezza d'emergenza in risposta a un bug critico che avrebbe potuto consentire ad attori malintenzionati di generare XRP aggiuntivi spendibili, nonostante l'offerta fissa di 100 miliardi di token della rete.

La correzione ha bypassato il processo standard di voto dei validatori di due settimane del ledger — una decisione giustificata dagli sviluppatori sostenendo che attendere avrebbe dato a potenziali attaccanti il tempo di sfruttare la debolezza. La patch è stata distribuita con effetto immediato tre giorni dopo la segnalazione del bug tramite il bug bounty program della rete, che premia i ricercatori per la divulgazione responsabile delle vulnerabilità, e gli sviluppatori hanno dichiarato che si è trattato del primo bypass intenzionale del processo di emendamento in più di dieci anni.

La risposta ha da allora suscitato un'ampia discussione su come l'XRP Ledger gestisce le situazioni critiche, nonché sul suo impegno verso la decentralizzazione.

La patch d'emergenza ha bypassato l'approvazione dei validatori

Gli emendamenti al protocollo dell'XRP Ledger richiedono normalmente un consenso superiore all'80% tra i validatori per un periodo di due settimane prima che una modifica entri in vigore — una soglia progettata per garantire che le modifiche alle regole della rete godano di un ampio accordo prima della loro attivazione. Gli sviluppatori hanno osservato che attendere l'esito di un voto sulla patch di sicurezza avrebbe potuto lasciare la falla esposta allo sfruttamento.

Secondo un post sul blog pubblicato domenica dagli sviluppatori dell'XRP Ledger, il normale processo di emendamento avrebbe potuto lasciare la correzione esposta per diverse settimane prima dell'attivazione dell'emendamento, mettendo così in pericolo la rete.

Mentre la patch d'emergenza ha consentito una rapida risoluzione del problema, la decisione di aggirare il processo regolare ha sollevato interrogativi sul ruolo svolto dai team di sviluppo nella risposta alle violazioni della.

La Foundation chiarisce che non è stato creato alcun XRP

La XRP Ledger Foundation è intervenuta per chiarire la confusione sorta dopo la correzione:

La recente correzione di sicurezza dell'XRP Ledger ha sollevato molte domande e alcuni equivoci. Chiarili. 1. È stato creato XRP? No. L'offerta di XRP è stata fissata a 100 miliardi al lancio dell'XRP Ledger, e nessuna transazione è autorizzata a crearne di più. Questo bug era un modo per aggirare… — XRP Ledger Foundation (@XRPLF) 11 ottobre 2026

La patch alimenta il dibattito sulla decentralizzazione

La risposta d'emergenza ha riacceso la controversia sulla decentralizzazione dell'XRP Ledger — una questione che è stata uno dei temi principali nel determinare la posizione giuridica di XRP. Il grado di controllo che un team centrale mantiene su una rete è una considerazione ricorrente quando i regolatori valutano come classificare un asset digitale.

Justin Bons, co-fondatore di Cyber Capital, è stato duramente critico sull'aggiornamento d'emergenza, sostenendo che il discorso sulla decentralizzazione di XRP è ingannevole:

Selling XRP to retail as "decentralized" is straight-up fraud! 🚩 XRP has been running closed-source code for the last two weeks Tomorrow, this code becomes mandatory & anyone who disagrees will get kicked off the chain! A permissioned node list means validators must obey: 🧵… pic.twitter.com/3nIcRiid8S — Justin Bons (@Justin_Bons) 8 ottobre 2026

Nel suo post, Bons ha affermato che la rete ha eseguito codice closed-source per due settimane in vista di un aggiornamento obbligatorio, e che un elenco di nodi autorizzati ha di fatto richiesto ai validatori di conformarsi.

Un ulteriore motivo di preoccupazione è che le distribuzioni binarie sono file eseguibili: in assenza della pronta distribuzione del codice sorgente sottostante, gli sviluppatori indipendenti hanno tempo limitato per analizzare le modifiche apportate.

La XRP Ledger Foundation ha spiegato che la patch d'emergenza è stata "concordata congiuntamente" dalla Foundation, RippleX, dagli sviluppatori e dai validatori a causa della gravità del bug rilevato nel codice. Ha sottolineato che nessuno ha dettato il processo decisionale e che gli operatori restano liberi di utilizzare il software che preferiscono.

L'operatore di validatori XRP Kuwait ha anch'esso sostenuto il processo di patching d'emergenza, affermando che la collaborazione non significa centralizzazione:

Our Statement on xrpld 3.4.1 At XRP Kuwait, our journey has always been about infrastructure and purpose. Our purpose is decentralization. We pursue that purpose through independently operated infrastructure and responsible participation in the XRP Ledger. Following the… pic.twitter.com/Oo7qClwpgi — XRPKuwait (@XRPKuwait) 11 ottobre 2026

La controversia ha di nuovo messo un punto interrogativo sulla trasparenza e la responsabilità durante le patch d'emergenza.

Integer overflow nel motore di pagamento

La vulnerabilità alla base della patch d'emergenza è stata descritta in una divulgazione del team dell'XRP Ledger. Secondo il rapporto sulla vulnerabilità, il problema era un integer overflow nel motore di pagamento persistente dal 2015. Gli integer overflow sono una classe di errori software da lungo tempo nota, in cui un calcolo supera il valore massimo che un sistema può memorizzare e rientra su un numero molto più piccolo; in questo caso, i calcoli oltre il limite massimo fisso producevano risultati minori.

Un attaccante avrebbe potuto sfruttare il bug inviando centinaia di offerte che richiedevano enormi quantità di XRP in cambio. Dopo il calcolo errato, l'attaccante avrebbe ricevuto tali importi mentre l'acquirente avrebbe pagato meno del dovuto — con la possibile cre di XRP aggiuntivi spendibili.

Poiché le regole della rete hanno fissato l'offerta totale di XRP a 100 miliardi di token al lancio, qualsiasi via per produrre XRP aggiuntivi spendibili avrebbe minato una garanzia fondamentale del ledger — la regola dell'offerta fissa che sostiene la scarsità dell'asset.

L'attacco richiedeva offerte appositamente costruite e non poteva avvenire durante il normale svolgimento delle negoziazioni. La patch è stata progettata per impedire che l'errore di calcolo venisse utilizzato per aggirare le regole sull'offerta della rete.

RippleX amplia gli sforzi di sicurezza

RippleX intende rafforzare la sicurezza dell'XRP Ledger attraverso il rilevamento delle vulnerabilità basato sull'IA, test avversari, verifica formale e collaborazione con esperti di sicurezza esterni.

Gli obiettivi di questi sforzi includono l'individuazione di bug nel codice, il test di possibili attacchi e l'identificazione delle vulnerabilità prima che possano essere sfruttate. RippleX ha inquadrato il lavoro come un impegno per migliorare la sicurezza dell'intero sistema di codice, anziché limitarsi a correggere le vulnerabilità rilevate.

Bilanciare sicurezza e trasparenza

La correzione d'emergenza evidenzia la sfida di mantenere la sicurezza della blockchain preservando la trasparenza nei processi decisionali. Sebbene l'implementazione rapida sia essenziale per proteggersi da potenziali attacchi, essa solleva questioni relative ai processi di governance e all'accesso al codice sorgente.

Gli sviluppatori hanno sostenuto che la vulnerabilità rendeva necessario saltare la procedura standard, mentre la Foundation ha affermato che il coordinamento tra le parti coinvolte non ha compromesso l'indipendenza dei validatori.

L'incidente sottolinea la necessità di sviluppare protocolli d'emergenza capaci di conciliare la risposta rapida con l'apertura della rete.

Fonte: Tron Weekly