XRP-Ledger-Schwachstelle: Hätte sie XRP erschaffen können?

Überblick

Eine kritische XRP-Ledger-Schwachstelle, die etwa ein Jahrzehnt lang in der Zahlungs-Engine verblieben war, hätte theoretisch einem Angreifer ermöglichen können, ausgabefähige XRP außerhalb der vorgesehenen Angebotsregeln des Ledgers zu erzeugen. XRPL veröffentlichte das Problem am 9. Oktober 2026, nachdem es am 22. September privat über das XRPL Bug Bounty Program gemeldet worden war. Die Schwachstelle betraf xrpld 3.4.0 und frühere Versionen und wurde in xrpld 3.4.1 behoben, das am 25. September veröffentlicht wurde.

Die XRP-Ledger-Schwachstelle beinhaltete einen Integer-Überlauf, wenn eine Zahlung Hunderte speziell konstruierter Orderbuch-Angebote verbrauchte. Einzelne Angebotsinhaber konnten ihre vollen XRP-Beträge erhalten, während dem Käufer nur ein kleiner umgewickelter Gesamtbetrag berechnet wurde. Ernster noch: Die bestehende Invariante „keine XRP erzeugt“ des Ledgers verwendete einen ähnlichen arithmetischen Pfad und konnte auf dieselbe Weise überlaufen, wodurch diese Sicherheitsprüfung daran gehindert wurde, die Diskrepanz zu erkennen.

XRPL gibt an, keine Beweise dafür gefunden zu haben, dass die Schwachstelle in einem öffentlichen Netzwerk ausgenutzt wurde, und normale Zahlungen konnten sie nicht versehentlich auslösen. Der Angriff erforderte absichtlich konstruierte Angebote mit wirtschaftlich unrealistischen Preisen. Dennoch wirft der Vorfall eine tiefere Sicherheitsfrage auf: Die feste Geldpolitik einer Blockchain ist nur so stark wie die Software, die jeden Saldoübergang durchsetzt.

Wichtige Erkenntnisse

• Der Fehler scheint seit der Erstellung der aktuellen XRPL-Zahlungs-Engine im Jahr 2015 existiert zu haben.
• Eine absichtlich konstruierte Transaktion hätte theoretisch ausgabefähige XRP erzeugen können.
• XRPL fand keine Beweise für eine Ausnutzung in einem öffentlichen Netzwerk.
• Die bestehende Angebotsinvariante konnte fehlschlagen, weil sie dasselbe Überlaufverhalten reproduzierte.
• xrpld 3.4.1 fügte geprüfte Arithmetik und eine stärkere unabhängige Angebotsprüfung hinzu.

Was war die XRP-Ledger-Schwachstelle?

Die Schwachstelle befand sich in der Handhabung der Orderbuch-Liquidität durch die XRP-Ledger-Zahlungs-Engine. Wenn eine Zahlung durch mehrere Angebote fließt, muss die Engine berechnen, wie viel XRP der Zahler insgesamt schuldet. Jeder einzelne Betrag konnte gültig sein, aber die Aggregatberechnung verwendete eine 64-Bit-Ganzzahl ohne ausreichenden Überlaufschutz.

Unter normalen Bedingungen war dies praktisch unerreichbar. Das normale XRP-Angebot und die realen Marktpreise kommen bei weitem nicht an die numerische Grenze heran, die erforderlich ist, um den Zähler zu überlaufen. Das Problem trat nur auf, wenn ein Angreifer absichtlich Hunderte von Angeboten konstruierte, bei denen jedes Konto einen extrem großen Betrag an XRP für einen winzigen Betrag eines anderen Tokens verlangte.

Ein bösartiger Ablauf könnte ungefähr so aussehen:

• Erstellen Sie mehrere hundert kontrollierte Konten.
• Platzieren Sie absichtlich unrealistische Angebote von diesen Konten.
• Konstruieren Sie eine Zahlung, die darauf ausgelegt ist, diese Angebote zusammen zu verbrauchen.
• Treiben Sie die aggregierte XRP-Berechnung über das Integer-Limit hinaus.
• Verursachen Sie, dass der Gesamtbetrag auf eine viel kleinere Zahl umschlägt.

