De XRP Ledger Foundation heeft uitgelegd hoe ontwikkelaars en validators reageerden op een kwetsbaarheid waarmee een aanvaller via een opzettelijk geconstrueerde betaling spendable XRP had kunnen creëren. De Foundation stelde dat er via de fout geen XRP is gecreëerd en dat er geen bewijs is dat deze op een publiek netwerk is uitgebuit.

De verklaring van 11 oktober richtte zich op de reactie in plaats van op herhaling van de werking van de kwetsbaarheid. Een eerdere uitleg van de bug is te vinden in het rapport van Coindoo. Het technische openbaarmakingsrapport van de Foundation staat op de XRP Ledger-website.

Publieke ledgerdata ondersteunt de supply-claim

XRP lanceerde met een vaste supply van 100 miljard, en transactiekosten worden in de loop van de tijd vernietigd. De Foundation zei dat er momenteel ongeveer 99,986 miljard XRP bestaan.

Het technische openbaarmakingsrapport meldde dat het team geen bewijs vond dat de kwetsbaarheid op een publiek netwerk was uitgebuit. De claim kan worden getoetst aan de gevalideerde transactiegeschiedenis en accountsaldi van de XRP Ledger, die publiek beschikbaar zijn voor onafhankelijke controle via explorers en andere gegevensdiensten.

"Je hoeft ons hierin niet te vertrou", schreef de Foundation. Nieuwe XRP zou in accountsaldi verschijnen, omdat er op de XRP Ledger geen verborgen saldi-ruimte bestaat. De Foundation zei de ledger continu te monitoren en de supply gedurende de hele geschiedenis van het netwerk te hebben geverifieerd, terwijl ook andere communityleden eigen controles hebben uitgevoerd.

Publieke registraties kunnen niet elk privégesprek vóór de openbaarmaking onthullen of de intentie achter een aanval vaststellen die nooit naar het netwerk is verzonden. Ze kunnen wel gevalideerde transacties, zichtbare saldoveranderingen en de geregistreerde supply tonen. Die informatie biedt een basis om claims tegen te gaan dat grote hoeveelheden XRP heimelijk geslagen en verborgen op het netwerk zouden zijn achtergelaten.

Waarom de fix vóór de technische openbaarmaking werd uitgebracht

Onder het standaard governance-proces van de XRP Ledger worden wijzigingen in transactieregels via amendments ingevoerd. Validators moeten langer dan twee weken meer dan 80% steun behouden voordat een amendment actief wordt. Dit proces geeft operators tijd om te upgraden en zorgt ervoor dat het netwerk de wijziging op hetzelfde moment doorvoert.

De overflow-fix volgde een andere route omdat de kwetsbaarheid als actief risico werd beschouwd. Volgens het openbaarmakingsrapport zou het publiceren van code die de precieze fout onthulde, voordat oudere servers waren beveiligd, het aanvalspad gemakkelijker identificeerbaar hebben gemaakt. Versie 3.4.1 paste de beveiliging daarom toe zodra afzonderlijke servers upgraden, in plaats van te wachten op het normale publieke amendment-proces.

De Foundation vatte haar uitleg samen in een X-post:

The recent XRP Ledger security fix raised a lot of questions and some misconceptions. Let’s clear them up.

1. Was any XRP created?

No. XRP’s supply was fixed at 100 billion when the XRP Ledger launched, and no transaction is allowed to create more. This bug was a way around that rule, and 3.4.1 fixed it 2 weeks ago.

You don’t need to trust us on this. All ledger data is public, and explorers and data sites read it every day. New XRP would show up in account balances for everyone to see. There is no hidden place for XRP on the XRP Ledger, every balance is public.

We monitor the XRP Ledger 24/7 and have verified the supply throughout the history of the ledger. Others in the community verified this too, and anyone can do the same.

Transaction fees are destroyed, so the supply is deflationary. About 99.986 billion XRP exist today.

1. How did this go unnoticed, and what’s nextn>
   No normal payment comes anywhere near triggering it. It took hundreds of deliberately constructed operations.

AI makes bugs like this faster to find, for the bad guys and the good guys.

Together with RippleX and the community, we will ensure the XRP Ledger is protected against such vulnerabilities. This means radically applying Formal Verification and AI adversarial testing, collaborating closely with security researchers, and strengthening the bug bounty program.

You’ll hear a lot more about this as we progress.

1. XRP Ledger decentralization at the core of this.

A public fix shows attackers where the bug is, and AI makes that fast. With a normal amendment vote, the fix would have been public for weeks before it took effect, risking network security.

As a reaction to this, the XRPL community came together, and among them the XRP Ledger Foundation, RippleX, core devs and validators formed a social consensus and agreed on a path forward that involves shipping the fix directly. Patching a live network is never trivial, so the plan was also designed to minimize disruption for everyone running on it.

