Ein jahrzehntealter XRP-Ledger-Bug hätte 18 Billionen XRP prägen können

Play Now

Play One-Piece-Monte

Das XRP Ledger hat eine harte Obergrenze von 100 Milliarden XRP. Rund elf Jahre lang war diese Obergrenze nur eine Empfehlung. Am 9. Oktober 2026 veröffentlichte die XRPL Foundation einen Offenlegungsbericht, der bestätigt, dass eine einzige manipulierte Transaktion etwa 18,4 Billionen ausgebbare XRP hätte erzeugen können – rund 184-mal die Gesamtmenge – und dass der Code, der dies ermöglichte, seit November 2015 in der Payment Engine steckte. Der Bug wurde von einem KI-Agenten gefunden, innerhalb von drei Tagen gepatcht und auf eine Weise ausgeliefert, die das Ledger noch nie zuvor genutzt hatte. Niemand hat ihn ausgenutzt. Das ist die gute Nachricht. Alles andere an dieser Geschichte verdient einen genaueren Blick.

Was der XRP-Ledger-Overflow-Bug tatsächlich bewirkte

Der Fehler steckte in dem Teil der Payment Engine, der eine Zahlung über ein Orderbuch abwickelt. Wenn eine Zahlung viele Angebote gleichzeitig verbraucht, addiert die Engine die Beträge, die sie jedem Angebotsinhaber schuldet. Diese Addition verwendete einfache 64-Bit-Ganzzahlen mit Vorzeichen ohne Overflow-Prüfung. Überschreitet die Summe 2 hoch 64, läuft der Zähler auf eine kleine Zahl über – so wie ein Tacho von 999999 auf 000000 zurückspringt.

Hier kommt der hässliche Teil. Die Engine belastete den Käufer mit der übergelaufenen Summe, die winzig war. Sie zahlte jedem Angebotsinhaber seinen vollen, nicht übergelaufenen Betrag. Die Differenz zwischen diesen beiden Zahlen sind XRP, die einen Moment zuvor nicht existierten.

Das Ledger hat für genau diesen Fall ein Sicherheitsnetz. Eine Invariantenprüfung namens XRPNotCreated läuft nach jeder Transaktion und verweigert die Validierung von allem, was die Gesamtmenge an XRP erhöht. Das Problem: Die Invariante verfolgte die Netto-XRP-Änderung mit derselben ungeprüften 64-Bit-Arithmetik. Ein ausreichend großer Credit ließ auch den Invariantenzähler überlaufen, sodass eine Transaktion, die Billionen XRP druckte, für die Sicherheitsprüfung wie ein routinemäßiger Fee-Burn aussah. Zwei unabhängige Bugs, zwei Jahre auseinander geschrieben, hoben gegenseitig ihren Schutz auf.

Wie 256 Angebote 18 Billionen XRP ergeben

Veria Labs, die Sicherheitsfirma, deren KI-Agent den Bug fand, veröffentlichte die Arithmetik. Der Angriff nutzte 256 Angebote. Jedes Angebot wurde für 2 hoch 56 plus einen Drop XRP verkauft. Multipliziert man 256 mit dieser Zahl, landet die Summe bei exakt 2 hoch 64 plus 256 Drops. Der zusätzliche einzelne Drop pro Angebot ist entscheidend: Ohne ihn läuft die Summe auf exakt null über, was die Engine als trockene Zahlung ablehnen würde. Mit ihm wird der Käufer mit 256 Drops belastet, etwa 0,000256 XRP, während die 256 Angebotsinhaber zusammen 2 hoch 64 Drops erhalten. Das sind 18.446.744.073.709.551.616 Drops oder rund 18,45 Billionen XRP.

Der Angreifer benötigte 256 finanzierte Konten, weil jedes XRPL-Konto auf 100 Milliarden XRP begrenzt ist – weit unter dem Betrag pro Angebot, der auf ein Konto verteilt würde. Er benötigte außerdem ein paar hundert XRP an Reserven und Transaktionsgebühren, alles rückgewinnbar. Validator-Zugriff war nicht erforderlich. Der Angriff konnte mit frischen Konten wiederholt werden. Veria bezifferte den gefährdeten Wert auf rund 94 Milliarden US-Dollar – mehr als sechzigmal der Bybit-Diebstahl von 1,5 Milliarden US-Dollar, der derzeit den Rekord für einen tatsächlich erfolgten Krypto-Hack hält.

Ein KI-Agent fand ihn an einem Montagabend

