Kritische XRP-Ledger-Lücke hätte XRP-Obergrenze umgangen

Der XRP Ledger hat eine kritische Schwachstelle in seiner Payment Engine behoben, die zusätzliches, ausgabefähiges XRP über die feste Gesamtmenge hinaus hätte entstehen lassen können. Bitcoin.com News und CoinDesk berichten, dass RippleX vor der öffentlichen Offenlegung einen Fix verteilte; Hinweise auf eine Ausnutzung in einem öffentlichen Netzwerk wurden nicht gefunden.

Der Fehler betraf die Abwicklung von Zahlungen über den integrierten dezentralen Handelsplatz des Netzwerks. Damit stand nicht nur ein gewöhnlicher Softwarefehler im Raum, sondern ein Angriffsszenario gegen die Obergrenze von 100 Milliarden XRP.

Wie der Rechenfehler zusätzliches XRP ermöglicht hätte

Bei einer einzelnen Zahlung, die zahlreiche Angebote auf dem XRPL-DEX ausführte, addierte die Software die Beträge mit ungeprüfter 64-Bit-Arithmetik. Wurde die Summe zu groß, konnte sie überlaufen und als deutlich kleinerer Wert erscheinen. Die Verkäufer hätten dann den vollen Betrag erhalten, während dem Käufer nur die fehlerhaft reduzierte Summe belastet worden wäre.

Die Differenz hätte als XRP vorgelegen, das zuvor nicht existierte und anschließend hätte ausgegeben werden können. Auch die sogenannte Invariante, eine interne Sicherheitsprüfung, sollte verhindern, dass durch Transaktionen neues XRP entsteht. Weil sie dieselbe fehlerhafte Berechnung verwendete, hätte sie den Überlauf jedoch nicht erkannt.

Die aktuelle Payment Engine geht laut Bitcoin.com News auf das Jahr 2015 zurück. Für den beschriebenen Angriff wären einige Hundert XRP nötig gewesen, die vorübergehend als Kontoreserven gebunden worden wären, sowie normale Transaktionsgebühren. Zudem hätte der Angreifer Hunderte absichtlich falsch bepreiste Angebote platzieren und eine Zahlung durch diese leiten müssen.

Fix vor der öffentlichen Offenlegung

Der Sicherheitsforscher Cayden Liao und Veria AI meldeten den Fehler am 22. September 2026 über das Bug-Bounty-Programm des XRP Ledgers. RippleX reproduzierte ihn am 23. September, stufte die Schwachstelle als kritisch ein und integrierte den Fix. Die Server-Software xrpld 3.4.1 wurde am 25. September ausgeliefert; an diesem Tag liefen laut Bitcoin.com News mehr als 80 Prozent der Validatoren der Standard-Unique-Node-List mit der Version.

Anders als bei Änderungen, die über ein Amendment – ein Protokoll-Update mit Abstimmungsverfahren der Validatoren – aktiviert werden, wurde diese Fehlerbehebung als direkter Code-Fix verteilt. Der Quellcode wurde erst nach dem Rollout veröffentlicht, um potenziellen Angreifern nicht vorab technische Hinweise zu geben. Die öffentliche Offenlegung erfolgte am 9. Oktober.

Der XRPL Operations Account erklärte laut Bitcoin.com News, es gebe keine Hinweise auf eine Ausnutzung in einem öffentlichen Netzwerk. 3.4.1 wurde zugleich zur erforderlichen Mindestversion gemacht. Die zeitliche Abfolge – erst Verteilung, dann Offenlegung – sollte verhindern, dass die Schwachstelle während eines offenen Abstimmungsprozesses bekannt wird, bevor genügend Server aktualisiert sind.

Was der Vorfall für das XRPL bedeutet

Die feste Obergrenze gehört zu den zentralen Eigenschaften des XRP-Angebots. Ein erfolgreicher Angriff hätte sie technisch unterlaufen können; die Berichte beschreiben jedoch ein mögliches Szenario und keine tatsächlich erzeugten oder verkauften Token. Auch die Größenordnung eines potenziellen Gewinns ist daher nicht mit einem realisierten Schaden gleichzusetzen.

In derselben Version wurde außerdem ein weniger schwerwiegender Fehler bei der Verpackung von Batch-Transaktionen behoben. Der zugehörige FixBatchV1_2-Schritt wurde am 9. Oktober auf dem Mainnet aktiviert; laut Bitcoin.com News gingen dadurch keine Mittel verloren. Für den XRPL steht damit zunächst die Nutzung der gepatchten Mindestversion im Vordergrund. Eine Kursreaktion oder weitergehende Maßnahmen lassen sich aus den vorliegenden Berichten nicht ableiten.