xrpld 3.4.1 schließt Fehler, der neues XRP hätte erzeugen können

Nach Darstellung der Entwickler ließ sich bis Version 3.4.0 mit einem Fehler in xrpld, der Serversoftware des XRP Ledger, neues XRP erzeugen, im Ernstfall weit über die Gesamtmenge hinaus. Ursache war ein Ganzzahlüberlauf: Ein Zähler lief wie ein alter Kilometerzähler über seinen Höchstwert und sprang auf einen falschen kleinen Wert. Laut dem Disclosure-Bericht vom 9. Oktober 2026 fanden die Entwickler keine Hinweise darauf, dass jemand die Lücke in einem öffentlichen Netz ausgenutzt hat. Handeln müssen die Serverbetreiber: Sie brauchen xrpld 3.4.1 oder neuer.

Mit xrpld 3.4.1 ist die Lücke geschlossen. Für dich zählen danach zwei Fragen. Wie belastbar ist eine Entwarnung, die von den Entwicklern selbst kommt? Und was heißt es, dass die Korrektur laut Bericht als erste Änderung der Transaktionsverarbeitung seit mehr als zehn Jahren ohne Amendment-Abstimmung ins Netz ging?

Laut Bericht konnte eine einzige präparierte Zahlung neues XRP erzeugen

Der Angriff brauchte präparierte Angebote im Orderbuch und eine einzige Zahlung. Das so erzeugte XRP ließ sich ausgeben wie jedes andere. Im Szenario der Entwickler hätte eine einzige validierte Transaktion gereicht, um ausgebbares XRP weit über der Gesamtmenge zu schaffen. RippleX hat die Erzeugung auf einem lokalen Testserver und in Unit-Tests nachgestellt, also abseits des öffentlichen Netzes.

Die Schutzprüfung lief mit über, ab 3.4.1 rechnet sie breiter

Der Fehler steckte in der Payment Engine, dem Teil von xrpld, der Zahlungen über Angebote im Orderbuch abwickelt. Nach Einschätzung der Entwickler bestand er vermutlich seit 2015, als die heutige Payment Engine entstand. Unbemerkt blieb er wohl rund ein Jahrzehnt, weil normale Zahlungen nicht in die Nähe des Überlaufs kommen.

Gemeldet wurde er am 22. September 2026 über das Bug-Bounty-Programm des XRP Ledger, eingestuft als „Major“. RippleX stellte die Erzeugung noch am selben Tag nach und stufte den Fehler auf „critical“ hoch.

Auslösen ließ sich der Angriff nur mit Absicht. Nötig waren Hunderte Angebote zu Preisen, die kein echter Händler setzen würde, und eine eigens gebaute Zahlung, die sie alle auf einmal aufbraucht.

Der Einsatz dafür war klein. Der Bericht beziffert ihn auf einige hundert XRP an Konto- und Angebotsreserven, die beim Entfernen der Objekte zurückfließen, dazu übliche Transaktionsgebühren. Stell das neben das mögliche Ergebnis: einige hundert XRP Reserven plus Gebühren auf der einen Seite, ausgebbares XRP weit über der Gesamtmenge auf der anderen.

Gegen genau diesen Fall gibt es eine Invariante: eine Schlusskontrolle nach jeder Transaktion, die sicherstellen soll, dass kein XRP aus dem Nichts entsteht. Sie kam zwei Jahre nach der Payment Engine hinzu und nutzte dieselbe ungeprüfte Arithmetik. Die Nettoänderung summierte sie mit einem gleichartigen 64-Bit-Zähler, der ebenso überlief. Die Transaktion sah deshalb aus, als habe sie nur die Gebühr verbraucht.

Die zweite Sicherung, die Prüfung des Kontostands, schlägt erst an, wenn ein einzelnes Konto mehr als die gesamte XRP-Menge hält. Das erzeugte XRP ließ sich aber auf Hunderte Konten verteilen und blieb so unter dieser Schwelle.

Andere Nutzer konnten in den Tests der Entwickler weiter zahlen: Zahlungen und Pfadsuche lieferten mit und ohne die präparierten Angebote dieselben Ergebnisse. Ein Blockieren fremder Zahlungen erwies sich damit als nicht praktikabel.

Mit xrpld 3.4.1 prüft die Payment Engine beim Summieren über Angebote auf Überlauf. Der betroffene Zahlungsteil scheitert dann mit einem gewöhnlichen Ergebnis wie „path dry“ oder „partial payment“, ohne dass XRP entsteht. Die Schlusskontrolle rechnet jetzt mit einem breiteren Zähler, der nach Angabe der Entwickler nicht überlaufen kann. Weitere Summenstellen wurden vorsorglich gehärtet.

