4 juni 2026
Een beveiligingslek in een voorgestelde upgrade van het XRP Ledger (XRPL) had ongeautoriseerde transacties kunnen mogelijk maken, maar gelukkig hebben onderzoekers het probleem tijdig gesignaleerd voordat het de hoofdnetwerk kon bereiken. De XRPL Foundation maakte op 26 februari bekend dat de kwetsbaarheid zich bevond in de voorgestelde ‘Batch’-wijziging, een functie die gebruikers in staat stelt om meerdere acties samen te voegen tot één enkele atomische transactie.
De beveiligingsonderzoeker Pranamya Keshkamat, samen met het autonome statische analysetool van Cantina AI, Apex, heeft dit probleem op 19 februari gerapporteerd aan de foundation. Had de wijziging met de aanwezige bug geactiveerd, dan had een aanvaller interne transacties kunnen uitvoeren alsof ze geautoriseerd waren door een ander account, zonder toegang tot die gebruiker’s privésleutels.
Dit had geleid tot ongeautoriseerde geldtransfers en wijzigingen in de ledger-instellingen onder het account van het slachtoffer, zelfs als het slachtoffer de transactie niet had ondertekend. Deze onthulling komt op een cruciaal moment voor XRPL, dat zich richt op toepassingen zoals tokenisatie en andere compliance-gevoelige activiteiten, waarbij waargenomen veiligheid en betrouwbaarheid centraal staan voor institutionele adoptie.
De voorgestelde Batch-wijziging zou de autorisatie op het XRP Ledger wijzigen door het mogelijk te maken om meerdere ‘interne’ transacties samen te voegen in één enkele ‘externe’ Batch-transactie. Dit zorgt ervoor dat alle stappen samen succesvol zijn of falen. Deze atomische structuur kan het uitvoeringsrisico voor ontwikkelaars die multistap-operaties uitvoeren, verminderen en creëert tegelijkertijd een nieuwe autorisatiegrens.
In de Batch-ontwerpstructuur zijn interne transacties opzettelijk niet ondertekend. Autoriteit wordt in plaats daarvan gedelegeerd aan een lijst van batch-ondertekenaars die aan de externe transactie zijn gekoppeld, waardoor de validatiecode voor de ondertekenaar een kritische controlepunt wordt. Als deze controles falen, kan de ledger ongeautoriseerde acties als geldig beschouwen.
De onthulling stelde dat de bug voortkwam uit een lusfout in de functie die batch-ondertekenaars valideert. Wanneer de code een ondertekenaar tegenkwam wiens account nog niet bestond op de ledger en wiens ondertekeningssleutel bij datzelfde account overeenkwam, retourneerde het onmiddellijk succes en stopte het met het controleren van de rest van de ondertekenaarslijst. Deze situatie was gevaarlijker in een batchesysteem dan het lijkt. Een batch kan stappen omvatten die accounts creëren binnen dezelfde atomische sequentie, wat betekent dat de aanwezigheid van een account op het moment van validatie deel uitmaakt van de autorisatiegrens.
Een aanvaller had een geldige ondertekenaar-invoer kunnen inserten voor een nog niet aangemaakt account dat onder zijn controle was, wat de vroegtijdige-succesconditie had geactiveerd en de validatie van een vervalste ondertekenaar-entry die beweerde een slachtoffer-account te autoriseren, had kunnen omzeilen. Had Batch geactiveerd voordat de bug werd ontdekt, dan zouden de gevolgen ernstig kunnen zijn geweest. De Foundation merkte op dat een aanvaller interne Betalingen had kunnen uitvoeren die slachtoffers’ accounts tot de reserve zouden legen. Dezelfde bug had ook ongeautoriseerde account-level operaties mogelijk gemaakt, waaronder AccountSet, TrustSet en mogelijk zelfs AccountDelete.
De kwetsbaarheid had het beveiligingsimago van XRPL kunnen schaden op een gevoelig moment voor het netwerk, dat zich agressief richt op de tokenisatie van echte activa (RWA) en institutionele DeFi. Gegevens van DeFiLlama tonen aan dat XRPL ongeveer $50 miljoen aan totale DeFi-waarden op het platform heeft, met bijna $2 miljard aan RWA-activa. In de cryptomarkten vormen autorisatiefouten vaak de perceptie, lang nadat het onderliggende technische probleem is opgelost. Voor een ledger die zich positioneert als infrastructuur voor gereguleerde financiën, zou een dergelijk incident bredere implicaties hebben gehad.
Dit is bijzonder van belang, gezien het feit dat XRPL recentelijk een nieuwe set institutioneel gerichte functies heeft geïntroduceerd, inclusief Toegestane Domeinen en DEX’s. Deze functies zijn ontworpen om afgeschermde handelsplaatsen te creëren waar alleen goedgekeurde deelnemers orders kunnen plaatsen en aannemen. Dit model is gericht op instellingen die blockchain-gebaseerde afstemming willen zonder open toegang voor alle tegenpartijen. Een beveiligingsprobleem zou dat boodschap ondermijnen; een netwerk kan niet eenvoudig worden gemarkeerd of compliancegericht zijn in on-chain omgevingen wanneer een voorgestelde transactie-upgrade het risico op ongeautoriseerde acties met zich meebrengt.
De reactie van XRPL vond snel plaats via governance- en softwarekanalen. De unieke Node List (UNL) van vertrouwde validators werd ingelicht en aangespoord om ‘Nee’ te stemmen op de Batch-wijziging. Op 23 februari publiceerde XRPL rippled 3.1.1, een noodrelease die zowel Batch als fixBatchInnerSigs als niet-ondersteund markeert. Dit voorkwam dat de wijzigingen validatorstemmen ontvingen of geactiveerd werden op het netwerk.
De release was bedoeld als onmiddellijke containment, niet als een volledige oplossing. De onthulling gaf expliciet aan dat de 3.1.1-release de onderliggende logica fix niet omvatte. XRPL heeft ook een devnet-reset gepland voor 3 maart 2026, samenvallend met de wijziging van 3.1.1. Deze reset geldt uitsluitend voor Devnet, niet voor het hoofdnet, maar toont aan in welke mate de netwerkoperators zich hebben ingespannen om te voorkomen dat het probleem actieve wijzigingspaden zou beïnvloeden. Een gecorrigeerde vervangende wijziging, BatchV1_1, is al geïmplementeerd en onderhevig aan beoordeling, zonder dat er een releasedatum is vastgesteld.
Volgens de onthulling verwijdert de volledige fix de vroege exit, voegt extra autorisatiebeveiligingen toe en verkleint de reikwijdte van de ondertekeningscontrole. Het rapport schetst ook een bredere beveiligingsroutekaart, inclusief meer gestandaardiseerde AI-ondersteunde audits, uitgebreide statische analysecontroles voor gevaarlijke lusuitgangen en een herziening van vergelijkbare patronen elders in de codebasis.
Voor XRPL zal de uitkomst van februari worden beschouwd als een governance-succes. De bug werd ontdekt voordat deze geactiveerd kon worden. Validators hebben gecoördineerd, een noodrelease heeft het amendementpad geblokkeerd en er zijn geen fondsen verloren gegaan. Maar het verhaal eindigt hier niet.
BatchV1_1 zal nu op twee niveaus worden beoordeeld. Ten eerste op technisch gebied, of het de voordelen van atomische transactie-bundeling levert zonder het autorisatierisico opnieuw te openen. Ten tweede op procedureel niveau, of de governance- en engineeringsystemen van XRPL kunnen meegroeien met een uitbreidend functieaanbod gericht op institutionele adoptie. Dat is de echte achtergrond van deze bijna-misser. XRPL probeert uit te groeien tot een breder financieel platform dat afgeschermde handelsgenen, permissiegebaseerde omgevingen en geavanceerdere transactie-logica kan hosten, terwijl het ook builders probeert aan te trekken met ecosystemenkapitaal en productbreedte. Hoe ambitieus die routekaart ook wordt, des te belangrijker worden ogenschijnlijk ‘saaiere’ zaken zoals ondertekenvalidatie en loopgedrag.
In dit geval functioneerden de remmen, maar de volgende uitdaging is om te bewijzen dat het systeem opnieuw kan versnellen zonder dat veiligheidsmarge te verliezen.
Wat was de aard van de kwetsbaarheid in de Batch-wijziging van XRPL?
De kwetsbaarheid lag in de autorisatiefunctie van de Batch-wijziging, waarmee een aanvaller ongeautoriseerde transacties kon uitvoeren door gebruik te maken van een bug die betrokken was bij het valideren van batch-ondertekenaars.
Hoe heeft XRPL gereageerd op deze ontdekking?
XRPL heeft snel gereageerd door validators te adviseren om tegen de Batch-wijziging te stemmen en een noodrelease uit te brengen die de wijziging van de netwerktechnologie blokkeerde voordat deze geactiveerd kon worden.
Wat zijn de implicaties van deze kwetsbaarheid voor de toekomst van XRPL?
Deze situatie benadrukt het belang van robuuste governance- en engineeringprocessen binnen XRPL, vooral nu het netwerk zich richt op institutional adoption en meer geavanceerde functies wil implementeren, waar nauwkeurige autorisatie cruciaal is.
Bitcoin (BTC)
Ethereum (ETH)
XRP (XRP)
