XRP Ledger Notfall-Fix: Wer machte ihn ohne Abstimmung wirksam?

Der Notfall-Fix gegen den Überlauffehler im XRP Ledger griff ohne Abstimmung der Validatoren, und zwar auf jedem Server, der xrpld 3.4.1 installiert hatte. Am Release-Tag, dem 25. September 2026, waren das laut Offenlegungsbericht der Entwickler vom 9. Oktober 2026 bereits mehr als 80 Prozent der Default-UNL, also der empfohlenen Liste vertrauenswürdiger Validatoren, deren Stimmen zählen. Für dich heißt das: Die Lücke war schnell zu, der Schutz hing aber am raschen Upgrade der Betreiber.

Der Fix kam ohne Abstimmung, aber nicht ohne die Validatoren

Regeländerungen kommen im XRP Ledger normalerweise als Amendment ins Netz, also als Änderung, über die die Validatoren abstimmen, bevor sie für alle gilt. Den Überlauf-Fix lieferten die Entwickler stattdessen direkt mit der Software aus. Er griff ab dem Release Ende September 2026 auf jedem Server, sobald dessen Betreiber auf 3.4.1 aktualisiert hatte. Server mit älterer Version verarbeiteten die betroffenen Zahlungen bis zu ihrem Upgrade nach den alten Regeln.

Dazu kam die Form der Auslieferung. Wegen der Sicherheitsrelevanz erschien 3.4.1 zunächst nur als Binärpaket, also als fertiges Programm, dessen Bauplan noch nicht öffentlich war (Release-Ankündigung auf XRPL.org). Inzwischen ist der Quellcode veröffentlicht, auch auf GitHub im Release 3.4.1.

Wirksam wurde der Fix also mit jedem einzelnen Upgrade. Laut Bericht hatte die große Mehrheit der Default-UNL die neue Version schon am Release-Tag eingespielt, bevor der Quellcode des Fixes öffentlich war.

Die Entwickler sprechen von einer Premiere: Seit Einführung des Amendment-Systems vor mehr als zehn Jahren sei erstmals eine Änderung der Transaktionsverarbeitung bewusst auf diesem Weg ausgeliefert worden.

Was der Fix schließt, erklärt der Artikel zum Überlauffehler in xrpld 3.4.1. Kurz gefasst: Ein Überlauf in der Zahlungs-Engine von xrpld 3.4.0 und älter hätte es erlaubt, mit präparierten Offers und einer einzigen Zahlung neues, ausgebbares XRP zu erzeugen. Gemeldet wurde der Fehler am 22. September 2026.

So kommt eine Regeländerung sonst ins Netz, und darum ist 3.4.1 seit 9. Oktober Pflicht

Auf dem regulären Weg wird ein Amendment erst aktiv, wenn es zwei Wochen lang durchgehend von mehr als 80 Prozent der vertrauenswürdigen Validatoren unterstützt wird. Fällt die Zustimmung zwischendurch unter diese Schwelle, beginnt die Frist von vorn. So legt es die Amendment-Dokumentation von XRPL.org fest.

Ein Vergleich zeigt den Abstand. Regulär hätten die Betreiber erst aktualisieren, die Validatoren dann zustimmen und die Zustimmung danach zwei Wochen halten müssen. Der direkte Weg wirkte mit dem Upgrade, für die meisten Validatoren der Default-UNL also schon am Release-Tag.

Pflicht ist 3.4.1 trotzdem, allerdings über einen anderen Weg. Mit der Version kam das separate Amendment fixBatchV1_2 gegen einen zweiten Fehler bei gebündelten Batch-Transaktionen, aktiv auf dem Mainnet seit 9. Oktober 2026 (Hintergrund zum Batch-Amendment). Ältere Server sind seitdem amendment-blockiert: Sie können dem Netz nicht mehr folgen.

Die XRPL Foundation verteidigt das Vorgehen laut Cointelegraph so: 3.4.1 sei erst durch eine reguläre Abstimmung mit mehr als 80 Prozent Validator-Unterstützung über zwei Wochen verpflichtend geworden. Das trifft die Pflicht über das Batch-Amendment. Der Überlauf-Fix wirkte schon vorher auf jedem aktualisierten Server, ganz ohne Abstimmung.

Wie das Verfahren als Bremse dient, zeigte sich beim Batch-Fehler. Ripple und weitere Betreiber zogen ihre Stimmen für das Batch-Amendment BatchV1_1 zurück; die Zeitleiste des Berichts nennt Vet. Die Frist begann damit neu, sodass Batch erst nach dem Fix aktiv werden konnte.

Warum die Entwickler den kurzen Weg wählten und welchen Preis er hatte

