Una falla di XRP Ledger scoperta dall'IA ha esposto un percorso per coniare 18,45 trilioni di XRP
Veria AI ha scoperto una falla in XRP Ledger che, secondo i ricercatori, avrebbe potuto coniare 18,45 trilioni di XRP, nonostante l'offerta fissa di 100 miliardi della criptovaluta.
L'exploit combinava un'aritmetica difettosa nel motore dei pagamenti del ledger con un controllo di sicurezza che ripeteva lo stesso errore. Un pagamento appositamente costruito avrebbe potuto accreditare centinaia di account venditori, addebitando al compratore una somma quasi nulla.
RippleX ha riprodotto l'exploit, lo ha classificato come critico e ha rilasciato xrpld 3.4.1 il 25 settembre 2026. La divulgazione ufficiale afferma che gli investigatori non hanno trovato prove che qualcuno abbia sfruttato la vulnerabilità su una rete pubblica.
Questa distinzione è importante. Non si è trattato di un furto di 18 trilioni di XRP, né l'importo teorico avrebbe avuto un valore di mercato realizzabile. Era però un percorso credibile per violare la regola fondamentale dell'offerta di XRP.
L'incidente mette inoltre alla prova una promessa più ampia legata alla sicurezza assistita dall'IA. Un agente IA avrebbe apparentemente individuato un difetto vecchio di dieci anni che audit e test convenzionali non avevano rilevato. Tuttavia, i ricercatori umani hanno comunque dovuto convalidare il risultato, coordinare una correzione riservata e convincere i validator ad aggiornarsi.
La falla di XRP Ledger è stata corretta prima della divulgazione pubblica
La notizia immediata è una risposta d'emergenza riuscita a una vulnerabilità rimasta raggiungibile per quasi un decennio.
Veria Labs afferma di aver indirizzato il proprio agente di sicurezza verso rippled, il software server open source utilizzato da XRP Ledger. L'azienda sostiene che il suo sistema abbia identificato il codice vulnerabile, sviluppato un exploit funzionante e lo abbia testato su una rete locale.
La ricostruzione tecnica dell'azienda data il rilevamento iniziale dell'IA al 21 settembre. Secondo Veria, il sistema ha prodotto una proof of concept funzionante il giorno successivo.
Il ricercatore Cayden Liao ha esaminato il risultato e lo ha segnalato tramite il programma bug bounty di XRPL il 22 settembre. Gli ingegneri di RippleX hanno confermato il problema quel giorno stesso, dopo averlo riprodotto su un server standalone e nel proprio framework di test.
La conferma è andata oltre la dimostrazione di una discrepanza contabile. RippleX ha stabilito che gli XRP appena creati potevano essere trasferiti in un pagamento successivo, rendendo l'output effettivamente spendibile.
Gli sviluppatori hanno integrato una correzione il 23 settembre e rilasciato rippled 3.4.1 due giorni dopo. La divulgazione pubblica ha atteso fino al 9 ottobre, dopo che gli operatori avevano avuto il tempo di installare il software corretto.
Veria afferma che oltre l'80 percento dei validator eseguiva la release il 25 settembre. L'account ufficiale di XRPL ha analogamente riportato che quel giorno oltre l'80 percento dei validator nella Unique Node List predefinita aveva effettuato l'aggiornamento.
Una Unique Node List, o UNL, identifica i validator di cui un server si fida nel valutare il consenso. La rapida adozione tra questi validator ha ridotto il pericolo creato dai nodi più vecchi che continuavano ad accettare la transazione vulnerabile.
La risposta si è discostata dal percorso normale per modificare il comportamento delle transazioni. XRPL introduce generalmente modifiche sensibili al consenso tramite amendment, che i validator valutano prima dell'attivazione.
Gli sviluppatori hanno invece inserito direttamente la correzione dell'overflow nella release del server. Hanno temporaneamente trattenuto le modifiche al codice sorgente pertinenti, limitando la possibilità che gli aggressori effettuassero il reverse engineering della vulnerabilità prima che un numero sufficiente di validator si aggiornasse.
Questa scelta ha concentrato la fiducia nei maintainer e negli operatori dei validator per un breve periodo. Ha inoltre impedito che un processo di amendment pubblico diventasse un manuale per un bug di inflazione immediatamente sfruttabile.
Il rapporto ufficiale afferma che XRPL Foundation, RippleX e i validator partecipanti hanno considerato l'aggiornamento riservato più sicuro rispetto al lasciare disponibile un exploit aperto per settimane. La correzione è diventata pubblica dopo che la rete ha superato la soglia di sicurezza necessaria.
Veria ha ricevuto la ricompensa critica massima di $250,000 l'8 ottobre. L'importo riconosce il livello di gravità, ma non va confuso con una perdita quantificata.
Non sono stati trovati XRP non autorizzati, non sono stati segnalati fondi utente mancanti e nessuna transazione sul ledger pubblico è stata collegata all'exploit. L'emergenza riguardava ciò che il codice accettava, non danni già osservati.
Questo esito rende facile minimizzare l'evento. Tuttavia, l'assenza di sfruttamento non riduce l'importanza di un difetto che avrebbe potuto invalidare l'assunto dell'offerta fissa dell'asset.
Come la falla di XRP Ledger avrebbe potuto creare XRP spendibili
L'exploit funzionava perché due salvaguardie monetarie eseguivano calcoli vulnerabili in modo quasi identico.
Il primo difetto compariva nella gestione, da parte del motore dei pagamenti, delle offerte dell'exchange decentralizzato integrato in XRP Ledger. Le offerte consentono agli account di scambiare XRP o asset emessi attraverso gli order book del ledger.
Un aggressore avrebbe iniziato creando numerosi account controllati ed emettendo un token privo di valore. Questi account avrebbero poi inserito centinaia di offerte artificiali richiedendo importi XRP estremamente elevati per quel token.
La proof of concept di Veria utilizzava 256 offerte. Ciascuna richiedeva poco più di 2^56 drop, dove un drop rappresenta un milionesimo di XRP.
L'aggressore avrebbe quindi inviato un unico pagamento progettato per consumare l'intera raccolta di offerte. Il motore dei pagamenti doveva sommare gli importi XRP associati a ciascuna offerta prima di addebitare il compratore.
Quel totale superava la capacità dell'intero senza segno a 64 bit utilizzato per il calcolo. Un integer overflow si verifica quando un valore supera il massimo consentito e torna a un numero molto più piccolo.
In questo caso, l'aggregato superava 2^64 drop. I singoli proprietari delle offerte potevano ricevere gli importi completi, mentre l'overflow faceva apparire l'addebito complessivo del compratore pari a soli 256 drop.
Si trattava di qualcosa di più grave di una quotazione di scambio errata. I saldi accreditati rappresentavano XRP che nessun account sorgente aveva fornito.
Il risultato era approssimativamente di 18.446.744.073.709 XRP, prima di considerare l'addebito alla fonte e la commissione di transazione. Veria riassume l'output utilizzabile come circa 18,45 trilioni di XRP distribuiti su 256 account.
Questa distribuzione era essenziale. XRPL applica un limite agli XRP detenuti da un singolo account, ma ogni destinatario restava al di sotto di tale soglia.
L'attacco aggirava quindi una salvaguardia dividendo i nuovi XRP tra molti account. I ricercatori affermano che gli XRP accreditati avrebbero poi potuto transitare attraverso pagamenti ordinari o raggiungere gli exchange.
XRPL disponeva inoltre di un invariant destinato a prevenire esattamente questo risultato. Un invariant è una condizione di sicurezza post-transazione che deve rimanere vera prima che il ledger accetti una modifica.
L'invariant XRPNotCreated calcolava la variazione netta del saldo XRP nell'intera transazione. Avrebbe dovuto rifiutare qualunque risultato mostrasse che la transazione aveva creato più XRP di quanti ne avesse distrutti tramite commissioni.
Tuttavia, quel calcolo utilizzava un'aritmetica vulnerabile allo stesso overflow. La variazione netta tornava a capo fino a somigliare a una normale combustione di commissioni, consentendo il superamento della transazione.
In pratica, il motore dei pagamenti conteggiava erroneamente quanto il compratore doveva. Il controllo dell'offerta, apparentemente indipendente, ripeteva poi il fallimento matematico e approvava il risultato falso.
Questo fallimento condiviso è la lezione progettuale fondamentale. Un controllo di backup offre una protezione limitata quando si basa sullo stesso tipo di dati, comportamento aritmetico o presupposto del componente che monitora.
L'attacco non era qualcosa che un trader ordinario avrebbe potuto attivare accidentalmente. Richiedeva centinaia di offerte deliberatamente prezzate e un pagamento progettato per consumarle insieme.
Richiedeva inoltre alcuni XRP per le riserve di account e offerte, oltre alle commissioni di transazione. Il rapporto sulla vulnerabilità stima il requisito in alcune centinaia di XRP, con la maggior parte delle riserve recuperabile in seguito.
L'aggressore non doveva controllare un validator. Una volta preparata e firmata, la transazione exploit sarebbe entrata nella rete come un pagamento altrimenti ordinario.
L'attacco era inoltre ripetibile. Gruppi aggiuntivi di account controllati avrebbero potuto ricreare la configurazione, consentendo un altro lotto da 18,45 trilioni di XRP.
La correzione ha introdotto controlli di overflow nel codice che somma le offerte. Un totale che supera l'intervallo consentito ora fallisce invece di tornare a capo trasformandosi in un piccolo addebito.
Gli sviluppatori hanno inoltre ampliato l'accumulatore utilizzato dall'invariant dell'offerta. Altri percorsi di somma dei saldi hanno ricevuto un rafforzamento correlato per ridurre la possibilità di un altro fallimento aritmetico condiviso.
Un'offerta fissa rendeva potenziale il danno sistemico
L'esposizione reale non era l'impossibile valore nominale di 18,45 trilioni di XRP, ma la credibilità di ogni unità legittima già in circolazione.
XRP è stato lanciato con un'offerta totale di 100 miliardi di token. Non viene prodotto tramite mining o staking, e le normali commissioni di transazione distruggono piccole quantità nel tempo.
Questo design offre agli utenti una semplice aspettativa monetaria. Le transazioni possono ridistribuire XRP, ma non dovrebbero mai aumentare l'offerta totale.
La falla di XRP Ledger violava questa regola a livello contabile. Se sfruttata, avrebbe potuto collocare XRP appena creati in account normali senza contrassegnare visibilmente tali saldi come diversi.
L'output segnalato di 18,45 trilioni era circa 184 volte l'offerta originaria. Tuttavia, moltiplicare questa quantità per il prezzo di mercato produce una misura fuorviante del danno economico.
Un aggressore non avrebbe potuto vendere trilioni di XRP al prezzo pre-attacco. La liquidità disponibile sarebbe scomparsa, gli exchange avrebbero potuto sospendere le negoziazioni e il prezzo avrebbe reagito molto prima che la maggior parte dei token raggiungesse un compratore.
Il riferimento più significativo era la capitalizzazione di mercato di XRP, pari a circa $94 miliardi, quando Veria ha valutato la vulnerabilità. Rappresentava il valore la cui assunzione di scarsità sottostante era sotto pressione.
Anche questa cifra non è una stima di perdita garantita. La capitalizzazione di mercato non equivale al denaro custodito all'interno di una rete e i diversi detentori avrebbero sperimentato esiti diversi.
Il rischio sistemico derivava dalla fiducia. Un'emissione non autorizzata avrebbe potuto diluire i detentori esistenti, travolgere la liquidità degli exchange, interrompere le applicazioni e sollevare interrogativi sulle garanzie contabili del ledger.
Anche le istituzioni avrebbero affrontato incertezza operativa. Gli exchange avrebbero potuto dover identificare i depositi interessati, i fornitori di pagamenti avrebbero potuto sospendere il regolamento e i custodian avrebbero potuto limitare i prelievi durante un'indagine.
Queste risposte avrebbero potuto danneggiare utenti legittimi anche se un aggressore avesse catturato solo una piccola parte dell'importo in evidenza. Un fallimento dell'offerta si estende oltre gli account direttamente coinvolti.
Questo aiuta a spiegare il rilascio riservato. I maintainer stavano proteggendo sia il protocollo sia la finestra di risposta disponibile per exchange, validator e fornitori di infrastruttura.
La falla esisteva probabilmente da quando il motore dei pagamenti è stato scritto nel 2015. Una seconda debolezza nell'invariant dell'offerta risaliva al 2017, secondo l'analisi di Veria.
Questa cronologia mette in discussione l'idea che la longevità da sola dimostri la sicurezza. Il software può elaborare miliardi di transazioni mantenendo al contempo un percorso di exploit che l'attività normale non esercita mai.
Ripple ha dichiarato a marzo che XRPL aveva elaborato oltre 100 milioni di ledger e tre miliardi di transazioni dal 2012. Questi numeri dimostrano un uso esteso, ma non coprono ogni possibile stato aritmetico.
Qui contava l'input raro. I pagamenti normali non potevano avvicinarsi al valore necessario per l'overflow perché l'offerta legittima di XRP era molto al di sotto di tale soglia.
Un aggressore avrebbe dovuto fabbricare valori estremi del book degli ordini su molte offerte. I test convenzionali basati su comportamenti economici plausibili potrebbero non aver mai esplorato quella combinazione.
Nemmeno gli audit hanno eliminato il rischio. Veria afferma che la codebase è stata sottoposta a più di una dozzina di audit o competizioni di auditing a partire dal 2024, insieme a un consolidato programma di bounty.
Questo non dimostra che gli audit siano stati negligenti. Gli audit operano entro limiti di tempo, perimetro e incentivi, mentre interazioni rare possono restare nascoste tra componenti separati.
La lezione è più circoscritta e più utile. Il codice finanziario maturo necessita di test che mettano alla prova i limiti della macchina, non soltanto scenari che assomigliano al normale comportamento degli utenti.
La sicurezza AI ha individuato il bug, ma gli umani lo hanno contenuto
La scoperta sostiene l'uso dell'AI nella sicurezza, mentre la risposta mostra perché la scansione autonoma è solo uno strato della difesa di un protocollo.
Veria attribuisce sia la scoperta sia la costruzione dell'exploit al proprio agente di sicurezza AI. L'azienda afferma che il sistema ha analizzato rippled, collegato le due debolezze aritmetiche e realizzato una proof of concept locale funzionante.
Questo resoconto è significativo perché la vulnerabilità richiedeva ragionamento tra componenti diversi. Individuare il solo overflow nei pagamenti non avrebbe garantito il successo se l'invariante dell'offerta avesse respinto la transazione.
Secondo quanto riferito, l'agente ha riconosciuto che l'invariante ripeteva l'overflow. Ha quindi progettato un input che attivava entrambi i guasti all'interno di una singola transazione.
Le affermazioni di Veria godono di un significativo riscontro esterno. RippleX ha riprodotto indipendentemente l'exploit, confermato la spendibilità degli XRP coniati e innalzato la segnalazione da grave a critica.
La disclosure ufficiale di XRPL non fornisce una valutazione completa dell'autonomia dell'agente. Conferma la segnalazione e il risultato tecnico, ma non misura in modo indipendente quanta guida umana abbia prodotto la scoperta.
Questa lacuna conta nella valutazione dei prodotti di sicurezza AI. Una scoperta riuscita può coinvolgere, in proporzioni diverse, analisi automatizzata del codice, prompt scritti da esseri umani, revisione iterativa e convalida manuale dell'exploit.
L'incidente fornisce comunque prove più solide di un punteggio benchmark. Ha portato a una vulnerabilità critica confermata, a una release di produzione e al pagamento di una bounty massima.
Ripple aveva già annunciato un più ampio programma di sicurezza AI nel marzo 2026. Il programma combinava test assistiti dall'AI con un red team dedicato, fuzzing, verifica formale e una revisione più rigorosa degli amendment.
Il fuzz testing fornisce al software input inattesi o malformati per individuare crash e stati non validi. La verifica formale utilizza tecniche matematiche per testare se il software soddisfa proprietà definite.
Questi metodi affrontano modalità di guasto differenti. L'AI può ispezionare il codice e proporre percorsi d'attacco, i fuzzer possono esplorare spazi di input e i metodi formali possono verificare invarianti critici.
Gli ingegneri umani decidono comunque se una scoperta è raggiungibile, se il suo impatto è reale e come ripararla senza compromettere il consenso. Gestiscono inoltre la disclosure presso una base decentralizzata di operatori.
La risposta di XRP Ledger illustra chiaramente questa divisione. L'agente ha trovato il percorso, Liao lo ha esaminato e RippleX ha riprodotto l'exploit in ambienti controllati.
Gli sviluppatori hanno poi modificato più percorsi aritmetici. Gli operatori dei validator hanno installato la release, mentre i manutentori monitoravano l'adozione prima di divulgare i dettagli.
Nessun singolo partecipante controllava l'intero esito. Il sistema dipendeva dalla cooperazione tra una società privata di sicurezza, sviluppatori open source, una fondazione, RippleX e operatori indipendenti.
Questo coordinamento è un punto di forza perché più parti hanno esaminato la scoperta. È anche una dipendenza di governance che merita attenzione.
La patch d'emergenza è stata distribuita prima che la spiegazione a livello di codice diventasse pubblica. I validator hanno dovuto decidere se fidarsi della release senza ricevere la normale trasparenza disponibile per le modifiche di routine.
L'alternativa comportava un pericolo proprio. Pubblicare l'esatta meccanica dell'overflow prima di un'ampia adozione avrebbe fornito agli aggressori un percorso funzionante contro ogni validator non aggiornato.
Questo è il compromesso centrale, non una semplice competizione tra AI e auditing umano. Una scoperta più rapida aumenta il valore di procedure di risposta rapide, affidabili e governate con cura.
Gli stessi strumenti che aiutano i difensori a ispezionare codice datato possono anche aiutare gli aggressori a cercare errori equivalenti. L'ingegnera di RippleX Mayukha Vadari ha avvertito nella disclosure che l'AI modifica le tempistiche della scoperta e dello sfruttamento delle vulnerabilità.
Un programma maturo necessita quindi di qualcosa in più rispetto a scanner migliori. Richiede disclosure riservate collaudate, standard di gravità chiari, canali di comunicazione con i validator e una prontezza agli aggiornamenti misurabile.
Cosa non dimostra il difetto di XRP Ledger
L'exploit confermato era grave, ma diverse interpretazioni da titolo di giornale vanno oltre le prove disponibili.
Primo, non ci sono prove che 18,45 trilioni di XRP siano entrati in un ledger pubblico. I ricercatori hanno creato l'output in un ambiente controllato durante la convalida della vulnerabilità.
Secondo, nessuna fonte ha stabilito che gli aggressori conoscessero il percorso prima della segnalazione di Veria. L'età del codice vulnerabile descrive il tempo di esposizione, non una conoscenza avversaria confermata.
Terzo, i presunti 94 miliardi di dollari a rischio non dovrebbero essere considerati una previsione di perdita. Descrivono il mercato la cui garanzia di scarsità avrebbe potuto subire danni.
Quarto, l'incidente non stabilisce che un sistema AI abbia completato autonomamente ogni fase della ricerca. Veria ha fornito il resoconto più dettagliato sul ruolo dell'agente, mentre gli umani hanno svolto revisione e disclosure.
Queste cautele non rendono la scoperta teorica in senso liquidatorio. RippleX ha riprodotto la transazione e confermato che un pagamento successivo poteva spendere i nuovi XRP.
La vulnerabilità ha inoltre raggiunto il codice di produzione. Non si trattava di una funzionalità proposta e intercettata prima dell'attivazione, a differenza di un problema separato relativo alle transazioni Batch riparato nella stessa release 3.4.1.
Combinare questi incidenti può creare confusione. Il difetto Batch riguardava la convalida del wrapper e un possibile disaccordo tra versioni dei server.
Quell'amendment Batch non era stato attivato sulla rete principale. I validator hanno gestito la sua riparazione tramite voto sugli amendment e la versione corretta è stata attivata il 9 ottobre.
L'overflow XRP ha seguito un percorso diverso. Colpiva il comportamento esistente del motore dei pagamenti ed è stato riparato immediatamente quando i nodi hanno installato la versione 3.4.1.
Il record della release contiene quindi due correzioni di sicurezza con storie diverse di esposizione e governance. Solo l'overflow nei pagamenti ha creato il presunto percorso di conio.
Un'altra incertezza riguarda l'individuazione storica. XRPL afferma di non aver trovato prove di sfruttamento sulle reti pubbliche, ma i lettori dovrebbero distinguere tra “nessuna prova” e una prova assoluta di assenza.
Un aggressore che utilizzasse l'exploit creerebbe insolite variazioni di saldo e attività nel book degli ordini. Tali tracce dovrebbero agevolare l'analisi retrospettiva, soprattutto data la necessità di centinaia di offerte artificiali.
Tuttavia, la disclosure pubblica non presenta una metodologia forense completa né una ricerca della cronologia del ledger sottoposta ad audit indipendente. La sua conclusione resta il risultato riportato dai manutentori.
Anche il rapido aggiornamento della rete merita un esame continuo. Un'adozione superiore all'80 per cento tra i validator default-UNL ha ridotto l'esposizione immediata, ma altri nodi e fornitori di infrastruttura seguono calendari diversi.
Il software meno recente non può essere reso sicuro da una dichiarazione di disclosure. Gli operatori che eseguono rippled 3.4.0 o versioni precedenti restano responsabili dell'aggiornamento.
Infine, questo evento non dimostra che l'AI abbia reso completo l'auditing blockchain. Dimostra che un processo assistito dall'AI ha trovato un bug importante in una codebase matura.
Il prossimo test è la ripetibilità. I team di sicurezza necessitano di prove che sistemi simili trovino vulnerabilità diverse e precedentemente ignote senza sommergere i manutentori di segnalazioni deboli.
Devono anche valutare l'uso avversario. Una scoperta difensiva più rapida è utile solo quando riparazione e distribuzione possono superare la riproduzione malevola.
Tre segnali mostreranno se il modello di sicurezza è migliorato
La prossima fase dovrebbe essere giudicata attraverso il codice, il comportamento dei validator e risultati di sicurezza riproducibili in modo indipendente.
Il primo segnale è la continua adozione di rippled 3.4.1 o successivo. La correzione dell'overflow critico si applica durante l'installazione del software, quindi i nodi obsoleti restano il rischio evitabile più evidente.
La telemetria pubblica dei validator dovrebbe mostrare la scomparsa delle versioni vulnerabili dai ruoli di consenso significativi. Un'adozione lenta indebolirebbe l'affermazione secondo cui XRPL può coordinarsi in condizioni urgenti.
Il secondo segnale è una revisione tecnica degli invarianti monetari oltre questa specifica patch. Il controllo dell'offerta fallito condivideva il comportamento aritmetico con il componente che avrebbe dovuto monitorare.
Gli sviluppatori dovrebbero testare altri totali, conversioni e percorsi dei saldi con accumulatori più ampi e una gestione esplicita dell'overflow. Una revisione indipendente rafforzerebbe la fiducia più di un'altra garanzia generica.
Il terzo segnale è la prova che i test assistiti dall'AI producano scoperte ripetibili in condizioni di disclosure responsabile. Vulnerabilità confermate, bassi tassi di falsi positivi e una chiara supervisione umana sosterrebbero l'affermazione più ampia di Veria.
Un flusso di segnalazioni sensazionalistiche ma non verificate la indebolirebbe. Lo farebbero anche scoperte che richiedono un'ampia ricostruzione umana non divulgata prima di diventare attuabili.
L'incidente modifica già la base di riferimento della sicurezza. Operatività di lunga durata, audit precedenti e un design a offerta decrescente non hanno impedito che un errore relativo ai limiti della macchina minacciasse la regola monetaria fondamentale di XRP.
Allo stesso tempo, la risposta ha funzionato prima che apparisse un exploit pubblico. I ricercatori hanno segnalato il problema, gli ingegneri lo hanno riprodotto e i validator hanno installato una riparazione d'emergenza nel giro di pochi giorni.
Sviluppatori e operatori dell'infrastruttura dovrebbero ora chiedersi se i propri controlli di sicurezza falliscano in modo diverso dai sistemi che supervisionano. Un'assunzione duplicata non è una vera difesa in profondità.
Per i lettori che seguono il difetto di XRP Ledger, l'azione più utile è monitorare l'adozione della versione, la revisione indipendente del codice e le future disclosure di bounty. Questi segnali mostreranno se si è trattato di una riparazione isolata o dell'inizio di un modello di sicurezza più solido.
