Una grave vulnerabilità nel Batch Amendment XRPL è stata corretta prima dell’attivazione su mainnet, grazie a controlli congiunti tra ricercatori di sicurezza e strumenti di intelligenza artificiale.
Summary
Bug individuato durante la fase di voto dei validator
La XRPL Foundation ha corretto una falla critica nel Batch amendment prima che raggiungesse l’attivazione su mainnet. Il problema è emerso mentre l’emendamento era ancora in fase di votazione da parte dei validator ed è stato bloccato tramite un aggiornamento software d’emergenza.
La vulnerabilità è stata individuata il 19 febbraio 2026 dall’ingegnera di sicurezza Pranamya Keshkamat e dallo strumento autonomo Apex di Cantina AI. Secondo la fondazione, nessun fondo utente è mai stato a rischio, poiché l’emendamento non era ancora attivo sulla rete principale.
Cos’era il Batch amendment e dove nasceva l’errore
La falla risiedeva nella logica di validazione delle firme del proposto Batch amendment, noto anche come XLS-56. L’emendamento prevedeva la possibilità di raggruppare più transazioni interne in un unico batch, semplificando l’elaborazione sul ledger.
Queste transazioni interne erano pensate per restare non firmate, delegando l’autorizzazione all’elenco di firmatari del batch esterno. Tuttavia, un errore nel ciclo di validazione dei firmatari comprometteva la sicurezza complessiva del meccanismo.
Secondo la XRPL Foundation, un bug nel ciclo della funzione di controllo dei firmatari poteva causare un’uscita anticipata. Quando il sistema incontrava un firmatario relativo a un account non ancora creato, il processo poteva interrompersi prima del completamento di tutte le verifiche.
Se la chiave di firma corrispondeva al nuovo account, la validazione veniva considerata riuscita. Il sistema saltava così i controlli sui restanti firmatari, lasciando aperta una potenziale via d’attacco.
Rischi di transazioni non autorizzate e impatto potenziale
Questo comportamento creava un percorso per possibili transazioni non autorizzate. In teoria, un attaccante avrebbe potuto eseguire operazioni da account vittima senza disporre delle relative chiavi private, sfruttando l’incompletezza della verifica.
L’emendamento era comunque ancora in fase di voto dei validator e non era stato abilitato sulla mainnet XRPL. La fondazione ha ribadito che “l’emendamento era nella fase di votazione e non era stato attivato su mainnet; nessun fondo è stato a rischio”.
Nel complesso, una vulnerabilità Batch Amendment XRPL di questo tipo, se attivata, avrebbe potuto consentire trasferimenti di fondi e modifiche al ledger senza autorizzazione. Inoltre, in caso di abuso su larga scala, avrebbe potuto generare un impatto sistemico sull’ecosistema.
Come avrebbe potuto funzionare l’exploit
L’exploit segnalato richiedeva una struttura precisa del batch di transazioni. Un attaccante avrebbe dovuto includere tre transazioni interne all’interno di un unico batch, orchestrate in modo specifico.
La prima transazione avrebbe creato un nuovo account controllato dall’attaccante stesso. La seconda avrebbe eseguito una semplice operazione da questo nuovo account, utile ai fini della validazione superficiale. La terza avrebbe tentato un pagamento da un account vittima verso l’attaccante.
L’attaccante avrebbe quindi fornito due voci nella lista dei firmatari del batch. Una voce sarebbe stata valida per il nuovo account creato, mentre la seconda avrebbe finto di autorizzare l’account vittima, senza possedere le sue chiavi.
A causa dell’uscita anticipata dal ciclo di verifica, il sistema avrebbe potuto accettare il primo firmatario e saltare il controllo sul secondo. Di conseguenza, il pagamento dell’account vittima avrebbe potuto essere eseguito senza un’autentica autorizzazione.
Ruolo di Apex e collaborazione con i team di sviluppo
La XRPL Foundation ha precisato che un simile exploit avrebbe potuto consentire trasferimenti non autorizzati e cambiamenti di stato del ledger. Inoltre, la sua eventuale diffusione avrebbe potuto creare forti disagi all’intero ecosistema.
Hari Mulackal, CEO di Cantina e Spearbit, ha dichiarato che “il nostro cacciatore di bug autonomo, Apex, ha individuato questo bug critico”. Lo strumento ha agito come componente chiave nel processo di audit automatizzato.
I team di ingegneria di Ripple hanno riprodotto il problema con una proof of concept completa. Inoltre, è stato sviluppato e completato un test unitario dedicato, prima di procedere alla fase di correzione e all’implementazione delle misure di contenimento.
Aggiornamento d’emergenza rippled e blocco dell’emendamento
Dopo la segnalazione, ai validator UNL è stato consigliato di esprimere voto “No” sul Batch amendment. Contemporaneamente, è stato predisposto un aggiornamento software d’urgenza per impedire ogni possibile attivazione sulla rete.
Il 23 febbraio 2026 è stato rilasciato l’aggiornamento d’emergenza rippled 3.1.1. Questa versione contrassegna sia Batch sia fixBatchInnerSigs come non supportati. Di conseguenza, tali emendamenti non possono più ricevere voti dai validator né essere attivati sul network.
L’aggiornamento non contiene ancora la correzione logica definitiva. Funziona invece come salvaguardia immediata per bloccare ogni possibilità di attivazione delle versioni vulnerabili, guadagnando tempo per una revisione approfondita.
Nuova versione BatchV1_1 e rafforzamento dei controlli
Una versione corretta, denominata BatchV1_1, è già stata implementata nel codice. Il nuovo emendamento elimina l’uscita anticipata dal ciclo di controllo e rafforza le verifiche di autorizzazione sui firmatari.
L’emendamento aggiornato è attualmente in fase di revisione e non è stata ancora fissata una data di rilascio pubblico. La prudenza nella tempistica riflette l’importanza di evitare nuove superfici di attacco.
Detto ciò, la foundation ha indicato che l’obiettivo è mantenere i benefici funzionali del batch di transazioni, senza riproporre le debolezze emerse con il primo disegno di XLS-56.
Uso esteso dell’AI e misure di sicurezza aggiuntive
Sono previste ulteriori misure di sicurezza. La XRPL Foundation ha annunciato l’intenzione di ampliare gli audit del codice supportati da strumenti di intelligenza artificiale, sulla scia del contributo di Apex alla scoperta del bug.
Inoltre, verranno estese le analisi statiche per intercettare più facilmente i casi di “successo prematuro” all’interno dei cicli di codice. Questo approccio mira a individuare in anticipo strutture logiche simili a quelle che hanno causato il problema.
In questo contesto, la gestione tempestiva della vulnerabilità Batch Amendment XRPL viene indicata dalla fondazione come un caso esemplare di prevenzione. L’intervento anticipato ha evitato transazioni non autorizzate e ha contribuito a tutelare l’integrità complessiva della rete.
Conclusioni: lezioni per la sicurezza dei protocolli
Nel complesso, l’episodio mette in luce l’importanza di fasi di test approfondite prima dell’attivazione di nuovi emendamenti su reti pubbliche. La combinazione di ricerca umana e strumenti AI ha dimostrato di poter individuare vulnerabilità sottili.
Il blocco preventivo su XRPL mainnet, tramite rippled 3.1.1 e l’uso di BatchV1_1 come sostituto corretto, offre un modello operativo per la gestione responsabile degli aggiornamenti di protocollo. La priorità resta la protezione dei fondi e la stabilità del ledger.
