Ripple Labs veröffentlichte am 25. September xrpld 3.4.1, um zwei Schwachstellen in der XRP-Ledger-Serversoftware zu beheben. Die Fehler hätten die Erzeugung von XRP ohne ordnungsgemäße Deckung ermöglichen oder dazu führen können, dass Serverversionen Batch-Transaktionen unterschiedlich bewerten, was die Validierung neuer Ledger potenziell hätte stoppen können.
Das XRPL-Team erklärte, es habe keine Hinweise darauf gefunden, dass der Ganzzahlüberlauf in öffentlichen Netzwerken ausgenutzt wurde, während der Fehler bei Batch-Transaktionen das Mainnet nicht beeinträchtigen konnte, bevor das relevante Protokoll-Update aktiviert worden war.
Das XRP-Ledger-Blockchain-Team veröffentlichte einen Bericht zu den beiden Schwachstellen, die beide in xrpld 3.4.1 behoben wurden. Das Team verstärkte zudem die Kontrollen der Guthaben und plant, jede behobene Schwachstelle in neuen Release-Kandidaten erneut zu überprüfen, bevor die zugehörigen Berichte geschlossen werden.
Überlauf hätte ungedecktes XRP erzeugen können
Die erste Schwachstelle wurde am 22. September 2026 über das XRPL-Bug-Bounty-Programm entdeckt. Ein Ganzzahlüberlauf in der Zahlungs-Engine hätte einem Angreifer ermöglichen können, durch speziell gestaltete Angebote im Orderbuch und eine einzelne Zahlung XRP ohne ordnungsgemäße Deckung zu erzeugen.
Bei der Verarbeitung von Hunderten Angeboten konnte die Software XRP-Beträge fehlerhaft addieren. Statt einen Fehler zurückzugeben, konnte eine übermäßig große Summe in eine kleine Zahl umschlagen. Die Eigentümer der Angebote hätten weiterhin die vollen Beträge erhalten, während der Käufer einen deutlich geringeren Betrag gezahlt hätte.
Eine Standardprüfung, die verhindern soll, dass eine Transaktion neues XRP erzeugt, konnte wegen eines ähnlichen Überlaufs ebenfalls fehlschlagen. Das XRPL-Team schätzte, dass die Schwachstelle möglicherweise seit 2015 bestanden hatte, als die aktuelle Zahlungs-Engine eingeführt wurde.
Version 3.4.1 fügte Überlaufprüfungen bei der Berechnung von Gesamtsummen hinzu und weist ungültige Vorgänge zurück. Das Team erklärte, es gebe keine Hinweise darauf, dass die Schwachstelle in öffentlichen Netzwerken ausgenutzt wurde.
Fehler bei Batch-Transaktionen bedrohte Netzwerkkonsistenz
Die zweite Schwachstelle trat bei einer weiteren Überprüfung der Ergebnisse des Sherlock Attackathon zutage. Denis Angell von der XRPL Foundation bestätigte am 18. September, dass eine frühere Korrektur unvollständig war. Mayukha Vadari von RippleX stellte später fest, dass der Fehler dazu führen konnte, dass unterschiedliche Versionen der Serversoftware zu widersprüchlichen Schlussfolgerungen gelangen.
Das Problem betraf den Batch-Mechanismus, der bis zu acht Transaktionen in einem Batch bündeln kann. Der Server prüfte nicht, ob jede innere Transaktion im erforderlichen RawTransaction-Feld enthalten war. Unterschiedliche Versionen von xrpld konnten daher die Gültigkeit desselben Vorgangs unterschiedlich interpretieren, was unter bestimmten Bedingungen die Validierung neuer Ledger potenziell hätte stoppen können.
Das Team behob den Fehler durch das Update fixBatchV1_2, das am 9. Oktober im Mainnet aktiviert wurde. Vor dieser Aktivierung konnte das Problem nicht ausgenutzt werden, um das Mainnet zu beeinträchtigen, da die entsprechende BatchV1_1-Funktion inaktiv blieb.
Weitere XRPL-Sicherheitsarbeit
Ripple Labs arbeitete 2026 zudem daran, die Sicherheit zu stärken und die Fähigkeiten von XRPL auszubauen. Im März stellten RippleX-Forscher einen Ansatz für vertrauliche Transfers von Multi-Purpose-Token vor, der Nutzerdaten schützen soll.
Im April kündigte das Unternehmen einen mehrphasigen Plan an, um XRPL auf Bedrohungen durch Quantencomputing vorzubereiten, darunter einen Übergang zu Post-Quanten-Kryptografie bis 2028. Im Oktober begann Brasiliens CSD BR mit der ersten Phase einer Partnerschaft mit Ripple Labs, um Anteile an Investmentfonds von BTG Pactual auf XRPL zu tokenisieren.
Quelle: HODL Press