Die Engine konnte dann die Angebotsinhaber einzeln gutschreiben, während dem Käufer nur der übergelaufene Gesamtbetrag berechnet wurde. Da der Angreifer auch die Konten der Angebotsinhaber kontrollieren konnte, wurde die Differenz effektiv zu neuen XRP.

XRPL-Ingenieure reproduzierten den Angriff lokal und bestätigten, dass die resultierenden XRP anschließend übertragen werden konnten. Das Problem wurde infolgedessen von Major auf kritische Schwere hochgestuft.

Konnte die XRP-Ledger-Schwachstelle wirklich XRP erzeugen?

Ja, theoretisch. Dies war nicht bloß ein Buchhaltungs-Anzeigefehler. Die technische Offenlegung von XRPL besagt, dass der Exploit XRP hätte erzeugen können, das sich nach der Validierung der bösartigen Transaktion wie gewöhnliches XRP verhielt. Diese Guthaben hätten verschoben, gehandelt oder an Börsen gesendet werden können.

Das bedeutet nicht, dass XRP historisch übermäßig ausgegeben wurde. XRPL berichtet, dass es keine Beweise dafür gefunden hat, dass der Exploit in einem öffentlichen Netzwerk aufgetreten ist. Der Unterschied zwischen diesen beiden Aussagen ist wesentlich: Die Schwachstelle konnte die beabsichtigte Angebotsbeschränkung verletzen, aber derzeit gibt es kein bestätigtes historisches Angebotsereignis, das damit in Verbindung gebracht wird.

Der Angriff konnte auch nicht versehentlich während des normalen DEX-Handels auftreten. Die Orderbuch-Angebote mussten so unrealistisch bepreist sein, dass normale Marktliquidität vor Erreichen dieser ausgeführt würde. Eine Zahlung musste auch absichtlich so konstruiert sein, dass sie genügend dieser Angebote zusammen verbrauchte, um den Überlauf auszulösen.

Dies ist daher am besten als ein Ausführungspfad mit geringer Wahrscheinlichkeit und extrem hoher theoretischer Auswirkung zu verstehen, und nicht als ein Fehler, den gewöhnliche XRP-Nutzer unwissentlich hätten auslösen können.

Warum versagte XRPLs Angebots-Sicherheitsprüfung?

Der technisch wichtigste Teil des Vorfalls ist nicht einfach, dass ein Integer-Überlauf existierte. Ausgereifte Finanzsoftware enthält oft mehrere Verteidigungsschichten, die genau darauf ausgelegt sind, solche unerwarteten Ergebnisse abzufangen.

XRPL hatte eine: eine Transaktionsinvariante, die sicherstellen sollte, dass eine Transaktion keine XRP erzeugen konnte. Im Prinzip hätte die Invariante selbst dann, wenn die Zahlungs-Engine einen Buchhaltungsfehler machte, bemerken müssen, dass die gesamten XRP-Guthaben zunahmen, und die Transaktion ablehnen müssen.

Sie tat es nicht.

Der Grund ist ein klassisches Versagen vermeintlich unabhängiger Sicherheitssysteme. Die Invariante berechnete die Netto-XRP-Änderungen unter Verwendung einer ähnlichen Art ungeprüfter Arithmetik. Als die Zahlungs-Engine überlief, konnte die Invariantenberechnung in dieselbe Richtung überlaufen, wodurch die resultierende Transaktion so erschien, als hätte sie das XRP-Angebot nur um die gewöhnliche Transaktionsgebühr verändert.

Eine Sicherheitsprüfung ist nicht wirklich unabhängig, wenn sie denselben Fehlermodus reproduzieren kann wie das System, das sie prüft.

Eine zweite Schutzmaßnahme prüfte, ob ein einzelnes Kontoguthaben das gesamte XRP-Angebot überstieg. Auch das konnte den Angriff nicht stoppen, weil die neu erzeugten XRP über Hunderte von Konten verteilt werden konnten, wodurch jedes einzelne Guthaben unter dem Limit blieb.

