XRPL ha corretto una vulnerabilità nel motore dei pagamenti che, in condizioni molto specifiche, avrebbe potuto accreditare più XRP di quelli addebitati a chi acquistava asset da un book di ordini. Il problema è stato risolto con xrpld versione 3.4.1 e il resoconto non segnala prove di sfruttamento sulle reti pubbliche.
La segnalazione descrive anche una seconda falla nella funzione Batch, dedicata all’invio di più transazioni insieme. In questo caso il rischio riguardava la validazione del ledger; la correzione fixBatchV1_2 è stata attivata sulla mainnet il 9 ottobre 2026.
Come poteva verificarsi la creazione di XRP
La vulnerabilità più grave riguardava il modo in cui il motore dei pagamenti calcolava gli XRP necessari per concludere scambi distribuiti su più offerte di un order book. Se il valore combinato superava il massimo gestibile dal sistema, il calcolo poteva andare in overflow.
In quella circostanza, l’acquirente avrebbe potuto essere addebitato per una quantità di XRP inferiore a quella accreditata ai proprietari delle offerte. La differenza avrebbe quindi creato nuovi XRP spendibili, secondo quanto riportato dal team tecnico dopo aver riprodotto il difetto.
Non si trattava però di una condizione attivabile con un normale pagamento o una comune operazione di trading. Lo sfruttamento avrebbe richiesto un order book costruito appositamente, con centinaia di offerte a prezzi insolitamente elevati, seguito da una specifica transazione di pagamento.
Il ricercatore ha segnalato il problema attraverso il programma XRPL Bug Bounty il 22 settembre 2026. La versione 3.4.1, pubblicata il 25 settembre, aggiunge controlli contro l’overflow e rafforza le protezioni contro la creazione non autorizzata di XRP.
La seconda falla riguardava le transazioni Batch
Il secondo problema interessava Batch, la funzione che permette di inviare più transazioni come gruppo. Una transazione inclusa nel pacchetto poteva usare un campo strutturato in modo scorretto ed essere comunque accettata ed elaborata dal server.
Il rischio non era il superamento delle firme crittografiche né il furto diretto di fondi. Il punto critico era un altro: versioni diverse del software XRPL avrebbero potuto non concordare sulla validità della stessa transazione, ostacolando il consenso dei validator e interrompendo la validazione del ledger.
La funzione Batch non era ancora attiva sulla mainnet quando la vulnerabilità è stata individuata. Per questo il resoconto non indica account o fondi della rete principale coinvolti da questo difetto.
Correzione attivata e procedure di test riviste
Per intervenire sul problema Batch, sviluppatori e operatori dei validator hanno ritirato il supporto all’emendamento originale, così da azzerarne il percorso di attivazione durante la preparazione della correzione.
L’emendamento aggiornato, fixBatchV1_2, ha poi raccolto il supporto necessario ed è stato attivato sulla mainnet il 9 ottobre 2026, lo stesso giorno della pubblicazione del report. XRPL ha inoltre indicato un cambiamento nel processo di sicurezza: le vulnerabilità segnalate saranno ritestate sulle release candidate per verificare l’efficacia delle correzioni prima della distribuzione del software.
Cosa cambia per possessori e operatori
Il report non stabilisce che le falle abbiano causato perdite di fondi o un aumento effettivo dell’offerta di XRP. Inoltre, non invita i possessori di XRP a spostare gli asset o a cambiare le chiavi private.
L’aggiornamento riguarda soprattutto chi gestisce server XRPL: usare versioni compatibili è necessario per restare sincronizzati con la rete. Per gli utenti finali, il dato essenziale è che la falla nel motore dei pagamenti risulta corretta e non ci sono prove di un suo uso sulle reti pubbliche.
FAQ
Il bug ha creato davvero nuovi XRP?
Il report non accerta la creazione effettiva di nuovi XRP. Descrive una vulnerabilità che avrebbe potuto generarne di spendibili, ma non riporta prove di sfruttamento su alcuna rete pubblica né un aumento accertato dell’offerta.
Era possibile rubare XRP aggirando le firme?
No. Per il difetto Batch, il report esclude la possibilità di bypassare le firme delle transazioni o di sottrarre fondi direttamente.
Chi deve intervenire dopo la correzione?
La versione xrpld 3.4.1 è rilevante per gli operatori dei server XRPL. Il report non richiede ai semplici possessori di XRP di trasferire fondi o modificare le proprie chiavi private.
Considerazioni finali
La parte più rilevante di questo caso non è soltanto la gravità teorica del bug, ma il fatto che richiedesse una sequenza molto costruita e che non emergano prove di sfruttamento pubblico. Questo non riduce l’importanza della correzione: un errore capace di alterare il rapporto fra XRP addebitati e XRP accreditati tocca direttamente una delle garanzie fondamentali di un ledger.
È positiva anche la scelta di fermare e correggere il percorso di Batch prima della sua attivazione sulla mainnet. La misura concreta che conta è il doppio intervento già indicato: xrpld 3.4.1 per il motore dei pagamenti e fixBatchV1_2 per la funzione Batch.