XRPL-Bericht: Der Überlauf-Fix in 3.4.1 umging die Amendment-Abstimmung – zum ersten Mal
Victoria Shinder3 Min. LesezeitAls xrpld 3.4.1 am 25. September als Notfall-Release erschien, hieß es in den Notes nur, man behebe sicherheitsrelevante Probleme, Einzelheiten folgten. Sie kamen am 9. Oktober in einem Vulnerability Disclosure Report auf xrpl.org – am selben Tag, an dem das zugehörige Amendment aktiv und der Quellcode von 3.4.1 veröffentlicht wurde. Der Bericht behandelt zwei Fehler. Der zweite verändert, wie der XRP Ledger bisher funktioniert hat.
Fehler eins: Batch-Transaktionen im falschen Wrapper. Mit Batch (XLS-56) kann ein Konto bis zu acht Transaktionen als Einheit einreichen. Laut Spezifikation muss jede innere Transaktion in einem Feld RawTransaction stecken; der Server prüfte das nicht. Ursprünglich als Attackathon-Fund mit niedrigem Schweregrad erfasst und für behoben gehalten, stellte sich am 18. September heraus, dass der Fix unvollständig war. Am 22. September zeigte Mayukha Vadari von RippleX, dass Server verschiedener Versionen sich dadurch uneinig werden konnten – der Fehler wurde zum Blocker hochgestuft. Batch war auf dem Mainnet nicht aktiv, Gelder waren nicht betroffen. Validatoren, darunter Ripple, zogen ihre Stimmen für BatchV1_1 zurück, um dessen Aktivierungsuhr zurückzusetzen, lieferten die neue Prüfung als Amendment fixBatchV1_2 aus und stimmten danach wieder für Batch – rund 30 Minuten hinter dem Fix. Beide wurden am 9. Oktober aktiv; Server älter als 3.4.1 sind jetzt amendment-blocked.
Fehler zwei: XRP aus dem Nichts. Ein Forscher – genannt werden Cayden Liao und Veria AI – meldete am 22. September über das Bug-Bounty-Programm einen Ganzzahlüberlauf in der Payment-Engine, mit dem sich neue, ausgebbare XRP erzeugen ließen. Verbrauchte eine einzige Zahlung sehr viele Angebote, konnte die laufende Summe den Wertebereich einer 64-Bit-Zahl überschreiten und überlaufen; der Zahlende wurde dann mit weit weniger belastet, als die Anbieter erhielten. RippleX reproduzierte das noch am selben Tag und stufte es als kritisch ein. Der Fehler stammt laut Bericht vermutlich aus dem Jahr 2015, als die heutige Payment-Engine geschrieben wurde; Hinweise auf Ausnutzung in einem öffentlichen Netz gibt es keine.
Der Präzedenzfall. Regeländerungen an der Transaktionsverarbeitung laufen beim XRP Ledger normalerweise über ein Amendment: Es wird inaktiv ausgeliefert und erst eingeschaltet, wenn mehr als 80 % der vertrauenswürdigen Validatoren es zwei Wochen lang unterstützen – so wechseln alle Server die Regeln beim selben Ledger. Dieser Fix tat das nicht. Er wirkte auf jedem Server, sobald dieser auf 3.4.1 aktualisiert war. Laut Bericht ist es die erste bewusst so ausgelieferte Änderung der Transaktionsverarbeitung, seit es das Amendment-System gibt – seit mehr als zehn Jahren. Die Begründung steht ausdrücklich da: Ein Open-Source-Fix verrät den Fehler, und der Amendment-Zeitplan hätte ihn wochenlang öffentlich und auf dem Mainnet ausnutzbar gelassen.
Das bewusst eingegangene Risiko – und warum es aufging. Solange Server unterschiedliche Versionen fuhren, hätte ein Ausnutzungsversuch das Netz in Server spalten können, die ihn annehmen, und solche, die ihn ablehnen; gewöhnliche Zahlungen berühren diesen Codepfad nie. Tragbar wurde das laut Bericht durch Tempo: Mehr als 80 % der Validatoren der Standard-UNL liefen am Tag des Releases mit 3.4.1, noch bevor der Quellcode öffentlich war. Die Autoren betonen, dass das Amendment-Verfahren die Regel bleibt und der Umweg nur für Fehler gilt, die schlimmer sind als ein Netzstillstand.
Was sich jetzt ändert. Jeder als behoben markierte Sicherheitsfund – aus Audits, Bounties oder KI-Red-Teaming – soll künftig gegen jeden Release-Kandidaten erneut getestet und erst geschlossen werden, wenn ein Test besteht, der den ursprünglichen Fund nachstellt. Anlass ist der unvollständige Batch-Fix.
Quelle: XRPL.org, Vulnerability Disclosure Report, 9. Oktober 2026 — https://xrpl.org/blog/2026/vulnerabilitydisclosurereport-bug-20261009 ; frühere Release Notes — https://xrpl.org/blog/2026/xrpld-3.4.1