La XRP Ledger Foundation spiega l'intervento d'emergenza per un bug critico sull'offerta
Punti chiave
- •La XRP Ledger Foundation ha dichiarato che non è stato creato alcun XRP attraverso il difetto e di non aver trovato prove di sfruttamento su una rete pubblica.
- •Lo sfruttamento richiedeva centinaia di operazioni appositamente costruite: un pagamento normale non si avvicinerebbe nemmeno all'attivazione della vulnerabilità.
- •La versione 3.4.1 è stata distribuita direttamente ai validatori della default UNL prima che i binari pubblici fossero disponibili il 25 settembre, segnando la prima modifica diretta e deliberata all'elaborazione delle transazioni da quando il sistema di emendamenti è stato introdotto più di un decennio fa.
- •Esistono circa 99,986 miliardi di XRP rispetto all'offerta fissa di miliardi, e la Foundation afferma che tutti i saldi sono pubblicamente visibili, così che chiunque possa verificare i dati in modo indipendente.
- •Gli operatori di nodo sono invitati a eseguire la versione 3.4.1 di xrpld o successive, mentre ai possessori di XRP non è stato chiesto di spostare fondi o sostituire i wallet.

La XRP Ledger Foundation ha spiegato come sviluppatori e validatori hanno risposto a una vulnerabilità che avrebbe potuto consentire a un aggressore di creare XRP spendibili tramite un pagamento appositamente costruito. La Foundation ha dichiarato che non è stato creato alcun XRP attraverso il difetto e che non ci sono prove che sia stato sfruttato su una rete pubblica.
La dichiarazione dell'11 ottobre si è concentrata sulla risposta rather che ripetere i meccanismi della vulnerabilità. Una spiegazione precedente del bug è disponibile nel report di Coindoo. Il rapporto di divulgazione tecnica della Foundation è disponibile sul sito web di XRP Ledger.
I dati pubblici del ledger supportano l'affermazione sull'offerta
XRP è stato lanciato con un'offerta fissa di 100 miliardi, e le commissioni di transazione vengono distrutte nel tempo. La Foundation ha dichiarato che esistono attualmente circa 99,986 miliardi di XRP.
Il rapporto di divulgazione tecnica ha dichiarato che il team non ha trovato prove che la vulnerabilità sia stata sfruttata su una rete pubblica. L'affermazione può essere verificata rispetto alla storia delle transazioni validate e ai saldi dei conti dell'XRP Ledger, disponibili pubblicamente per una revisione indipendente attraverso esploratori e altri servizi di dati.
"Non dovete fidarvi di noi su questo punto", ha scritto la Foundation. I nuovi XRP apparirebbero nei saldi dei conti, perché non esiste un'area di saldo nascosta sull'XRP Ledger. La Foundation ha dichiarato di monitorare il ledger ininterrottamente e di aver verificato l'offerta throughout la storia della rete, mentre altri membri della comunità hanno effettuato le proprie verifiche.
I registri pubblici non possono rivelare ogni conversazione privata avvenuta prima divulgazione né stabilire l'intenzione dietro un attacco mai inviato alla rete. Possono tuttavia mostrare le transazioni validate, le variazioni di saldo visibili e l'offerta registrata. Queste informazioni forniscono una base per contestare le affermazioni secondo cui grandi quantità di XRP sarebbero state coniate di nascosto e lasciate nascoste sulla rete.
Perché la correzione è stata rilasciata prima della divulgazione tecnica
Secondo il processo di governance standard dell'XRP Ledger, le modifiche alle regole di transazione vengono introdotte tramite emendamenti. I validatori devono mantenere oltre l'80% di supporto per due settimane prima che un emendamento si attivi. Questo processo dà agli operatori il tempo di aggiornarsi e permette alla rete di adottare una modifica nello stesso punto.
La correzione dell'overflow ha seguito una strada diversa perché la vulnerabilità era considerata un rischio attivo. Secondo il rapporto di divulgazione, pubblicare il codice che rivelava il difetto preciso prima che i server più datati fossero protetti avrebbe potuto rendere più facile identificare la via d'attacco. La versione 3.4.1 ha quindi applicato la protezione man mano che i singoli server si aggiornavano, invece di attendere il normale processo di emendamento pubblico.
La Foundation ha riassunto la sua spiegazione in un post su X:
La recente correzione di sicurezza dell'XRP Ledger ha sollevato molte domande e alcuni malintesi. Chiariali.
- È stato creato qualche 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 quella regola, e la 3.4.1 l'ha corretto 2 settimane fa.
Non dovete fidarvi di noi su questo punto. Tutti i dati del ledger sono pubblici, ed esploratori e siti di dati li leggono ogni giorno. I nuovi XRP comparirebbero nei saldi dei conti, alla vista di tutti. Non esiste un posto nascosto per gli XRP sull'XRP Ledger, ogni saldo è pubblico.
Monitoriamo l'XRP Ledger 24/7 e abbiamo verificato l'offerta throughout la storia del ledger. Anche altri membri della comunità l'hanno verificata, e chiunque può fare lo stesso.
Le commissioni di transazione vengono distrutte, quindi l'offerta è deflazionistica. Oggi esistono circa 99,986 miliardi di XRP.
- Come è passato inosservato, e quali sono i prossimi passi?
Nessun pagamento normale sfiora anche solo l'attivazione. Ci sono volute centinaia di operazioni appositamente costruite.
L'AI rende più rapido trovare bug di questo tipo, sia per i cattivi che per i buoni.
Insieme a RippleX e alla comunità, faremo in modo che l'XRP Ledger sia protetto contro vulnerabilità di questo tipo. Ciò significa applicare in modo radicale la Verifica Formale e i test avversari basati su AI, collaborare strettamente con i ricercatori di sicurezza e rafforzare il programma di bug bounty.
Sentirete molto altro su questo man mano che progrediamo.
- La decentralizzazione dell'XRP Ledger al centro di tutto questo.
Una correzione pubblica mostra agli aggressori dov'è il bug, e l'AI rende tutto più veloce. Con un normale voto di emendamento, la correzione sarebbe stata pubblica per settim prima di entrare in vigore, rischiando la sicurezza della rete.
In reazione a questo, la comunità XRPL si è unita, e tra loro la XRP Ledger Foundation, RippleX, gli sviluppatori core e i validatori hanno formato un consenso sociale e concordato una strada che prevede la distribuzione diretta della correzione. Applicare patch a una rete attiva non è mai banale, quindi il piano è stato progettato anche per ridurre al minimo i disagi per chiunque vi operi.
Abbiamo condiviso la build con i validatori della default UNL, utilizzando i contatti che ciascuno pubblica nel proprio file xrp-ledger.toml. I binari pubblici sono seguiti lo stesso giorno, il 25 settembre.
Nessuna singola parte poteva prendere quella decisione da sola. Ogni validatore e operatore di nodo sceglie quale software eseguire, e la 3.4.1 è diventata obbligatoria solo attraverso un normale voto di emendamento con oltre l'80% di supporto dei validatori per due settimane. Le modifiche al protocollo passano ancora tramite gli emendamenti.
Un ringraziamento speciale a Cayden Liao e Veria AI per aver trovato e segnalato questo in modo responsabile, agli sviluppatori core di XRPL per aver costruito e testato la correzione, e a ogni operatore di nodo che ha aggiornato così rapidamente, in particolare i validatori.
Report completo:
— XRP Ledger Foundation (@XRPLF) October 11, 2026
La Foundation ha descritto il rilascio diretto del software come una risposta eccezionale, non come un sostituto della governance ordinaria. Il suo rapporto ha dichiarato che si è trattata della prima modifica diretta e deliberata all'elaborazione delle transazioni da quando il sistema di emendamenti è stato introdotto più di un decennio fa. Le future modifiche al protocollo, ha detto, continueranno a richiedere emendamenti sostenuti dai validatori.
I validatori hanno mantenuto il controllo sull'installazione del software
La Foundation ha dichiarato di aver condiviso la build con la patch con gli operatori dei validatori della default UNL prima del rilascio dei binari pubblici il 25 settembre. Quegli operatori hanno deciso se eseguire la nuova versione. Né la Foundation né RippleX potevano imporre un aggiornamento su server gestiti in modo indipendente.
Questo ha creato un breve periodo in cui i server con e senza patch seguivano regole diverse per il percorso di pagamento specializzato. Secondo il rapporto XRPL, un tentativo di exploit durante quel periodo avrebbe potuto causare discrepanze tra le versioni e potenzialmente disturbare la validazione. Il team ha giudicato tale rischio preferibile rispetto a lasciare aperto un attacco di inflazione potenzialmente irreversibile durante un più lungo periodo di attivazione pubblica.
La risposta è stata coordinata attraverso la XRP Ledger Foundation, RippleX, gli sviluppatori core e i validatori, ma nessuna singola organizzazione poteva prendere la decisione da sola. Ogni validatore e operatore di nodo sceglie quale software eseguire, mentre il sistema di emendamenti rimane il meccanismo per rendere obbligatorie le modifiche al protocollo.
Cosa significa la divulgazione per utenti e operatori
Il report non haiesto ai possessori di XRP di spostare fondi o sostituire i propri wallet. Per gli operatori di nodo, XRPL ha dichiarato che i server dovrebbero eseguire la versione xrpld 3.4.1 o successive per rimanere sincronizzati con la rete. In termini pratici, la mitigazione indicata riguardava il software che mantiene l'infrastruttura del ledger, non un'azione sul wallet richiesta ai possessori di XRP.
La Foundation ha anche dichiarato che un pagamento normale non si avvicinerebbe nemmeno all'attivazione della vulnerabilità. Lo sfruttamento richiedeva centinaia di operazioni appositamente costruite. Ha aggiunto che l'intelligenza artificiale può rendere più rapida l'individuazione delle vulnerabilità sia per gli aggressori che per i difensori.
Misure di sicurezza pianificate
La Foundation ha dichiarato di avere in programma di ampliare l'uso della verifica formale e dei test avversari basati su AI, di collaborare più strettamente con ricercatori di sicurezza esterni e di rafforzare il suo programma di bug bounty. Queste misure non possono garantire che non emergeranno più problemi critici, ma sono intese a migliorare le probabilità che le vulnerabilità vengano identificate prima di un rilascio in produzione.
Il rapporto di divulgazione descrive inoltre una misura di controllo dei rilasci. I risultati di sicurezza contrassegnati come corretti dovrebbero essere testati nuovamente sulla release candidate contenente la patch, e il problema originariamente segnalato dovrebbe essere riprodotto prima di chiudere il rilievo. Tale processo offre ai ricercatori esterni uno standard definito rispetto al quale valutare i rilasci successivi.
La vulnerabilità ha esposto una grave debolezza in una regola progettata per preservare l'offerta fissa di XRP. La risposta ha prodotto un registro pubblico composto da un report di bug bounty, un aggiornamento accelerato dei validatori, una successiva divulgazione tecnica e impegni per rafforzare le pratiche di sicurezza. La misura in cui tali impegni diventeranno una prassi routinaria dei futuri processi di rilascio ne determinerà il significato a lungo termine.
Questo articolo ha finalità puramente informative e non costituisce una consulenza finanziaria. I dettagli sui rilasci software e sulle divulgazioni di sicurezza possono cambiare man mano che ulteriori informazioni tecniche diventano disponibili.
Fonte: Coindoo.