Die Behebung adressierte daher sowohl den unmittelbaren Fehler als auch die defensive Architektur. xrpld 3.4.1 fügte explizite Überlaufprüfungen hinzu, wenn Beträge über Angebote und Zahlungspfade hinweg aggregiert werden. XRPL änderte außerdem die Invariante „keine XRP erzeugt“ dahingehend, einen breiteren Zähler zu verwenden, der unter denselben Bedingungen nicht überlaufen kann.

Warum blieb ein Fehler von 2015 so lange verborgen?

Die Antwort liegt teilweise in der Differenz zwischen realistischen wirtschaftlichen Werten und theoretischen Computergrenzen. Einzelne XRP-Zahlungen bewegen sich um viele Größenordnungen unterhalb des Bereichs, der erforderlich ist, um eine 64-Bit-Summe zu überlaufen. Ein normaler Händler könnte XRPL jahrelang nutzen, ohne irgendetwas zu erzeugen, das den bösartigen numerischen Bedingungen ähnelt.

Dies machte den Fehler schwer durch routinemäßige Nutzung aufzudecken. Die anfällige Logik konnte sich über Milliarden normaler Operationen hinweg korrekt verhalten und dennoch an einer künstlichen Grenze katastrophal versagen.

Die Schwachstelle zeigt auch, warum langlebiger Blockchain-Code nicht automatisch als sicher betrachtet werden sollte, nur weil er viele Jahre lang betrieben wurde. Die Produktionshistorie ist ein nützlicher Beweis, aber sie testet hauptsächlich gängige Zustände. Angreifer suchen gezielt nach Zuständen, die normale Nutzer niemals erzeugen.

XRPL schrieb die Entdeckung des Problems seinem Bug-Bounty-Programm zu und hat einen breiteren Defense-in-Depth-Ansatz skizziert, der unabhängige Audits, öffentliche Attackathons, Fuzzing, KI-gestütztes Red Teaming und formale Verifikation umfasst. Es fügt außerdem eine erneute Überprüfung von Sicherheitsfixes gegen Release-Kandidaten hinzu, bevor Befunde formell geschlossen werden.

Dieser Ansatz ist wichtig, weil die Lehre aus diesem Vorfall nicht ist, dass ausgereiftem Code nicht vertraut werden kann. Sie ist, dass ausgereifter Code immer noch adversariales Testen gegen Annahmen erfordert, die Entwickler vor Jahren aufhörten zu hinterfragen.

Was bedeutet der Fehler für XRPs festes Angebot?

XRP begann mit einem definierten Anfangsangebot von 100 Milliarden Token, ohne einen Protokollmechanismus analog zum Proof-of-Work-Mining, der kontinuierlich zusätzliche XRP erzeugt. Transaktionsgebühren werden vernichtet statt an Validatoren gezahlt, sodass der beabsichtigte Angebotspfad nicht inflationär ist.

Die XRP-Ledger-Schwachstelle legt eine wichtige Unterscheidung offen zwischen Geldpolitik als Regel und Geldpolitik als softwaremäßiger Durchsetzung.

Eine Blockchain-Spezifikation mag feststellen, dass keine neuen XRP erzeugt werden können, aber Knoten setzen diese Eigenschaft letztlich durch Code durch. Wenn die Guthabenübergangslogik manipuliert werden kann, um die Regel zu verletzen, dann kann die Wirtschaftspolitik selbst versagen, obwohl sich die dokumentierte Politik nicht geändert hat.

Dieser Vorfall hat nicht gezeigt, dass XRPs tatsächliches Umlaufangebot heimlich erhöht wurde. XRPL sagt, dass keine Ausnutzung im öffentlichen Netzwerk gefunden wurde. Aber er hat gezeigt, dass es vor dem Patch einen theoretischen Ausführungspfad gab, der eine der fundamentalsten geldpolitischen Beschränkungen des Ledgers umgehen konnte.

