Un bug del 2015 su XRP Ledger e la fine dell’audit artigianale

Il 22 settembre 2026 Veria Labs ha segnalato a RippleX un overflow aritmetico nel motore di pagamento dell’XRP Ledger. Tre giorni dopo, il 25, RippleX ha pubblicato la versione 3.4.1 di xrpld e già quello stesso giorno oltre l’80% dei validatori della Unique Node List predefinita la stava eseguendo. Il difetto era nel codice dal 2015. Secondo il rapporto di divulgazione ripreso da The Block, non ci sono prove che sia mai stato sfruttato su una rete pubblica.

Cayden Liao, cofondatore responsabile sicurezza di Veria, sostiene che a trovarlo e a costruire l’exploit funzionante sia stato un agente di IA. Secondo i suoi calcoli, una singola transazione poteva creare circa 18.000 miliardi di XRP: 184 volte l’offerta totale della rete, fissata in 100 miliardi al lancio e decrescente man mano che le commissioni vengono bruciate. Ripple ha pagato la ricompensa massima prevista dal suo programma, 250.000 dollari.

Il meccanismo: due bug lievi che insieme valgono una rete

Il motore di pagamento dell’XRPL consente a un pagamento di consumare più ordini del book contemporaneamente. La somma di quegli ordini non prevedeva alcun controllo di overflow: un totale sufficientemente grande andava in wrap-around e si trasformava in un numero piccolo. L’attacco descritto nel rapporto consisteva nell’aprire qualche centinaio di conti, fare in modo che ciascuno mettesse in vendita una frazione minuscola di un token in cambio di una quantità enorme di XRP, e poi chiudere tutte quelle vendite con un unico pagamento. Ogni wallet venditore incassava per intero; l’acquirente pagava «solo qualche centinaio di drop più la commissione».

Il pezzo che trasforma un errore contabile in un difetto sistemico è il secondo: il controllo che la rete esegue proprio per impedire la creazione di nuovi XRP sommava i saldi con lo stesso difetto. Il guardiano aveva lo stesso buco della porta. Come ha scritto Liao, «sospettiamo che una delle ragioni per cui nessuno ha individuato questa vulnerabilità è che concatena due bug che presi separatamente sarebbero di severità bassa».

È qui il dato interessante, non nei 18.000 miliardi. Un decennio di audit umani, da parte di revisori di Ripple e di terzi, è passato sopra quel codice senza vederlo, perché ciascuna metà del problema era di per sé noiosa. La revisione umana procede per moduli e per ipotesi: si verifica il motore di pagamento, si verifica il controllo sull’emissione, e quasi mai si modella lo stato congiunto dei due sotto input che nessun operatore razionale genererebbe. Lo sottolinea lo stesso rapporto: «L’attacco non poteva innescarsi per caso. Richiedeva centinaia di ordini con prezzi che nessun trader reale userebbe». È esattamente ciò che un agente che esplora lo spazio degli stati senza costo di noia, invece, fa.

L’asimmetria che nessuno ha ritarato

Il programma di bug bounty dell’XRP Ledger ha un tetto di 250.000 dollari. È una cifra alta per gli standard del settore e ridicola rispetto a ciò che era in gioco. Le stime circolate collocano il valore nozionale degli XRP coniabili intorno ai 94 miliardi di dollari, il che lascia un rapporto di circa 1 a 376.000 tra quanto incassa chi segnala e quanto potrebbe catturare chi non segnala.

Quella cifra nozionale merita un grosso asterisco, e ci tornerò sopra. Ma il problema strutturale non dipende dall’esattezza del numero. I programmi di bug bounty sono stati concepiti quando trovare un difetto critico in una catena in produzione era un atto artigianale, raro e lento: mesi di lavoro di uno specialista che, per di più, aveva pochi acquirenti alternativi. Il prezzo rifletteva la scarsità dell’offerta, non il valore dell’asset protetto. L’IA ha appena spostato la curva di offerta: il costo marginale di far girare un agente su una base di codice vecchia di dieci anni tende a zero, e lo stesso agente è disponibile a chiunque voglia rivenderne il risultato su un altro mercato.

