Ein Overflow-Bug im XRP Ledger hätte es einer einzelnen Transaktion ermöglichen können, mehr XRP zu erzeugen, als die gesamte existierende Menge ausmacht. RippleX, der Entwicklungszweig von Ripple, und die XRPL Foundation haben den Fehler, der vermutlich seit 2015 bestand, Ende September 2026 offengelegt und behoben. Es gibt keine Hinweise darauf, dass er jemals ausgenutzt wurde.

Ein Liefergrenzen-Deckel, der hätte gebrochen werden können

Das XRP Ledger ist die dezentrale Blockchain hinter XRP. Es verarbeitet Zahlungen und Handel über ein eingebautes Orderbuch, und die Payment-Engine ist die Komponente, die Zahlungen gegen die dort platzierten Offers abgleicht. Die Gesamtmenge lag beim Start bei 100 Milliarden XRP. Es gibt kein Mining und keine Inflation; nur verbrannte Transaktionsgebühren verringern die Menge leicht. Diese feste Obergrenze beruht auf einer Invariante auf Ledger-Ebene – der Regel, dass keine Transaktion XRP erzeugen darf – und genau diese Garantie wurde durch den Overflow-Bug untergraben.

Version 3.4.1 der xrpld-Server-Software erschien am 25. September, der Offenlegungsbericht folgte 14 Tage später. Zu diesem Zeitpunkt hatten bereits mehr als 80 % der Validatoren auf der Default Unique Node List (UNL) aktualisiert. Der Bug betraf xrpld 3.4.0 und alle früheren Versionen. Veria Labs, das den Bug meldete, berechnet, dass eine einzelne Exploit-Transaktion rund 18 Billionen XRP erzeugt hätte.

Wie ein Overflow XRP aus dem Nichts hätte erzeugen können

Die Payment-Engine summierte die Beträge aller Offers, die eine Zahlung im Orderbuch konsumierte, und verwendete dabei eine 64-Bit-Integer-Addition ohne Overflow-Prüfung. Wuchs die Summe groß genug, lief der Wert auf eine kleine Zahl zurück. Jeder Offer-Inhaber hätte die volle Zahlung erhalten, während das Ledger dem Käufer nur die umgeschlagene Summe belastete. Die Differenz wäre als neues XRP entstanden.

Zwei Schutzmechanismen hätten dies verhindern sollen. Allerdings verwendete die Invariante, die besagt, dass keine Transaktion XRP erzeugen darf, dieselbe überlaufende Arithmetik. Zudem greift die Kontostandsprüfung pro Konto erst oberhalb der Gesamtmenge, während das erzeugte XRP auf viele Konten verteilt worden wäre.\nFür den Angriff hätte ein Akteur hunderte Konten eingerichtet, die jeweils einen winzigen Bruchteil eines Tokens für eine enorme Menge an XRP anboten. Eine einzige Zahlung hätte dann alle Offers konsumiert, und jedes beteiligte Konto könnte dem Angreifer gehören. Die Kosten beliefen sich auf einige hundert XRP in wieder einlösbaren Reserven plus Gebühren, sodass der Angreifer kein großes Startguthaben benötigte.

Dennoch hätte niemand den Overflow versehentlich auslösen können. Normale Zahlungen erreichen die erforderliche Summe nie, da kein echter Händler solche Preise notieren würde. Der Bericht stellt außerdem fest, dass es keine Hinweise auf eine Ausnutzung in einem öffentlichen Netzwerk gibt. Cayden Liao von Veria Labs erklärt, dass der Exploit zwei Bugs kombiniert, die jeweils allein nur eine niedrige Schwere aufweisen würden; er vermutet, dass deshalb niemand den Fehler früher entdeckte.

Gemeldet über das Bug-Bounty-Programm

Cayden Liao und Veria AI meldeten die Schwachstelle am 22. September über das Bug-Bounty-Programm des Netzwerks und stuften sie zunächst als „Major“ ein. RippleX reproduzierte den Angriff, stufte die Bewertung auf „critical“ herauf und entwickelte den Fix anschließend privat. Einen Tag später landete der Fix im Release-Branch für Version 3.4.1 und erschien im Release-Kandidaten 3.4.1-rc1. Seither prüft die Payment-Engine bei der Summierung der Offer-Beträge auf einen Overflow; läuft die Summe über, schlägt dieser Teil der Zahlung fehl.

Nur Veria Labs hat Details zur Entdeckung selbst bereitgestellt. Dem Unternehmen zufolge fand ein KI-Agent den Bug und baute einen funktionierenden Exploit. Der Offenlegungsbericht nennt hingegen nur Liao und Veria AI als Melder. Die Zahl von rund 18 Billionen XRP stammt aus Liaos Berechnung und entspräche dem 184-Fachen der Gesamtmenge. Veria gibt außerdem an, die maximale Prämie von 250.000 USD erhalten zu haben; der Bericht nennt jedoch keinen Betrag. Solche Programme sind ein gängiger Mechanismus großer Blockchain-Netzwerke zur Belohnung verantwortungsvoller Offenlegung.