Das macht diese Schwachstelle folgenreicher als einen vorübergehenden RPC-Ausfall oder ein Knotenkonnektivitätsproblem. Ein Netzwerk kann bestimmte Infrastrukturstörungen tolerieren, ohne die Asset-Integrität zu beeinträchtigen. Ein Fehler, der in der Lage ist, ausgebbare Einheiten zu erzeugen, berührt das buchhalterische Fundament des Ledgers selbst.

Warum die Behebung mehr zählt als das Fehlen eines Exploits

Es ist verlockend, eine Schwachstelle abzutun, sobald Ermittler sagen, dass sie nie ausgenutzt wurde. Das würde die nützlichere Sicherheitslektion verpassen.

XRPLs Reaktionszeitplan war relativ komprimiert: Das Problem wurde am 22. September gemeldet und reproduziert, der Fix wurde vom 22. bis 23. September entwickelt und überprüft, in den 3.4.1-Release-Zweig zusammengeführt und am 25. September veröffentlicht. XRPL berichtete, dass mehr als 80 % der Standard-Unique-Node-List-Validatoren am selben Tag die geschützte Version ausführten.

Der Fix der Zahlungs-Engine trat zudem direkt mit dem Software-Upgrade in Kraft, anstatt auf den normalen Amendment-Aktivierungsprozess zu warten. Das war möglich, weil die Ablehnung arithmetischen Überlaufs als Behebung undefinierten oder unsicheren Verhaltens behandelt wurde und nicht als Einführung einer neuen beabsichtigten Transaktionsregel.

Für die Blockchain-Sicherheit ist der Zeitpunkt der Offenlegung Teil der Verteidigung. Die Veröffentlichung des Exploits, bevor die Validatoren geschützt waren, hätte eine theoretische Schwachstelle in operative Anweisungen für Angreifer verwandelt. XRPL hat daher technische Details erst offengelegt, nachdem sich die gepatchte Version bereits verbreitet hatte.

Risiken und Einschränkungen

Der Vorfall ist ernst, aber mehrere Grenzen sollten klar bleiben.

• Kein bestätigtes Inflationsereignis: XRPL gibt an, keine Hinweise auf eine Ausnutzung in einem öffentlichen Netzwerk gefunden zu haben.
• Keine versehentliche Auslösung: normale Zahlungen und realistische Orderbücher erreichen nicht die erforderlichen Werte.
• Die Patch-Adoption ist wichtig: Serverbetreiber sollen xrpld 3.4.1 oder neuer ausführen.
• Ein Fix beweist nicht vollständige Sicherheit: andere alte arithmetische Annahmen rechtfertigen weiterhin adversariales Testen.
• Das historische Fehlen von Missbrauch kann keine formale Verifikation ersetzen: einige Fehlerklassen sind zu ungewöhnlich, um durch normale Netzwerkaktivität aufzutreten.

Eine weitere Einschränkung ist die retrospektive Gewissheit. Ermittler können die Ledger-Historie und bekannte Exploit-Muster analysieren, aber der Beweis, dass eine Schwachstelle nie genutzt wurde, unterscheidet sich grundlegend vom mathematischen Beweis, dass sie nicht hätte genutzt werden können. Die offizielle Schlussfolgerung ist daher angemessen als keine Hinweise gefunden formuliert und nicht als absolute Aussage über jeden historischen Zustand.

MEXC-Ansicht: Festes Angebot ist eine Eigenschaft der Software-Sicherheit

Die Geldpolitik einer Blockchain wird nicht allein durch eine in der Dokumentation geschriebene Angebotszahl gesichert. Sie wird durch die Software gesichert, die jede Bilanzänderung, jeden Transaktionspfad und jeden Ledger-Zustand validiert.

Der XRPL-Vorfall veranschaulicht, warum diese Unterscheidung wichtig ist. Die beabsichtigte Regel des Protokolls verbot die Erzeugung neuer XRP, doch ein Fehler in der Arithmetik hätte diese Regel theoretisch verletzen können. Noch wichtiger ist, dass die defensive Invariante, die zur Erkennung von Angebotserzeugung dienen sollte, zunächst denselben Fehlermodus aufwies.