Che quell’altro mercato esista e liquidi bene lo dimostrano le ultime settimane. Ledger ha confermato un impianto hardware non autorizzato in almeno un dispositivo distribuito dal rivenditore CryptoBilis, con perdite stimate da investigatori on-chain tra 86 e 93 milioni di dollari su oltre 300 wallet. Nel luglio 2026 un difetto nel firmware di generazione dei seed di Coldcard ha permesso di prosciugare tra 100 e 130 milioni in bitcoin. Sono operazioni che richiedono logistica fisica o catene di fornitura compromesse, e rendono comunque due ordini di grandezza più della ricompensa massima della maggior parte dei programmi di divulgazione. Un exploit remoto, riproducibile e senza contatto fisico rende di più.

La conclusione operativa è scomoda: se il costo della scoperta crolla per tutti nello stesso momento, l’unico strumento rimasto per indirizzare la scoperta verso la divulgazione responsabile è il prezzo. E il prezzo resta ancorato all’economia del 2019.

La patch che ha scavalcato la governance

Nell’XRP Ledger le modifiche alle regole passano normalmente per un processo di emendamento: una proposta ha bisogno del sostegno di oltre l’80% dei validatori fidati mantenuto per due settimane. Questa correzione no. È entrata in vigore server per server, man mano che ogni operatore aggiornava, e il rapporto riconosce che è la prima volta in oltre dieci anni di emendamenti che accade così. In più, il codice sorgente della 3.4.1 è stato pubblicato circa due settimane dopo i binari. Justin Bons, di Cyber Capital, l’ha riassunta senza giri di parole: «XRP ha girato con codice chiuso per le ultime due settimane».

La risposta dell’ingegnera di RippleX Mayukha Vadari è l’argomento più rilevante di tutta la vicenda: «L’IA ha cambiato le cose. Non puoi far passare la patch di un bug critico dentro un processo di rilascio pubblico di routine, verrà individuata e sottoposta a reverse engineering immediatamente». J. Ayo Akinyele, responsabile ingegneria, ha annunciato che amplieranno la ricerca di difetti assistita da IA e la verifica formale. La difesa della patch d’emergenza è diventata un dibattito pubblico all’interno dell’ecosistema.

Vadari ha ragione nella diagnosi tecnica, ed è per questo che il problema è peggiore di quanto sembri. Per quindici anni l’open source ha operato con una finestra implicita tra la pubblicazione della patch e lo sfruttamento di massa: il tempo che serviva a un attaccante umano per leggere un diff e capire cosa correggeva. Quella finestra si è chiusa. Se qualsiasi agente può confrontare due versioni e ricostruire l’exploit in pochi minuti, la divulgazione coordinata classica smette di funzionare e l’alternativa è ciò che ha fatto RippleX: prima i binari, poi il sorgente, e aggiornamento di fatto senza voto.

Ciò che questo rivela non è un complotto, ma una capacità. Qualcuno è riuscito a muovere oltre l’80% dei validatori della UNL predefinita in settantadue ore, senza passare per il meccanismo di governance progettato a quello scopo. Quella capacità è un asset di sicurezza preziosissimo — senza di essa il difetto sarebbe rimasto esposto per settimane — e allo stesso tempo il vettore di rischio più concreto dell’intera rete. È la domanda che dovrebbe occupare chi sta scrivendo regole sulla tokenizzazione di titoli e materie prime: non quanti nodi ci sono, ma chi può cambiare le regole di regolamento in tre giorni e sotto quale supervisione. In una rete che ambisce a regolare asset del mondo reale, il potere di patch d’emergenza è, funzionalmente, una facoltà di intervento. Nessuno l’ha registrata come tale.

Cosa smentirebbe questa lettura

