Een overflow-bug in de XRP Ledger had met een enkele transactie meer XRP kunnen creëren dan de volledige bestaande voorraad. RippleX, de ontwikkeltak van Ripple, en de XRPL Foundation hebben de fout, die vermoedelijk al sinds 2015 bestond, eind september 2026 openbaar gemaakt en gedicht. Er zijn geen aanwijzingen dat de bug ooit is uitgebuit.

Een voorraadlimiet die gebroken had kunnen worden

De XRP Ledger is de gedecentraliseerde blockchain achter XRP. Hij verwerkt betalingen en handel via een ingebouwd orderboek, en de betalingsengine is het onderdeel dat betalingen afzet tegen de daar geplaatste aanbiedingen. De totale voorraad stond bij de lancering op 100 miljard XRP. Er is geen mining en geen inflatie; alleen verbrande transactiekosten verminderen de voorraad lichtjes. Die vaste limiet rust op een invariant op ledgerniveau — de regel dat geen enkele transactie XRP mag creëren — en precies die garantie ondergroef de overflow-bug.

Versie 3.4.1 van de xrpld-serversoftware werd op 25 september uitgebracht, en het openbaarmakingsrapport volgde 14 dagen later. Daarvoor had al meer dan 80% van de validators op de Default Unique Node List (UNL) geüpgradeerd. De bug trof xrpld 3.4.0 en alle eerdere versies. Veria Labs, dat de bug meldde, berekent dat een enkele exploittransactie ongeveer 18 biljoen XRP had kunnen creëren.

Hoe een bug XRP uit het niets had kunnen creëren

De betalingsengine telde de bedragen op van alle aanbiedingen die een betaling in het orderboek verbruikte, met behulp van 64-bits integeroptelling zonder overflowcontrole. Als de som groot genoeg werd, sloeg de waarde om naar een klein getal. Elke eigenaar van een aanbieding de volledige betaling hebben ontvangen, terwijl het ledger de koper slechts het omgeslagen bedrag afschreef. Het verschil zou als nieuwe XRP zijn ontstaan.

Twee beveiligingen hadden dit moeten voorkomen. Maar de invariant dat geen enkele transactie XRP mag creëren gebruikte dezelfde overlopende rekenkunde. Bovendien activeert de saldocolcheck per account pas boven de totale voorraad, terwijl de gecreëerde XRP op vele accounts zou zijn terechtgekomen.

Voor de aanval zou een aanvaller honderden accounts hebben opgezet, die elk een piepklein fractie van een token aanboden voor een enorme hoeveelheid XRP. Eén betaling zou vervolgens alle aanbiedingen verbruiken, en elk betrokken account kon van de aanvaller zijn. De kosten kwamen uit op enkele honderden XRP aan terugvorderbare reserves plus kosten, dus de aanvaller had geen groot startsaldo nodig.

Toch kon niemand de overflow per ongeluk activeren. Normale betalingen komen nooit bij het vereiste bedrag, omdat geen enkele echte handelaar dergelijke prijzen zou quoten. Het rapport stelt ook dat er geen aanwijzingen zijn voor uitbuiting op een publiek netwerk. Cayden Liao van Veria Labs zegt dat de exploit twee bugs ketent die elk op zichzelf als lage ernst zouden scoren, en hij vermoedt dat daarom niemand de fout eerder vond.

Gemeld via het bug bounty-programma

Cayden Liao en Veria AI meldden de kwetsbaarheid op 22 september via het bug bounty-programma van het netwerk, aanvankelijk beoordeeld als "Major". RippleX reproduceerde de aanval en verhoogde de beoordeling naar "kritiek", en ontwikkelde vervolgens de fix in het geheim. Een dag later belandde de fix in de releasebranch voor versie 3.4.1 en verscheen hij in release candidate 3.4.1-rc1. Sindsdien controleert de betalingsengine op een overflow bij het optellen van de aanbiedbedragen; als de som overloopt, mislukt dat deel van de betaling.

Alleen Veria Labs heeft details gegeven over de ontdekking zelf. Het bedrijf zegt dat een AI-agent de bug vond en een werkende exploit bouwde. Daarentegen noemt het openbaarmakingsrapport alleen Liao en Veria AI als melders. Het cijfer van ongeveer 18 biljoen XRP komt uit Liao's berekening en zou gelijkstaan aan 184 keer de totale voorraad. Veria zegt ook de maximale bounty van 250.000 USD te hebben ontvangen, al wordt in het rapport geen bedrag genoemd. Dergelijke programma's zijn een standaardmechanisme op grote blockchainnetwerken om verantwoorde openbaarmaking te belonen.