Laut Bericht bestand der Bug vermutlich seit der Entwicklung der Payment-Engine im Jahr 2015 im Code und blieb rund ein Jahrzehnt unentdeckt. Der Fall fügt sich in den breiteren Trend der KI-gestützten Schwachstellensuche ein, die Fehler schneller aufdeckt – eine Sichtweise, die auch RippleX-Entwickler teilen.

Ein Fix ohne Amendment

Regeländerungen im XRP Ledger laufen normalerweise über sogenannte Amendments, die die Unterstützung von mehr als 80 % der vertrauenswürdigen Validatoren über einen Zeitraum von zwei Wochen erfordern. Dieser Fix trat jedoch sofort in Kraft, sobald jeder einzelne Server aktualisiert wurde. Der Bericht bezeichnet dies als die erste absichtliche Änderung dieser Art an der Transaktionsverarbeitung seit Einführung der Amendments. Am Releasetag liefen bereits mehr als 80 % der Default-UNL-Validatoren mit Version 3.4.1 oder höher.

RippleX begründete den Schritt mit dem Zeitfenster: Ein reguläres Open-Source-Release hätte Angreifern Wochen vor dem Wirksamwerden des Fix gezeigt, wo der Bug saß. Mitglieder der XRPL Foundation, RippleX und XRPLValidatoren einigten sich daher im Voraus, dass das Risiko ein schnelles Vorgehen rechtfertigte. Ihrer Ansicht nach rechtfertigen nur die schwerwiegendsten Bugs diesen Schritt, während alle anderen Änderungen weiterhin über Amendments laufen.

„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

Dennoch veröffentlichte das Team den 3.4.1-Quellcode auf GitHub erst rund zwei Wochen nach den Binaries. Justin Bons, Gründer von Cyber Capital, kritisierte auf X, dass XRP zwei Wochen lang auf Closed-Source-Code lief. Ein stiller Patch mit verzögerter Offenlegung ist in der Softwaresicherheit übliche Praxis, bleibt aber in einem dezentralen Netzwerk mit Governance-Anspruch umstritten.

Ein zweiter Bug in der Batch-Funktion

Version 3.4.1 schloss zudem einen zweiten Bug in der Batch-Funktion (XLS-56), der xrpld 3.3.0 und 3.4.0 betraf. Ein Batch enthält bis zu acht innere Transaktionen, die gemäß Spezifikation jeweils in einem Feld namens RawTransaction liegen müssen. Der Server prüfte dies nicht. Dadurch könnte ein dauerhaft fehlerhafter Ledger-Eintrag entstehen, der Indexer, Explorer und SDKs gestört hätte.

Eine Konsens-Variante war schwerwiegender. Bei gemischten Software-Versionen hätte eine manipulierte Transaktion die Validierung zum Preis einer Transaktionsgebühr anhalten können, wobei ein Angreifer on-chain nichts gewonnen hätte. Das Mainnet blieb jedoch verschont, da BatchV1_1 dort nicht aktiv war.

Der Befund tauchte erstmals beim Sherlock Attackathon auf und wurde zunächst als „low“ eingestuft. Am 18. September bestätigte Denis Angell von der XRPL Foundation, dass ein früherer Fix unvollständig war. Vier Tage später identifizierte Mayukha Vadari das Konsensrisiko. Ripple und der Validator-Betreiber Vet zogen daraufhin ihre Stimmen für BatchV1_1 zurück, ein Amendment, das ursprünglich am 29. September aktiviert werden sollte. Das Release startete die zweiwöchige Aktivierung von fixBatchV1_2, und seit dem 9. Oktober sind beide Amendments im Mainnet aktiv.

Verschärfter Review-Prozess

RippleX ändert daher seinen Review-Prozess. Künftig durchläuft jeder als behoben markierte Sicherheitsbefund einen neuen Test gegen den Release-Kandidaten, und das Team schließt ihn erst, wenn ein Test den ursprünglichen Bug reproduziert und der Kandidat die Prüfung besteht. Zu den weiteren zusätzlichen Schutzmaßnahmen im Bericht zählen öffentliche Attackathons und KI-gestütztes Red Teaming.

Ältere Versionen gelten als „amendment-blocked“ und bleiben nicht mehr synchron. Betreiber müssen ihre Server daher auf xrpld 3.4.1 oder höher aktualisieren. Wie das Netzwerk seinen nächsten kritischen Befund behandelt – über diesen reservierten Schnellweg oder ein reguläres Amendment –, wird zeigen, ob dieses Vorgehen die Ausnahme bleibt, als die es der Bericht darstellt.

Quelle: XRPL vulnerability disclosure report via Crypto Valley Journal