Als offizieller Melder gilt Cayden Liao von Veria Labs, zusammen mit dem KI-Agenten der Firma. Verias eigener Darstellung zufolge wurde der Agent am 21. September auf die rippled-Codebasis angesetzt, markierte beide Overflows, erkannte, dass sie verkettet werden konnten, und erstellte einen funktionierenden Proof of Concept in einem lokalen Netzwerk. Ein Gründungsingenieur wurde um 4 Uhr morgens geweckt, um ihn zu prüfen. Am Morgen des 22. September war das Team sicher genug, ihn über das XRPL Bug Bounty Programm einzureichen und als Major einzustufen. RippleX reproduzierte ihn am selben Tag und stufte ihn auf Critical hoch. Realistischerweise behauptet Veria, dass allgemeine Coding-Agenten, die nach der Offenlegung auf denselben Code angesetzt wurden, ihn nicht fanden. Das ist mit der üblichen Skepsis gegenüber einem Unternehmen zu sehen, das genau dieses Tool verkauft. Der breitere Punkt bleibt dennoch bestehen. Der BookStep-Aggregationscode stammt von November 2015 und die XRPNotCreated-Invariante von Februar 2017. Das XRPL hat seit 2024 über 1 Million US-Dollar an Bounties gezahlt und mehr als ein Dutzend Audits und Audit-Wettbewerbe durchgeführt. Menschen und Auditfirmen haben diesen Code ein Jahrzehnt lang geprüft und ihn übersehen. Das Muster wird vertraut. Coldcard verlor diesen Sommer rund 1.367 BTC durch einen fünf Jahre alten Firmware-Bug, von dem sein Hersteller vermutet, dass er mit KI-Unterstützung gefunden wurde. Alter Code ist nicht mehr allein deshalb sicher, weil er alt ist.

Warum der Fix die Validator-Abstimmung übersprang

Hier hört die Geschichte auf, ein sauberer Sicherheitserfolg zu sein, und wird zu einer Governance-Debatte. Das XRP Ledger ändert Transaktionsregeln normalerweise über Amendments. Eine neue Regel wird im Software-Update deaktiviert ausgeliefert, Validatoren stimmen darüber ab, und sie aktiviert sich erst, nachdem sie zwei aufeinanderfolgende Wochen mehr als 80 Prozent Unterstützung auf der Standard-Unique-Node-List gehalten hat. Das System existiert seit über einem Jahrzehnt und wurde nie absichtlich für eine transaktionsverarbeitende Änderung umgangen.

Bis zum 25. September. Der Overflow-Fix wurde direkt in xrpld 3.4.1 ohne Amendment-Gate ausgeliefert. Er wurde auf jedem Server wirksam, sobald dieser Server aktualisiert wurde. Die Begründung der XRPL Foundation ist geradlinig: Eine Amendment-Abstimmung hätte den Fix und damit den Bug zwei Wochen vor seinem Inkrafttreten veröffentlicht. Jeder, der den Diff las, hätte zwei Wochen Zeit gehabt, 18 Billionen XRP zu drucken. Die Foundation erklärt, die Entscheidung sei gemeinsam von ihr, RippleX, Kernentwicklern und Validatoren getroffen worden, und keine einzelne Partei hätte sie allein treffen können.

Der Ansatz barg ein eigenes Risiko, was der Offenlegungsbericht einräumt. Hätte jemand den Exploit versucht, während das Netzwerk zwischen gepatchten und ungepatchten Servern gespalten war, hätten die beiden Gruppen sich über den Ledger-Zustand uneinig gewesen. Im schlimmsten Fall hält das Netzwerk an. Das Team befand einen möglichen Stillstand für vorzugswürdig gegenüber einer sicheren Angebotsexplosion, was schwer zu widerlegen ist. Mehr als 80 Prozent der Standard-UNL-Validatoren liefen innerhalb von Stunden nach der Veröffentlichung am 25. September auf 3.4.1.

Der Dezentralisierungsstreit, der folgte

Kurz gesagt: Justin Bons von Cyber Capital, ein langjähriger XRP-Kritiker, nutzte die Episode, um zu argumentieren, dass die Vermarktung von XRP an Privatanleger als dezentral einem Betrug gleichkomme. Seine konkreten Beschwerden: Die Veröffentlichung vom 25. September wurde nur als kompilierte Binärdateien verteilt, der Quellcode vorübergehend zurückgehalten, und Betreiber wurden gedrängt, eine Binärdatei zu aktualisieren, die sie nicht prüfen konnten. Der XRPL-Offenlegungsbericht bestätigt, dass die Quelle später veröffentlicht wurde, sagt aber nicht, wann.

