Ein zehn Jahre alter Bug hätte Milliarden XRP erzeugen können

iEXExchanger
Ein zehn Jahre alter Bug hätte Milliarden XRP erzeugen können

Die Entwickler von XRP Ledger schlossen eilig eine zehn Jahre alte Schwachstelle, die theoretisch Token über die Grenze von 100 Milliarden Münzen hinaus erschaffen hätte. Hinweise auf einen echten Angriff fehlen.

XRP wurde immer mit einem einfachen Versprechen verkauft: einer festen Obergrenze von 100 Milliarden Münzen, 2012 in einem einzigen Block vorgeprägt, ohne Mining und ohne schrittweise Inflation. Über ein Jahrzehnt lang war diese Zahl das Hauptargument gegenüber der langsamen Emission von Bitcoin. Nun zeigt sich, dass diese Grenze die ganze Zeit auf einer Arithmetik ruhte, die niemand ernsthaft zu brechen versucht hatte.

Der Fehler steckte seit 2015 im Abrechnungscode der Zahlungs-Engine. Wenn eine einzelne Zahlung eine große Menge an Orders von XRP Ledgers eingebauter Börse auf einmal abarbeitete, wurde der geschuldete Betrag als 64-Bit-Integer berechnet. Genügend Orders mit absurden Preisen reichten aus, damit diese Zahl überlief und zu einer viel kleineren Zahl "umschlug" — Verkäufer erhielten die volle Zahlung, während der Käufer fast nichts zahlte. Die Differenz zwischen beiden war praktisch XRP, das es zuvor nie gegeben hatte.

Die Umsetzung wäre fast kostenlos gewesen: Laut RippleX hätte ein Angreifer nur wenige hundert XRP als Reserven, verteilt auf mehrere Konten, plus normale Transaktionsgebühren benötigt.

Entdeckt wurde die Lücke nicht durch ein internes Audit, sondern durch den Forscher Cayden Liao zusammen mit dem Team von Veria AI — gemeldet am 22. September über das XRPL-Bug-Bounty-Programm. Danach lief alles ungewöhnlich schnell für ein dezentrales Netzwerk: RippleX reproduzierte den Fehler und stufte ihn innerhalb eines Tages als kritisch ein, und der Patch xrpld 3.4.1 erschien am 25. September — unter Umgehung der üblichen Amendment-Abstimmung, die normalerweise die Zustimmung von über 80 % der vertrauenswürdigen Validatoren über zwei Wochen hinweg erfordert. Für ein Netzwerk, das sich mit verteilter Governance rühmt, war das eine bewusste Ausnahme: Das Schließen des Risikofensters wog schwerer als das Abwarten des üblichen Verfahrens.

Öffentlich bekannt wurde das Problem erst am 9. Oktober, zwei Wochen nach der tatsächlichen Behebung. XRPL Operations erklärte, keine Hinweise auf eine Ausnutzung in einem öffentlichen Netzwerk gefunden zu haben — was von außen schwer zu überprüfen ist, da ein erfolgreicher Angriff schlicht wie eine große, völlig normale Zahlung ausgesehen hätte.

Dabei geht es nicht nur um einen einzelnen Beinahe-Unfall. Es ist eine Erinnerung daran, dass selbst eine über zehn Jahre alte, etablierte Blockchain, die mit einem festen und vorhersehbaren Angebot wirbt, noch Arithmetik verbergen kann, die niemand wirklich zu brechen versucht hat — bis es ein Bounty-Jäger tat. Eine feste Obergrenze ist nur so stabil wie der Code, den noch niemand bis an seine Grenze getrieben hat.

Fragen und Antworten

Häufig gestellte Fragen zum Thema des Artikels

Worin bestand die Schwachstelle von XRP Ledger genau?

Ein Fehler in der Zahlungs-Engine ließ unter bestimmten Bedingungen den für die Transaktionssumme verwendeten 64-Bit-Integer überlaufen, sodass der Verkäufer voll bezahlt wurde, während der Käufer fast nichts zahlte — die Differenz wurde zu neuem, nirgends verbuchtem XRP.

Wer hat den Bug entdeckt und wie?

Der unabhängige Forscher Cayden Liao fand sie zusammen mit dem Team von Veria AI und meldete sie am 22. September 2026 über das XRPL-Bug-Bounty-Programm, das externe Forscher für das Auffinden kritischer Fehler bezahlt.

Wurde tatsächlich jemand geschädigt?

XRPL Operations erklärte, keine Beweise für eine Ausnutzung im öffentlichen Netzwerk gefunden zu haben. Das lässt sich jedoch schwer unabhängig überprüfen, da ein erfolgreicher Angriff schlicht wie eine große, ansonsten gewöhnliche Zahlung ausgesehen hätte.

Warum wurde der Patch ohne die übliche Validator-Abstimmung veröffentlicht?

Eine normale Protokolländerung bei XRP Ledger benötigt über 80 % der vertrauenswürdigen Validatoren über zwei Wochen hinweg. Angesichts der Kritikalität des Bugs brachten die Entwickler xrpld 3.4.1 als Notfall-Release heraus, um das Risikofenster so schnell wie möglich zu schließen, statt den vollen Abstimmungsprozess abzuwarten.