Volgens het rapport zat de bug waarschijnlijk al in de code sinds de ontwikkeling van de betalingsengine in 2015 en bleef hij ongeveer decennium onopgemerkt. Het geval past in de bredere trend van door AI ondersteund zoeken naar kwetsbaarheden, die fouten sneller blootlegt — een perspectief waarin RippleX-ontwikkelaars zich ook vinden.

Een fix zonder amendment

Regelwijzigingen op de XRP Ledger gaan normaal gesproken via zogenaamde amendments, die steun vereisen van meer dan 80% van de vertrouwde validators over een periode van twee weken. Deze fix trad echter onmiddellijk in werking naarmate elke afzonderlijke server upgradde. Het rapport noemt het de eerste bewuste wijziging van deze soort in de transactieverwerking sinds de komst van amendments. Op de releasedag draaide al meer dan 80% van de Default UNL-validators versie 3.4.1 of nieuwer.

RippleX rechtvaardigde de stap met het tijdsvenster: een reguliere open-source-release zou aanvallenden weken voor de fix inging hebben laten zien waar de bug zat. Leden van de XRPL Foundation, RippleX en XRPL-validators waren daarom vooraf overeengekomen dat het risico een snelle aanpak rechtvaardigde. Naar hun mening rechtvaardigen alleen de ernstigste bugs deze stap, terwijl alle andere wijzigingen nog steeds via amendments gaan.

"AI has changed things. You can't sneak a critical bug patch into a routine public release process, it'll get spotted and reverse-engineered immediately." — Mayukha Vadari, RippleX

Toch publiceerde het team de 3.4.1-broncode op GitHub pas zo'n twee weken na de binaire bestanden. Justin Bons, oprichter van Cyber Capital, bekritiseerde op X dat XRP twee weken op closed-sourcecode had gedraaid. Een stille patch met vertraagde openbaarmaking is gebruikelijke praktijk in softwarebeveiliging, maar blijft omstreden in een gedecentraliseerd netwerk met governanceambities.

Een tweede bug in de batchfunctie

Versie 3.4.1 dichtte ook een tweede bug, in de batchfunctie (XLS-56), die xrpld 3.3.0 en 3.4.0 trof. Een batch bevat tot acht binnenTransacties, en volgens de specificatie moet elke ervan in een veld genaamd RawTransaction staan. De server controleerde dit niet. Daardoor kon een permanent misvormde ledgerentry ontstaan die indexeerders, explorers en SDK's zou kunnen verstoren.

Een consensusvariant was ernstiger. Met gemengde softwareversies had een vervaardigde transactie de validatie kunnen stilleggen ten koste van één transactiekost, al zou een aanvaller on-chain niets hebben gewonnen. Mainnet ondervond geen impact, aangezien BatchV1_1 daar niet actief was.

De bevinding kwam eerst aan het licht tijdens de Sherlock Attackathon, aanvankelijk beoordeeld als "laag". Op 18 september bevestigde Denis Angell van de XRPL Foundation dat een eerdere fix onvolledig was. Vier dagen later identificeerde Mayukha Vadari het consensusrisico. Ripple en validatoroperator Vet trokken vervolgens hun stemmen voor BatchV1_1 in, een amendment dat oorspronkelijk op 29 september zou activeren. De release startte de activering van twee weken van fixBatchV1_2, en sinds 9 oktober zijn beide amendments actief op mainnet.

Verscherpt reviewproces

RippleX wijzigt daarom zijn reviewproces. Voortaan gaat elke als gefixt gemarkeerde securitybevinding door een nieuwe test tegen de release candidate, en het team sluit deze pas af zodra een test de oorspronkelijke bug reproduceert en de candidate slaagt. Tot de aanvullende beveiligingen in het rapport behoren publieke attackathons en door AI ondersteunde red teaming.

Oudere versies gelden als "amendment-blocked" en blijven niet langer gesynchroniseerd. Operators moeten hun servers dus upgraden naar xrpld 3.4.1 of nieuwer. Hoe de XRP Ledger zijn volgende kritieke bevinding afhandelt — via dit gereserveerde snelle spoor of via een regulier amendment — zal laten zien of de aanpak de uitzondering blijft als de beschrijving die het rapport ervan geeft.

Bron: XRPL vulnerability disclosure report via Crypto Valley Journal