Praktisch kam das Gegenargument ebenso von unabhängigen Validator-Betreibern wie von der Foundation. XRP Kuwait, das einen eigenen Node betreibt, formulierte es so: Koordination ist nicht dasselbe wie Kontrolle. Unabhängige Betreiber lasen dieselbe Warnung, kamen zum selben Schluss und aktualisierten. Niemand zwang sie. Bitcoin hat dasselbe getan, insbesondere mit dem Inflation-Bug von 2018 in Bitcoin Core 0.16.x, als Entwickler stillschweigend einen Fix auslieferten, bevor sie erklärten, was er behob. Jede Chain mit einem ernsten Bug steht irgendwann vor der Wahl zwischen Transparenz und Überleben, und jede von ihnen hat das Überleben gewählt. Letztlich hat Bons bei den Binärdateien einen berechtigten Punkt. Eine nicht verifizierbare Binärdatei auszuliefern und Validatoren zu bitten, sie sofort auszuführen, ist eine Vertrauensübung, so gerechtfertigt sie auch sein mag. Die ehrliche Version der XRPL-Position ist, dass ihr Validator-Set der Foundation und RippleX genug vertraute, um ein paar Tage lang ungeprüften Code auszuführen. Ob man das dezentral nennt, hängt davon ab, was man unter dem Wort versteht.

Waren 250.000 US-Dollar genug für einen 94-Milliarden-Dollar-Bug?

Veria Labs erhielt am 8. Oktober die höchste Critical-Auszahlung des XRPL-Programms von 250.000 US-Dollar. Veria nannte es wahrscheinlich die größte Bounty, die je für einen vollständig von einem KI-Agenten gefundenen Bug gezahlt wurde. Vier Tage später bezeichnete der Blockchain-Ermittler ZachXBT es als schlechten Witz. Sein Argument: Ein Ökosystem, dessen Treasury Milliarden hält, zahlte eine Viertelmillion für einen Fund, der das Asset hätte beenden können. Und genau diese Lücke ist der Anreiz, der den nächsten Forscher dazu bringt, stattdessen an einen Angreifer zu verkaufen. Er schlug siebenstellige Beträge als Untergrenze vor und verwies auf eine angeblich siebenstellige Belohnung, die im Zcash-Ökosystem für einen kürzlichen Fälschungsbug gezahlt wurde. Weder Ripple noch die Foundation hatten zum Zeitpunkt des Schreibens öffentlich reagiert.

Beide Seiten haben bei unterschiedlichen Dingen recht. Das Programm zahlte sein beworbenes Maximum, der Forscher legte verantwortungsvoll offen, und der Fix landete, bevor jemand außerhalb des Kreises davon wusste. Das ist das System, das funktioniert. Es ist auch wahr, dass 250.000 US-Dollar 0,27 Prozent der gefährdeten 94 Milliarden US-Dollar sind und dass jeder Angreifer mit 256 Konten und ein paar hundert XRP die anderen 99,73 Prozent hätte nehmen können. Bounty-Obergrenzen, die geschrieben wurden, als XRP einen Bruchteil seines aktuellen Marktwerts hatte, skalieren nicht mit dem, was sie schützen.

Was XRP-Halter und Krypto-Gambler daraus mitnehmen sollten

Der Fix ist serverseitig. Deine Wallet, deine Keys und dein Guthaben waren nie betroffen, und auf deiner Seite muss nichts aktualisiert werden. Die Angebotsobergrenze hielt, weil der Bug gefunden wurde, nicht weil die Invariante funktionierte. Die zweite Hälfte dieses Satzes ist die, die man sich merken sollte.

Es gibt hier drei praktische Lehren. Erstens: Dass Code zehn Jahre lang live war, ist kein Sicherheitsargument mehr. KI-gestütztes Auditing macht alte Overflows billig zu finden, und Angreifer mieten dieselben Modelle wie Forscher. Zweitens: Governance-Prozesse, die für Feature-Rollouts entwickelt wurden, sind nicht für kritische Patches gemacht. Und jede Chain sollte im Voraus entscheiden, wie sie den nächsten handhabt, statt unter Druck zu improvisieren. Drittens: Bug-Bounty-Obergrenzen sollten dem gesicherten Wert folgen. Eine feste Obergrenze, die 2022 großzügig aussah, ist 2026 eine Einladung. Für das Gambling-Publikum ist die Relevanz einfach. XRP ist zu einer Standard-Einzahlungsschiene in Krypto-Casinos geworden, weil es in vier Sekunden für einen Bruchteil eines Cents abgewickelt wird. Und diese Geschwindigkeit hängt davon ab, dass die Regeln des Ledgers korrekt sind. Plattformen, die Auszahlungen automatisieren, einschließlich CryptoCasino.Vegas, vertrauen bei jeder XRP-Auszahlung, die ohne menschliche Prüfung durchläuft, auf die Invarianten der Chain. Diese Invarianten hielten diesmal, weil ein Forscher und ein KI-Agent die Nacht durcharbeiteten – und das ist eine dünnere Marge, als die 100-Milliarden-Obergrenze je zugegeben hat.

Die vollständige technische Analyse, einschließlich beider Overflow-Stellen und der gehärteten Arithmetik, die sie ersetzte, findet sich im Offenlegungsbericht der XRPL Foundation zu xrpld 3.4.1.