Für ausgereifte Blockchain-Netzwerke muss die Sicherheit daher über das Testen hinausgehen, ob sich normale Transaktionen korrekt verhalten. Unabhängige Invarianten, Fuzzing, adversariales Grenzwerttesten und formale Methoden werden gerade deshalb immer wichtiger, weil die schädlichsten Schwachstellen in Codepfaden existieren können, die normale Nutzer nie berühren.

Die Kennzahl, die nach dieser Offenlegung beobachtet werden sollte, ist nicht die XRP-Preisreaktion. Es ist die Frage, ob die erweiterten Verifikationsprozesse von XRPL konsequent ähnliche Klassen latenter Protokollrisiken finden und isolieren, bevor Angreifer dies tun.

Der jahrzehntealte Bug war kritisch, aber kein nachgewiesenes XRP-Inflationsereignis

Die XRP-Ledger-Schwachstelle verdient die Bezeichnung „kritisch“, weil sie theoretisch eine der grundlegendsten Garantien von XRPL untergraben könnte. Eine sorgfältig konstruierte Zahlung könnte einen 64-Bit-Arithmetiküberlauf erzwingen, Hunderte von Angebotsinhabern mit XRP gutschreiben und den Käufer nur einen Bruchteil des Gesamtbetrags belasten. Die neu erzeugten Guthaben waren in XRPLs eigener Reproduktion des Angriffs ausgebbar.

Aber die zweite Hälfte der Geschichte ist ebenso wichtig. XRPL fand keine Hinweise auf eine Ausnutzung im öffentlichen Netzwerk, die Transaktion erforderte bewusst abnormale Orderbuchbedingungen, und die Schwachstelle wurde in xrpld 3.4.1 gepatcht, bevor die technischen Details öffentlich offengelegt wurden.

Der Vorfall sollte daher nicht als Beweis dafür umgeschrieben werden, dass das XRP-Angebot historisch inflationiert wurde. Seine Bedeutung ist struktureller. Er zeigt, dass selbst eine Blockchain mit festem Angebot letztlich davon abhängt, dass Software monetäre Beschränkungen in Randfällen korrekt durchsetzt, die jahrelang unsichtbar bleiben können.

Die stärkste Erkenntnis aus dieser XRP-Ledger-Schwachstelle betrifft folglich das Protokoll-Engineering und nicht Schlagzeilen zum Token-Angebot. Monetäre Invarianten benötigen eine unabhängige Implementierung, alter Code erfordert weiterhin adversariales Review, und ein erfolgreicher Netzwerkbetrieb über ein Jahrzehnt schließt die Möglichkeit verborgener Grenzbedingungsfehler nicht aus. Der Bug bewies nicht, dass XRP übermäßig ausgegeben wurde; er bewies, warum die Integrität des Angebots kontinuierlich verifiziert werden muss.

Quellen

Offizielle Schwachstellenoffenlegung von XRPL:
https://xrpl.org/es-es/blog/2026/vulnerabilitydisclosurereport-bug-20261009

Informationen zur Veröffentlichung von XRPL 3.4.1:
https://xrpl.org/blog

Möchten Sie die neuesten Informationen von MEXC am schnellsten erhalten? Treten Sie jetzt unserer offiziellen Telegram-Gruppe bei!
MEXC-Plattform: App herunterladen | Handel ohne Gebühren | Jetzt USDT kaufen Treten Sie der MEXC-Community bei: X (Twitter) | Telegram | Discord
Informationen erhalten: Akademie für Anfänger | Nutzungsbedingungen | MEXC Blog | MEXC News
Kontoverifizierung: KYC verstehen | Wie man KYC durchführt

Risikohinweis: Der Inhalt dieses Artikels dient nur als Referenz und stellt keine Anlageberatung dar. Der Markt für digitale Währungen ist sehr volatil, bitte treffen Sie Ihre Entscheidungen sorgfältig entsprechend Ihrer eigenen Situation.