XRPL-Sicherheit nach Blockierung des xrpl Batch-Änderungsfehlers vor dem Mainnet verstärkt

Die XRPL Foundation hat ein ernsthaftes Problem im Zusammenhang mit der xrpl Batch-Änderung gestoppt, bevor es die Mainnet beeinflussen konnte, was die sich entwickelnde Sicherheitslage des Ledgers unterstreicht.

Kritischer Fehler während der Abstimmungsphase entdeckt

Die XRPL Foundation gab bekannt, dass eine kritische Schwachstelle in dem vorgeschlagenen Batch-Änderungsvorschlag identifiziert und vor der Aktivierung im Mainnet neutralisiert wurde. Der Fehler trat auf, während sich die Änderung noch in der Validator-Abstimmungsphase befand, was Entwicklern ermöglichte, rechtzeitig zu reagieren, bevor es zu Auswirkungen in der Produktion kam.

Das Problem wurde am 19. Februar 2026 von Sicherheitstechniker Pranamya Keshkamat zusammen mit Cantina AI’s autonomem Tool Apex entdeckt. Laut der Stiftung waren keine Nutzerfonds gefährdet, da die Änderung noch nicht im XRPL-Mainnet aktiviert war.

Die Änderung, offiziell bekannt als XLS-56, sollte gebündelte Transaktionen auf dem XRP Ledger einführen. Sie hätte ermöglicht, mehrere innere Transaktionen in einem einzigen Batch zusammenzufassen, um Effizienz und Koordination zu verbessern. Diese inneren Transaktionen wurden jedoch absichtlich unsigniert gelassen, wobei die Autorisierung an eine äußere Batch-Transaktion delegiert wurde, die die Signierer auflistet.

Wie der Fehler bei der Signaturüberprüfung funktionierte

Laut dem Nachruf der Stiftung lag die Schwachstelle in der Signaturvalidierungslogik der Batch-Funktion. Das Problem konzentrierte sich auf einen Schleifenfehler in der Signierer-Validierungsfunktion, die zur Überprüfung der Batch-Autorisierungen verwendet wurde.

Wenn das System auf einen Signatoreintrag stieß, der mit einem Konto verbunden war, das noch nicht im Ledger existierte, konnte es die Schleife vorzeitig verlassen. Wenn der Signierschlüssel mit dem neuen Konto übereinstimmte, wurde der Validierungsprozess fälschlicherweise als erfolgreich markiert. Das Software-Programm übersprang dann die Überprüfung aller verbleibenden Signatoreinträge im Batch.

Dieses Verhalten eröffnete eine Möglichkeit für unbefugte Transaktionen. Ein Angreifer konnte Operationen von Opferkonten ausführen, ohne deren private Schlüssel zu besitzen, da die Schlüsselüberprüfung für diese Konten umgangen werden konnte. Zum Zeitpunkt der Entdeckung befand sich die Änderung nur in der Abstimmungsphase der Validatoren und war auf dem Mainnet noch deaktiviert.

Die XRPL Foundation betonte, dass die Änderung noch nicht aktiviert war, und wiederholte: „Die Änderung befand sich in der Abstimmungsphase und war im Mainnet noch nicht aktiviert; keine Gelder waren gefährdet.“ Diese Zusicherung war entscheidend, um Marktbedenken zu begrenzen und die Vorteile rigoroser Voraktivierungstests hervorzuheben.

Potenzielle Auswirkungen des Batch-Änderungsfehlers

Das berichtete Exploit-Szenario erforderte eine sorgfältig konstruierte Batch-Transaktion. Ein Angreifer würde eine Batch erstellen, die drei innere Operationen enthält, um die fehlerhafte Logik bei der Signierer-Validierung auszunutzen.

Erstens würde eine innere Transaktion ein neues Konto erstellen, das vollständig vom Angreifer kontrolliert wird. Zweitens würde eine andere innere Transaktion eine einfache Überweisung oder Aktion von diesem neu erstellten Konto ausführen. Drittens würde eine Zahlung von einem ausgewählten Opferkonto auf das Konto des Angreifers erfolgen, um Gelder ohne legitime Autorisierung zu bewegen.

Zur Vervollständigung des Setups würde der Angreifer zwei Signatoreinträge in den Batch einfügen. Ein Signatoreintrag wäre für das neue, vom Angreifer kontrollierte Konto gültig. Der zweite Signatoreintrag würde fälschlicherweise die Transaktionsautorisierung für das Opferkonto beanspruchen. Aufgrund des vorzeitigen Schleifenabbruchs könnte das System jedoch den ersten Signator akzeptieren und den zweiten nie richtig validieren.

