La sicurezza di un’infrastruttura finanziaria basata su blockchain non si esaurisce nella protezione delle chiavi con cui gli utenti autorizzano le transazioni: dipende anche dalla capacità del software di applicare correttamente le regole del protocollo. Un errore nel codice condiviso dalla rete può infatti compromettere l’integrità delle operazioni anche in presenza di firme valide e controlli apparentemente regolari. È quanto emerso dalla vulnerabilità corretta a settembre 2026 in XRP Ledger, che avrebbe permesso di creare XRP in violazione delle regole sull’offerta. Il difetto è stato riprodotto in un ambiente locale, senza evidenze di sfruttamento sulla rete pubblica. A rendere il caso particolarmente rilevante è il contributo attribuito all’intelligenza artificiale nella sua individuazione: la possibilità di portare alla luce vulnerabilità rimaste inosservate per anni impone di ripensare anche i tempi della risposta. In questo scenario, la sicurezza dipende tanto dalla capacità di individuare un difetto quanto dalla rapidità con cui è possibile verificarlo, correggerlo e neutralizzare il rischio di sfruttamento.
L’integrità dell’offerta e l’indipendenza dei controlli
XRP Ledger è una blockchain pubblica il cui asset nativo, XRP, presenta una caratteristica precisa: l’offerta iniziale di 100 miliardi di unità non può essere incrementata attraverso il normale funzionamento del protocollo. Le commissioni sulle transazioni, inoltre, riducono progressivamente la quantità complessiva di XRP. È proprio su questo principio che interveniva la vulnerabilità, segnalata il 22 settembre 2026. Il difetto interessava il motore dei pagamenti, che può ricorrere alle offerte del mercato di scambio integrato nella rete. Durante il calcolo degli importi, il software poteva superare i limiti del formato numerico utilizzato e restituire un totale inferiore a quello reale. Lo stesso problema coinvolgeva il controllo incaricato di impedire nuove emissioni, che poteva quindi accettare un risultato errato.
Nella dimostrazione dei ricercatori, una singola operazione permetteva di generare circa 18.450 miliardi di XRP, oltre 184 volte l’offerta iniziale. Questa cifra illustra la portata potenziale della vulnerabilità, senza implicare un’emissione sulla rete pubblica o una perdita economica effettiva. La presenza dello stesso errore nel motore dei pagamenti e nel controllo sull’offerta mette in luce un problema concreto nella progettazione del protocollo: due componenti chiamate a svolgere funzioni diverse possono fallire contemporaneamente se condividono le medesime debolezze. Per un’infrastruttura finanziaria, questo aspetto rende essenziale verificare come interagiscono i diversi livelli di protezione e quali conseguenze possa avere un singolo errore sul funzionamento complessivo della rete.
L’intelligenza artificiale e il riesame del software esistente
Il difetto nel motore dei pagamenti risaliva al 2015, mentre il controllo contro nuove emissioni era stato introdotto nel 2017. Veria Labs, il gruppo di ricerca che ha segnalato la vulnerabilità, attribuisce al proprio agente di intelligenza artificiale la scoperta dei due problemi e la capacità di combinarli in una dimostrazione locale, poi esaminata dai ricercatori. Il caso mostra come questi strumenti possano far emergere debolezze legate all’interazione tra componenti sviluppate in momenti diversi. Il problema non riguarda soltanto le blockchain: anche software utilizzati da decenni possono presentare vulnerabilità che emergono solo in determinate condizioni o attraverso la combinazione di più difetti.
Un esempio viene dal lavoro di Anthropic, che ha documentato attraverso il modello Mythos Preview la scoperta di vulnerabilità presenti da 27 anni nel sistema operativo OpenBSD e da 16 anni nella libreria multimediale FFmpeg. Risultati di questo tipo mostrano quanto a lungo alcune debolezze possano rimanere inosservate anche in software ampiamente utilizzati. Per chi gestisce infrastrutture critiche, diventa quindi importante affiancare alla manutenzione ordinaria verifiche periodiche più approfondite. L’intelligenza artificiale può offrire un contributo significativo a questo lavoro, ma la sua efficacia dipende anche dalla capacità dei ricercatori di confermare i risultati, valutarne le implicazioni e stabilire in quali condizioni un difetto possa essere sfruttato. Allo stesso tempo, la disponibilità di strumenti più potenti può aumentare la pressione su chi deve proteggere sistemi già in produzione, rendendo ancora più importante individuare e correggere tempestivamente le vulnerabilità.
I precedenti e la distinzione tra scoperta e prevenzione
Nel settore cripto, l’intelligenza artificiale ha già contribuito a individuare vulnerabilità rilevanti. Il 19 febbraio 2026, Pranamya Keshkamat e Apex, lo strumento di sicurezza sviluppato da Cantina AI, hanno scoperto un errore nella verifica delle firme della funzione Batch di XRP Ledger, progettata per raggruppare più transazioni. Il difetto avrebbe consentito di eseguire operazioni per conto di altri utenti senza disporre delle loro chiavi private. Poiché la funzione non era ancora stata attivata sulla rete principale, è stato possibile impedirne l’abilitazione nella forma vulnerabile, evitando che il problema raggiungesse gli utenti. Un altro esempio è il programma di ricerca di RippleX, il team di Ripple dedicato allo sviluppo del protocollo e degli strumenti per l’ecosistema XRP Ledger. L’iniziativa combina analisi assistita dall’intelligenza artificiale, test in condizioni avverse e revisione umana, e ha contribuito a correzioni incluse nella versione 3.1.3 del software. Questo approccio mostra come tali strumenti possano affiancare il lavoro dei ricercatori, all’interno di un processo che richiede verifica tecnica e supervisione specialistica.
Il confronto con la vulnerabilità aritmetica segnalata a settembre mette in evidenza due situazioni operative differenti. Quando un difetto viene individuato prima dell’attivazione di una funzionalità, è possibile correggerlo prima che questa entri in uso sulla rete pubblica, limitando l’esposizione degli utenti. Se, invece, la vulnerabilità interessa software già operativo, l’intervento deve avvenire mentre l’infrastruttura continua a elaborare transazioni. In questo caso, la gestione del rischio richiede di tenere insieme la rapidità della correzione, il coordinamento degli aggiornamenti e la continuità del consenso tra i nodi. Anche una soluzione tecnicamente efficace richiede una distribuzione coordinata, che limiti il rischio di divergenze nell’applicazione delle regole del protocollo. La capacità di risposta dipende quindi anche dall’organizzazione degli interventi e dalla possibilità di proteggere la rete senza comprometterne il funzionamento.
La correzione e la finestra di esposizione della rete
La vulnerabilità è stata segnalata il 22 settembre e verificata dagli ingegneri di RippleX; la versione 3.4.1 del software xrpld, realizzata con la XRP Ledger Foundation, è stata annunciata il 25 settembre. La correzione introduce verifiche sulle somme e rafforza il controllo sull’assenza di nuove emissioni. Normalmente, le modifiche all’elaborazione delle transazioni vengono attivate attraverso gli amendment, dopo il mantenimento del sostegno di oltre l’80% dei validatori fidati per due settimane. Questa procedura permette ai server di applicare le nuove regole a partire dallo stesso punto del registro. In questo caso, invece, la protezione è diventata operativa su ciascun server al suo aggiornamento.
Attendere avrebbe prolungato l’esposizione a un difetto che la pubblicazione della correzione avrebbe contribuito a rendere riconoscibile; per la stessa ragione, il codice sorgente è stato inizialmente trattenuto. Durante la transizione, un tentativo di sfruttamento avrebbe però potuto essere accettato dai server precedenti e respinto da quelli aggiornati, causando divergenze sul registro o un arresto della rete. Le transazioni ordinarie non erano interessate da questa differenza. Il rapporto ufficiale sulla vulnerabilità non segnala che tale scenario si sia verificato e indica che oltre l’80% dei validatori inclusi nella lista di riferimento predefinita aveva aggiornato il software il giorno del rilascio. La rapidità dell’adozione ha quindi limitato il periodo in cui coesistevano versioni con regole diverse.
Conclusioni
Il caso XRP Ledger mostra come l’intelligenza artificiale possa accelerare la scoperta di vulnerabilità rimaste inosservate per anni, modificando le condizioni di sicurezza anche di infrastrutture con una lunga storia operativa. Il vantaggio per la ricerca difensiva si accompagna alla possibilità che gli stessi progressi consentano agli attaccanti di individuare e sfruttare più rapidamente i difetti. Diventa quindi fondamentale intervenire tempestivamente: verificare la segnalazione, correggere il software e assicurare che la protezione raggiunga i sistemi in uso. Nel caso XRP Ledger, questo processo ha permesso di affrontare una minaccia all’integrità dell’offerta senza che emergessero evidenze di sfruttamento sulla rete pubblica. Con l’evoluzione degli strumenti di analisi, la sicurezza dipende sempre più dalla capacità di trasformare rapidamente una vulnerabilità scoperta in un rischio effettivamente contenuto.