Die Korrektur ging erstmals am Abstimmungsverfahren vorbei

Regeländerungen am XRP Ledger kommen normalerweise als Amendment. Ein Amendment gilt erst, wenn mehr als 80 Prozent der vertrauenswürdigen Validatoren es zwei Wochen lang unterstützen. Validatoren sind Server, die über den gültigen Stand des Ledgers mitentscheiden.

Die Überlaufkorrektur nahm den direkten Weg: Sie galt auf jedem Server, sobald er auf 3.4.1 aktualisiert war. Laut Bericht ist das die erste Änderung der Transaktionsverarbeitung seit Einführung des Amendment-Systems vor mehr als zehn Jahren, die bewusst so ausgeliefert wurde.

Die Entwickler begründen das mit der Zeit. Im Amendment-Verfahren wäre der Fix wochenlang öffentlich sichtbar gewesen, während der Fehler auf dem Mainnet ausnutzbar blieb.

Das Team nahm dafür ein Risiko in Kauf. In der Übergangszeit liefen alte und neue Versionen nebeneinander. Ein Angriffsversuch hätte dann nicht aktualisierte Server aus dem Takt bringen können, im schlimmsten Fall bis zum Stillstand des Netzes. Einen Stillstand hielt das Team für besser als einen fehlerhaften Ledgerzustand, der sich schwer zurückdrehen ließe.

Die Entwarnung kommt von den Entwicklern selbst

Gegen die beruhigende Lesart spricht, wer sie liefert. Die Entwickler stützen ihre Entwarnung auf eine eigene Suche, deren Methode sie nicht offenlegen. Eine unabhängige Stimme oder Auswertung des Ledgers liegt bislang nicht vor.

Dazu kommt der Ablauf des Updates. Mehr als 80 Prozent der Validatoren auf der Default-UNL, der empfohlenen Liste vertrauenswürdiger Validatoren, liefen laut Bericht schon am Veröffentlichungstag mit 3.4.1. Der Quellcode des Fixes war zu diesem Zeitpunkt noch unveröffentlicht.

Für die Entwickler spricht, dass der Quellcode von 3.4.1 inzwischen veröffentlicht ist; zum Release war er zurückgehalten worden. Das Amendment-Verfahren bleibt der Regelweg, halten sie fest. Die Ausnahme sei nur für schwerste Fehler gedacht und mit der XRPL Foundation, RippleX und Validatoren abgestimmt gewesen.

Für künftige Releases kündigt das Team einen zusätzlichen Prüfschritt an. Behobene Sicherheitsmeldungen sollen gegen den Release Candidate, die letzte Testfassung vor der Veröffentlichung, erneut getestet werden.

Serverbetreiber müssen auf 3.4.1, für Halter bleibt die Frage offen

Seit dem 9. Oktober 2026 ist auf dem Mainnet das Amendment fixBatchV1_2 aktiv. Es schließt eine separate Lücke in der Batch-Funktion. Server vor 3.4.1 sind seitdem amendment blocked: Sie kennen eine bereits aktivierte Regel nicht und können unter anderem keine Ledger mehr validieren und keine Transaktionen verarbeiten. Die Vorgeschichte steht im Artikel zum Batch-Amendment.

Für Betreiber heißt das: auf 3.4.1 oder neuer aktualisieren, um mit dem Netz synchron zu bleiben, wie es Bericht und Release Notes auf GitHub verlangen. Die Blockade folgt aus fixBatchV1_2. Die Überlaufkorrektur wirkte davon unabhängig auf jedem Server mit dessen Upgrade.

Die Upgrade-Aufforderungen in Bericht und Release Notes richten sich an Betreiber von XRP-Ledger-Servern. Zu Haltern ohne eigenen Server äußern sich die Quellen nicht, Stand 11. Oktober 2026.

Unterm Strich: Laut Bericht ließ bis Version 3.4.0 ein Rechenfehler neues XRP zu, und beide Schutzprüfungen liefen mit über oder ins Leere. Die Entwickler schlossen die Lücke bewusst ohne Amendment-Abstimmung, ihre Entwarnung ist eine Selbstauskunft. Für Serverbetreiber ist die Lage eindeutig: 3.4.1 oder neuer.

Woran du erkennst, ob die Entwarnung trägt: an einer unabhängigen Auswertung des Ledgers, an Hinweisen von Börsen oder Wallet-Anbietern an ihre Kunden und daran, ob weitere Änderungen am Amendment-Verfahren vorbei kommen. Ein zweiter Gradmesser ist der angekündigte Prüfschritt, der in den Angaben zu den nächsten Releases auftauchen sollte.