Am Anfang stand die Einstufung des Funds. Die ursprüngliche Meldung vom 22. September 2026 führte ihn als „Major“. RippleX reproduzierte den Fehler, bestätigte die Ausgebbarkeit des erzeugten XRP und hob die Stufe auf „critical“.

Dazu kam, wie billig ein Angriff gewesen wäre. Laut Bericht reichten einige hundert XRP an Konto- und Offer-Reserven, die beim Entfernen der Objekte zurückfließen, plus übliche Transaktionsgebühren. Ein Angreifer kam also mit kleinem Startkapital aus.

Die Entwickler begründen den kurzen Weg mit der Zeit. Im Amendment-Verfahren wäre der Fix wochenlang öffentlich gewesen, bevor er wirkt: für Upgrades, Abstimmung und die zweiwöchige Frist. So lange wäre der Fehler auf dem Mainnet sichtbar und ausnutzbar geblieben.

Den Preis dieses Wegs benennen sie selbst. Solange das Netz aktualisiert wurde, folgten Server mit verschiedenen Versionen für diese Zahlungen verschiedenen Regeln. Ein Exploit-Versuch in diesem Fenster hätte Server auseinanderlaufen lassen und im schlimmsten Fall das Netz anhalten können.

Ihre Abwägung: Ein kurzes Fenster sei weit sicherer als eine wochenlang offene Lücke. Die Rechnung stand und fiel mit dem Tempo der Validatoren. Ein langsameres Upgrade hätte nach Darstellung der Entwickler das Risiko gemischter Versionen stark erhöht und ihre Begründung geschwächt.

Ist das zentrale Steuerung? Kritik, Gegenrede und der Fall Bitcoin 2018

Den schärfsten Einwand gibt Cointelegraph von Justin Bons wieder, dem Gründer von Cyber Capital. Er kritisierte, das Notfall-Release sei nur als Binärdatei gekommen, der Quellcode zeitweise zurückgehalten und Betreiber zum Upgrade gedrängt worden. Binärpaket und späterer Quellcode decken sich mit den Angaben der Entwickler; das Drängen ist seine Wertung.

Widerspruch kommt aus dem Kreis der Betreiber. Der Validator-Betreiber XRP Kuwait wies laut Cointelegraph zurück, dass koordinierte Upgrades zentrale Kontrolle belegten: Koordination sei nicht dasselbe wie Kontrolle.

Die Entwickler ziehen im Bericht selbst eine Linie. Änderungen der Transaktionsverarbeitung liefen weiter über Amendments. Auf das Verfahren zu verzichten, komme nur bei den schwersten Fehlern in Betracht, deren Ausnutzung schlimmer wäre als ein Netzwerkstopp. Das ist eine Absichtserklärung ohne festgeschriebenes Kriterium.

Einen Vergleich außerhalb der Parteien bietet Bitcoin 2018. Beim Inflationsfehler CVE-2018-17144 machten die Bitcoin-Core-Entwickler zunächst nur den weniger schweren Denial-of-Service-Anteil öffentlich, damit möglichst schnell aktualisiert wurde (Offenlegung von Bitcoin Core). Patches lagen binnen Stunden vor, ein Binärrelease binnen 36 Stunden, die volle Offenlegung folgte am 20. September 2018 (Bitcoin Optech).

Der Vergleich betrifft das Vorgehen bei Patch und Offenlegung. Ein Abstimmungsverfahren wie die Amendments des XRP Ledger hat Bitcoin nicht.

Was das für dich als XRP-Halter heißt und woran du die Zusage misst

Für dein XRP gilt mit Stand 9. Oktober 2026: Die Entwickler haben nach eigener Aussage keine Hinweise gefunden, dass der Fehler auf einem öffentlichen Netz ausgenutzt wurde.

Die XRPL Foundation formuliert es am 11. Oktober 2026 auf X kategorischer: Es sei kein XRP erzeugt worden, das Angebot sei beim Start auf 100 Milliarden XRP festgelegt worden. Der Bericht der Entwickler bleibt bei der vorsichtigeren Formel „keine Hinweise gefunden“.

Woran du die Zusage misst: Laufen künftige Änderungen der Transaktionsverarbeitung wieder über Abstimmungen der Validatoren, wie die Entwickler zusagen? Und bleibt der kurze Weg den schwersten Fehlern vorbehalten?

Der Maßstab ist dieser Fall: Der Überlauf-Fix griff mit dem Upgrade auf jedem Server, ganz ohne zweiwöchige Frist. Kommt ein weiteres Release dieser Art, prüfe die Begründung daran.

Das Release-Datum steht in den Quellen mal als 25., mal als 26. September 2026. Stand der Angaben: 12. Oktober 2026.