Ein XRP-Ledger-Bug hätte mit einer einzigen Transaktion mehr XRP erzeugen können, als insgesamt existieren. RippleX hat den vermutlich seit 2015 bestehenden Überlauf-Fehler Ende September 2026 behoben, Hinweise auf eine Ausnutzung gibt es keine.
Das XRP Ledger ist die dezentrale Blockchain hinter XRP, die Zahlungen und den Handel über ein integriertes Orderbuch abwickelt. Die Payment Engine ist jener Teil des Codes, der Zahlungen gegen die dort hinterlegten Angebote abgleicht. Zum Start betrug die Gesamtmenge 100 Milliarden XRP. Mining und Inflation gibt es nicht, lediglich verbrannte Transaktionsgebühren senken den Bestand leicht. RippleX, die Entwicklungseinheit von Ripple, und die XRPL Foundation legten den Fall gemeinsam offen. Version 3.4.1 der Serversoftware xrpld erschien am 25. September, der Offenlegungsbericht folgte 14 Tage später. Zuvor hatten über 80% der Validatoren auf der Default Unique Node List (UNL) aktualisiert. Betroffen waren xrpld 3.4.0 und alle früheren Versionen. Eine einzige Exploit-Transaktion hätte nach Berechnung des Melders Veria Labs rund 18 Billionen XRP erzeugt.
Ein Überlauf in der Payment Engine erzeugt XRP aus dem Nichts
Die Payment Engine addierte die Beträge aller Angebote, die eine Zahlung im Orderbuch verbrauchte. Dafür nutzte sie eine 64-Bit-Ganzzahl-Addition ohne Überlaufprüfung. Bei einer genügend grossen Summe sprang der Wert auf eine kleine Zahl zurück. Jeder Anbieter erhielt die volle Zahlung, das Ledger belastete den Käufer jedoch nur mit der zurückgesprungenen Summe. Die Differenz entstand folglich als neues XRP.
Zwei Schutzmechanismen hätten das verhindern sollen. Die Invariante, wonach keine Transaktion XRP erzeugen darf, rechnete allerdings mit derselben überlaufenden Arithmetik. Ausserdem schlägt die Kontostand-Prüfung pro Konto erst oberhalb der Gesamtmenge an. Das erzeugte XRP hätte sich aber auf viele Konten verteilt. Für den Angriff hätte ein Akteur Hunderte Konten angelegt, die je einen winzigen Token-Bruchteil gegen eine enorme XRP-Menge anbieten. Eine einzige Zahlung verbraucht anschliessend alle Angebote. Und alle beteiligten Konten konnten dem Angreifer gehören. Die Kosten lagen bei wenigen hundert XRP an rückholbaren Reserven plus Gebühren, ein grosses Startguthaben war nicht nötig.
Zufällig liess sich der Überlauf dennoch nicht auslösen. Normale Zahlungen erreichen die nötige Summe nicht, denn kein echter Händler würde solche Preise stellen. Der Bericht hält zudem fest, dass es keinen Hinweis auf eine Ausnutzung in einem öffentlichen Netzwerk gibt. Cayden Liao von Veria Labs zufolge verkettet der Exploit zwei Fehler, die einzeln nur niedrig einzustufen wären. Er vermutet darin den Grund, weshalb die Lücke zuvor niemand fand.
Veria Labs meldet den Fehler über das Bug-Bounty-Programm
Cayden Liao und Veria AI meldeten die XRP-Ledger-Sicherheitslücke am 22. September über das Bug-Bounty-Programm des Netzwerks. Die Melder stuften sie zunächst als „Major“ ein. RippleX reproduzierte den Angriff und hob die Einstufung auf „kritisch“ an. Den Fix entwickelte das Team daraufhin privat. Einen Tag später gelangte er in den Release-Branch für Version 3.4.1 und war im Release Candidate 3.4.1-rc1 enthalten. Seither prüft die Payment Engine beim Summieren der Angebotsbeträge auf einen Überlauf. Läuft die Summe über, scheitert dieser Teil der Zahlung.
Über die Entdeckung selbst gibt es nur Angaben von Veria Labs. Dem Unternehmen zufolge fand ein KI-Agent den Fehler und baute einen funktionierenden Exploit. Der Offenlegungsbericht nennt hingegen lediglich Liao und Veria AI als Melder. Die Zahl von rund 18 Billionen XRP stammt ebenfalls aus Liaos Rechnung und entspräche dem 184-Fachen der Gesamtmenge. Veria erhielt nach eigenen Angaben ausserdem die Maximalprämie von 250'000 USD. Einen Betrag nennt der Bericht nicht.
Der Fehler steckte laut Bericht vermutlich seit der Entwicklung der Payment Engine im Jahr 2015 im Code. Er blieb rund ein Jahrzehnt lang unbemerkt. Damit reiht sich der Fall in die KI-gestützte Schwachstellensuche ein, die Lücken schneller sichtbar macht. Auch Entwickler von RippleX argumentieren aus dieser Perspektive.
Der Fix wirkt ohne Amendment, die Offenlegung folgt 14 Tage später
Regeländerungen am XRP Ledger laufen normalerweise über sogenannte Amendments. Eine Änderung braucht dafür über zwei Wochen hinweg die Unterstützung von mehr als 80% der vertrauten Validatoren. Dieser Fix wirkte hingegen sofort mit dem Upgrade jedes einzelnen Servers. Der Bericht bezeichnet ihn als erste bewusste Änderung dieser Art an der Transaktionsverarbeitung seit Einführung der Amendments. Am Tag des Release liefen bereits über 80% der Validatoren auf der Default-UNL mit Version 3.4.1 oder neuer.
RippleX begründet den Schritt mit dem Zeitfenster. Bei einem gewöhnlichen Open-Source-Release hätte der Code Angreifern wochenlang gezeigt, wo der Fehler liegt, bevor der Fix greift. Mitglieder der XRPL Foundation, RippleX und XRPL-Validatoren waren sich deshalb vorab einig, dass das Risiko ein schnelles Vorgehen rechtfertigt. Gerechtfertigt sei das Vorgehen nur bei schwersten Fehlern, alle anderen Änderungen laufen weiterhin über Amendments.
"KI hat die Lage verändert. Man kann einen kritischen Bug-Patch nicht in einen routinemässigen öffentlichen Release-Prozess schmuggeln, er wird sofort entdeckt und per Reverse Engineering analysiert." - Mayukha Vadari, RippleX
Den Quellcode von 3.4.1 veröffentlichte das Team allerdings erst rund zwei Wochen nach den Binärdateien auf GitHub. Justin Bons, Gründer von Cyber Capital, kritisierte auf X, XRP laufe seit zwei Wochen mit Closed-Source-Code. Ein stiller Patch mit später Offenlegung ist in der Software-Sicherheit üblich. In einem dezentralen Netzwerk mit Governance-Anspruch bleibt er trotzdem umstritten.
Ein zweiter Fehler im Batch-Feature verschärft die Prozessregeln
Version 3.4.1 schloss gleichzeitig einen zweiten Fehler im Batch-Feature (XLS-56), der xrpld 3.3.0 und 3.4.0 betraf. Ein Batch enthält bis zu acht innere Transaktionen, die laut Spezifikation je in einem Feld namens RawTransaction stecken müssen. Der Server prüfte das nicht. Daraus konnte ein dauerhaft fehlerhafter Ledger-Eintrag entstehen, der Indexer, Explorer und SDKs hätte stören können. Schwerer wog eine Konsens-Variante. Bei gemischten Softwareversionen hätte eine präparierte Transaktion die Validierung stoppen können, zum Preis einer Transaktionsgebühr. Ein Angreifer hätte damit on-chain nichts gewonnen. Folgen für das Mainnet gab es jedoch keine, da BatchV1_1 dort nicht aktiv war.
Erstmals tauchte der Befund beim Sherlock Attackathon auf, zunächst mit der Einstufung „low“. Am 18. September bestätigte Denis Angell von der XRPL Foundation, dass ein früherer Fix unvollständig war. Vier Tage danach erkannte Mayukha Vadari das Konsens-Risiko. Ripple und der Validator-Betreiber Vet zogen daraufhin ihre Stimmen für BatchV1_1 zurück. Dessen Aktivierung war ursprünglich für den 29. September vorgesehen. Mit dem Release startete gleichzeitig die zweiwöchige Aktivierung von fixBatchV1_2. Seit dem 9. Oktober sind schliesslich beide Amendments auf dem Mainnet aktiv.
RippleX ändert deshalb den Prüfprozess. Jeder als behoben markierte Sicherheitsbefund durchläuft künftig einen erneuten Test gegen den Release Candidate. Das Team schliesst ihn erst, wenn ein Test den ursprünglichen Fehler reproduziert und der Kandidat besteht. Als weitere Absicherung nennt der Bericht unter anderem ö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 neuer aktualisieren.