Diverse cose, ed è giusto dirle. Primo: i 94 miliardi sono nozionali, non realizzabili. Coniare 18.000 miliardi di XRP distrugge il prezzo dell’XRP nello stesso blocco; il valore realmente estraibile sarebbe una frazione minima di quella cifra, limitata dalla liquidità in uscita sugli exchange e dalla probabilità altissima di un rollback sociale della catena. L’asimmetria 1:376.000 è retoricamente potente ed economicamente imprecisa. Resta vero che il danno reputazionale sarebbe terminale anche se l’attaccante non portasse via nulla.

Secondo: «l’ha trovato un’IA» è un’affermazione difficile da verificare e commercialmente utile per una startup di sicurezza. Non sappiamo quanta regia umana ci sia stata nel prompt, nella selezione del modulo o nella costruzione dell’exploit. È plausibile che l’agente sia stato l’acceleratore di un’intuizione umana precedente, titolo decisamente meno vendibile.

Terzo: la concentrazione dei validatori dell’XRPL non è una rivelazione. È una proprietà nota e criticata da anni. La patch d’emergenza non la crea, la rende solo visibile in un momento in cui la domanda diventa regolatoria.

E quarto: resta da vedere il tasso di falsi positivi. Un agente che segnala duecento riscontri di cui uno solo reale sposta il costo sul team di ingegneria, non lo riduce. Il caso XRPL è, per ora, un’osservazione, non una serie statistica.

La difesa si riprogetta nel livello sbagliato

Nel frattempo, la conversazione dominante su IA e sicurezza crypto va da tutt’altra parte. Justin Drake, della Ethereum Foundation, ha avvertito che la matematica guidata dall’IA potrebbe rompere le firme ECDSA prima dei computer quantistici, «nel caso peggiore in mesi, non in anni», e Vitalik Buterin ha detto di ritenere «plausibile» che accada entro due anni. Zakura, che sta costruendo un nodo completo di Zcash, prevede opcode di firma post-quantistica a gennaio, con firme basate su hash (WOTS) per i pagamenti trasparenti, rotazione degli indirizzi dopo ogni transazione e private information retrieval nel wallet Vizor affinché il server non possa collegare tra loro gli indirizzi dello stesso utente.

È lavoro serio e necessario. Ma si noti lo sfasamento: l’industria sta riprogettando il livello crittografico contro un avversario dotato di calcolo massivo, mentre il livello di esecuzione — il codice che decide quanto si paga e a chi — resta C++ del 2015 verificato da esseri umani. Nell’XRP Ledger non è servito rompere nessuna curva ellittica. È servito un intero che andava in wrap-around. L’avversario con IA non partirà dalla matematica difficile: partirà dai dieci milioni di righe di logica di business accumulate nell’ultimo decennio, dove il costo della ricerca è ormai quasi nullo e la ricompensa per chi trova è la stessa di sempre.

Cosa farne, se costruisci o investi

Se hai un protocollo in produzione con codice antecedente al 2022, dai per scontato che ci siano scoperte in sospeso e che qualcuno le farà quest’anno, con o senza il tuo permesso. Tre decisioni concrete:

• Indicizza il tetto della ricompensa al valore a rischio, non al budget di sicurezza. Un tetto fisso di 250.000 dollari su una rete che custodisce miliardi è un segnale di prezzo che spinge lo scopritore verso l’altro mercato. Scale percentuali con un minimo garantito e un massimale alto sono difendibili davanti a un consiglio; un numero tondo ereditato dal 2019 no.
• Scrivi adesso la policy di divulgazione per un mondo senza finestra di patching. La sequenza binari-prima-sorgente-dopo smette di essere una violazione dello spirito dell’open source e diventa una decisione operativa da giustificare in anticipo, non a posteriori e sotto il fuoco. Documenta la soglia che attiva la procedura d’emergenza e chi la dichiara.
• Per l’investitore: chiedi chi ha la chiave della patch. Nella due diligence di qualunque rete che ambisca a regolare asset tokenizzati, il tempo di aggiornamento d’emergenza e l’elenco di chi può coordinarlo valgono più del numero di validatori. Se nessuno può muovere l’80% della rete in settantadue ore, il prossimo difetto critico resta aperto per settimane. Se qualcuno può, quella persona o quell’azienda è un rischio di concentrazione che ancora non compare in nessun memorandum.