Infolgedessen könnte die Zahlung des Opfers ohne gültige Signatur ausgeführt werden, was das Ledger in einer Weise verändern würde, die das Opfer nicht genehmigt hat. Die XRPL Foundation warnte, dass die erfolgreiche Nutzung dieser Technik beliebige Gelderübertragungen und disruptive Änderungen im Ledger ermöglicht hätte, wenn sie in großem Maßstab eingesetzt worden wäre.

Darüber hinaus hob die Organisation das Risiko für das Vertrauen im breiteren Ökosystem hervor, falls ein solcher Exploit im Mainnet angekommen wäre. Cantina- und Spearbit-CEO Hari Mulackal kommentierte: „Unser autonomer Bug-Jäger Apex hat diesen kritischen Fehler gefunden.“ Ripple-Entwicklungsteams reproduzierten das Verhalten mit einem Proof-of-Concept und führten vor der Behebung des Fehlers vollständige Unit-Tests durch.

Notfallreaktion und rippled-Update

Nach der Offenlegung wurden die UNL-Validatoren der XRPL umgehend angewiesen, gegen den Batch-Vorschlag mit „Nein“ zu stimmen. Diese Koordination stellte sicher, dass die Änderung während der Behebung nicht versehentlich die Aktivierungsschwelle überschritt.

Am 23. Februar 2026 wurde eine Notfallsoftware-Version, rippled 3.1.1, veröffentlicht. Dieses Release markiert explizit sowohl die ursprüngliche Batch-Änderung als auch die related fixBatchInnerSigs-Änderung als nicht unterstützt. Folglich sind sie von Validator-Stimmen ausgeschlossen und können auf keinem Produktionsnetz aktiviert werden.

Die Notfallversion enthält nicht die endgültige korrigierte Logik. Stattdessen dient sie als Schutzbarriere, um zu verhindern, dass Batch oder fixBatchInnerSigs in ihrer fehlerhaften Form aktiviert werden. Dieser sofortige Schutz verschaffte den Entwicklern jedoch die notwendige Zeit, um eine sicherere Alternative zu entwerfen und zu überprüfen.

Eine korrigierte Änderung namens BatchV1_1 wurde nun als Nachfolger des ursprünglichen Designs implementiert. Dieses Update entfernt den vorzeitigen Schleifenabbruch bei der Signierer-Validierung und stärkt die Überprüfungen aller Autorisierungspfade. Die Stiftung bestätigte, dass diese Revision noch in Prüfung ist und kein Datum für die Einführung festgelegt wurde.

Stärkung der Sicherheitspraktiken des XRPL

Nach dem Vorfall skizzierte die XRPL Foundation zusätzliche Sicherheitsmaßnahmen, um die Entwicklungsprozesse zu härten. Außerdem plant sie, die Rolle von KI bei der Überprüfung von Protokolländerungen auszubauen, um subtile Logikfehler früher im Prozess zu erkennen.

Die Organisation beabsichtigt, den Einsatz KI-gestützter Code-Audits zu erhöhen, basierend auf dem Erfolg der Tools von Cantina AI und des Apex-Systems in diesem Fall. Zudem soll die statische Analyse erweitert werden, um Muster wie vorzeitige Erfolgsausgaben innerhalb von Schleifen gezielt zu erkennen, was zum Fehler in der Batch-Validierungslogik beigetragen hat.

Dabei betonte die Stiftung, dass die Episode um die xrpl Batch-Änderung die Bedeutung von mehrschichtigen Verteidigungen zeigt, einschließlich menschlicher Überprüfung, autonomer Analyse und gestufter Aktivierung. Durch die Kombination dieser Ansätze wollen die Verantwortlichen das Risiko unentdeckter Schwachstellen bei zukünftigen Protokoll-Updates verringern.

Letztlich hob die XRPL Foundation hervor, dass der kritische Fehler vor der Mainnet-Aktivierung und vor der Gefährdung von Geldern behoben wurde. Die frühzeitige Erkennung, die koordinierte Validatoren-Reaktion und die schnelle rippled-Notfallversion trugen dazu bei, unbefugte Transaktionen zu verhindern und die Integrität des XRPL-Netzwerks zu bewahren.