We shared the build with the default UNL validators, using the contact details each one publishes in its xrp-ledger.toml file. Public binaries followed the same day, September 25.

No single party could make that call alone. Every validator and node operator chooses what software to run, and 3.4.1 only became required through a normal amendment vote with more than 80% validator support for two weeks. Protocol changes still go through amendments.

Big thanks to Cayden Liao and Veria AI for finding and reporting this responsibly, to the XRPL core developers for building and testing the fix, and to every node operator who upgraded so quickly, especially the validators.

Full report:

— XRP Ledger Foundation (@XRPLF) October 11, 2026

De Foundation omschreef de directe softwarerelease als een uitzonderlijke reactie in plaats van een vervanging van het normale governance-proces. Haar rapport stelde dat dit de eerste opzettelijke directe wijziging van de transactieverwerking was sinds het amendmentsysteem ruim tien jaar geleden werd ingevoerd. Toekomstige protocolwijzigingen zullen volgens het rapport blijven vereisen dat amendments door validators worden ondersteund.

Validators behielden de controle over de software-installatie

De Foundation zei de gepatchte build te hebben gedeeld met operators van default-UNL-validators voordat op 25 september publieke binaries werden uitgebracht. Die operators beslisten zelf of ze de nieuwe versie zouden draaien. Noch de Foundation noch RippleX kon een upgrade afdwingen op onafhankelijk beheerde servers.

Dit creëerde een korte periode waarin gepatchte en ongepatchte servers verschillende regels volgden voor het gespecialiseerde betalingspad. Volgens het XRPL-rapport had een uitbuitingspoging in die periode kunnen zorgen dat de versies met elkaar in conflict zouden komen en mogelijk de validatie verstoren. Het team oordeelde dat risico te verkiezen boven het openlaten van een mogelijk onomkeerbare inflatieaanval tijdens een langere publieke activeringsperiode.

De reactie werd gecoördineerd via de XRP Ledger Foundation, RippleX, kernontwikkelaars en validators, maar geen enkele organisatie kon de beslissing alleen nemen. Elke validator- en node-operator kiest zelf welke software wordt gedraaid, terwijl het amendmentsysteem het mechanisme om protocolwijzigingen verplicht te stellen.

Wat de openbaarmaking betekent voor gebruikers en operators

Het rapport gaf XRP-houders geen instructie om fondsen te verplaatsen of wallets te vervangen. Voor node-operators zei XRPL dat servers xrpld versie 3.4.1 of nieuwer moeten draaien om gesynchroniseerd te blijven met het netwerk. In de praktijk betrof de genoemde remediering dus de software die de ledger-infrastructuur beheert, en geen wallet-actie van XRP-houders.

De Foundation zei verder dat een normale betaling de kwetsbaarheid nowhere near kan activeren. Uitbuiting vereiste honderden opzettelijk geconstrueerde operaties. Kunstmatige intelligentie kan volgens de Foundation kwetsbaarheden sneller vindbaar maken, voor aanvallers én verdedigers.

Geplande beveiligingsmaatregelen

De Foundation zei het gebruik van formele verificatie en AI-adversarial testing te willen uitbreiden, nauwer te willen samenwerken met externe security-onderzoekers en haar bug-bountyprogramma te willen versterken. Deze maatregelen kunnen niet garanderen dat er zich geen nieuw kritiek probleem voordoet, maar ze zijn bedoeld om de kans te vergroten dat kwetsbaarheden worden gevonden vóór een productierelease.

Het openbaarmakingsrapport beschrijft ook een release-controlmaatregel. Beveiligingsbevindingen die als gefixeerd zijn gemarkeerd, moeten opnieuw worden getest tegen de release candidate met de patch, en het oorspronkelijk gerapporteerde probleem moet worden gereproduceerd voordat de bevinding wordt gesloten. Dat proces geeft externe onderzoekers een gedefinieerde standaard waaraan latere releases kunnen worden getoetst.

De kwetsbaarheid legde een ernstige zwakte bloot in een regel die bedoeld is om de vaste supply van XRP te bewaren. De reactie heeft nu een eigen publiek spoor nagelaten: een bug-bountyrapport, een versnelde validator-upgrade, een latere technische openbaarmaking en toezeggingen om de beveiligingspraktijken te versterken. In hoeverre die toezeggingen een vast onderdeel worden van toekomstige releaseprocedures, bepaalt de betekenis van het incident op de langere termijn.

Dit artikel is uitsluitend ter informatie en vormt geen beleggingsadvies. Details over softwarereleases en beveiligingsopenbaarmakingen kunnen wijzigen naarmate meer technische informatie beschikbaar komt.

Bron: Coindoo.