Die Entwickler des XRP Ledger haben einen Notfall-Sicherheitspatch veröffentlicht, um einen kritischen Fehler zu beheben, der böswilligen Akteuren hätte ermöglichen können, zusätzliche spendbare XRP zu erzeugen – trotz des festen Angebots von 100 Milliarden Token im Netzwerk.

Der Fix umging den üblichen zweiwöchigen Validator-Abstimmungsprozess des Ledgers – eine Entscheidung, die die Entwickler damit begründeten, dass eine Wartezeit potenziellen Angreifern Zeit gegeben hätte, die Schwachstelle auszunutzen. Der Patch wurde mit sofortiger Wirkung drei Tage nach der Meldung des Fehlers über das Bug-Bounty-Programm des Netzwerks ausgerollt, das Forscher für das verantwortungsvolle Melden von Sicherheitslücken belohnt. Die Entwickler erklärten, es handele sich um die erste absichtliche Umgehung des Änderungsprozesses seit mehr als zehn Jahren.

Die Reaktion hat seitdem eine ausführliche Diskussion darüber ausgelöst, wie das XRP Ledger mit kritischen Schwachstellen umgeht – und über sein Bekenntnis zur Dezentralisierung.

Notfall-Patch umging die Zustimmung der Validatoren

Protokolländerungen im XRP Ledger erfordern normalerweise mehr als 80 % Konsens unter den Validatoren über einen Zeitraum von zwei Wochen, bevor eine Änderung in Kraft tritt – eine Schwelle, die sicherstellen soll, dass Änderungen der Netzwerkregeln vor ihrer Aktivierung auf breite Zustimmung stoßen. Die Entwickler wiesen darauf hin, dass das Warten auf das Ergebnis einer Abstimmung über den Sicherheitspatch die Lücke für Ausnutzungen hätte offenlassen können.

Laut einem Blogbeitrag, den die XRP-Ledger-Entwickler am Sonntag veröffentlichten, hätte der normale Änderungsprozess den Fix mehrere Wochen lang offenlegen können, bevor die Änderung aktiviert würde, und somit das Netzwerk Gefahren aus können.

Während der Notfall-Patch eine schnelle Lösung brachte, wirft die Entscheidung, den regulären Prozess zu umgehen, Fragen über die Rolle auf, die Entwicklungsteams bei der Reaktion auf Sicherheitsvorfälle spielen.

Foundation stellt klar, dass kein XRP geschaffen wurde

Die XRP Ledger Foundation bemühte sich nach dem Fix, Verwirrung auszuräumen:

The recent XRP Ledger security fix raised a lot of questions and some misconceptions. Let's clear them up. 1. Was any XRP created? No. XRP's supply was fixed at 100 billion when the XRP Ledger launched, and no transaction is allowed to create more. This bug was a way around… — XRP Ledger Foundation (@XRPLF) October 11, 2026

Patch entfacht Debatte über Dezentralisierung

Die Notfallreaktion hat die Kontroverse darüber neu entfacht, ob das XRP Ledger dezentralisiert ist – eine Frage, die eines der Hauptthemen bei der rechtlichen Einordnung von XRP war. Der Grad der Kontrolle, den ein Kernteam über ein Netzwerk behält, ist ein wiederkehrendes Kriterium, wenn Regulierungsprüfer abwägen, wie ein digitaler Vermögenswert eingestuft werden sollte.

Justin Bons, Mitgründer von Cyber Capital, äußerte sich scharf kritisch zum Notfall-Update und argumentierte, das Gespräch über die Dezentralisierung von XRP sei irreführend:

Selling XRP to retail as "decentralized" is straight-up fraud! 🚩 XRP has been running closed-source code for the last two weeks Tomorrow, this code becomes mandatory & anyone who disagrees will get kicked off the chain! A permissioned node list means validators must obey: 🧵… pic.twitter.com/3nIcRiid8S — Justin Bons (@Justin_Bons) October 8, 2026

In seinem Beitrag behauptete Bons, das Netzwerk habe zwei Wochen lang Closed-Source-Code vor einem verpflichtenden Update ausgeführt, und eine genehmigte Knotenliste habe die Validatoren faktisch zur compliance gezwungen.

Ein weiteres Anliegen: Binärdistributionen sind ausführbare Dateien. Ohne die zeitnahe Veröffentlichung des zugrunde liegenden Quellcodes bleibt unabhängigen Entwicklern nur begrenzt Zeit, die vorgenommenen Änderungen zu analysieren.

Die XRP Ledger Foundation erklärte, der Notfall-Patch sei angesichts des Schweregrads des im Code gefundenen Fehlers von der Foundation, RippleX, den Entwicklern und den Validatoren „gemeinsam vereinbart“ worden. Sie betonte, dass niemand den Entscheidungsprozess diktiert habe und dass Betreiber weiterhin frei seien, welche Software sie auch immer verwenden möchten.

Der Validator-Betreiber XRP Kuwait unterstützte den Notfall-Patchprozess ebenfalls mit dem Hinweis, dass Zusammenarbeit nicht bedeutet Zentralisierung:

Our Statement on xrpld 3.4.1 At XRP Kuwait, our journey has always been about infrastructure and purpose. Our purpose is decentralization. We pursue that purpose through independently operated infrastructure and responsible participation in the XRP Ledger. Following the… pic.twitter.com/Oo7qClwpgi — XRPKuwait (@XRPKuwait) October 11, 2026

Die Kontroverse wirft erneut Fragen nach Transparenz und Rechenschaftspflicht bei Notfall-Patches auf.

Integer-Overflow in der Payment-Engine

Die Schwachstelle hinter dem Notfall-Patch wurde in einer Offenlegung des XRP-Ledger-Teams im Detail beschrieben. Laut demSchwachstellenbericht]() handelte es sich um einen Integer-Overflow in der Payment-Engine, der seit 2015 bestand. Integer-Overflows sind eine seit langem bekannte Klasse von Softwarefehlern, bei denen eine Berechnung den maximal speicherbaren Wert eines Systems überschreitet und auf eine viel kleinere Zahl zurückrollt; in diesem Fall lieferten Berechnungen oberhalb der festen Höchstgrenze kleinere Ergebnisse.

Ein Angreifer hätte den Fehler ausnutzen können, indem er Hunderte von Offers mit Forderungen nach riesigen XRP-Mengen im Gegenzug sendete. Nach der fehlerhaften Berechnung hätte der Angreifer diese Beträge erhalten, während der Käufer weniger als den erforderlichen Betrag gezahlt hätte – was potenziell zu zusätzlichen spendbaren XRP geführt hätte.

Da die Netzwerkregeln das gesamte XRP-Angebot beim Start auf 100 Milliarden Token festgelegt haben, hätte jeder Weg zur Erzeugung zusätzlicher spendbarer XRP eine zentrale Garantie des Ledgers untergraben – die Regel des festen Angebots, die der Knappheit des Assets zugrunde liegt.

Der Angriff erforderte speziell angefertigte Offers und konnte im normalen Handelsablauf nicht auftreten. Der Patch soll verhindern, dass dieser Rechenfehler genutzt wird, um die Angebotsregeln des Netzwerks zu umgehen.

RippleX weitet Sicherheitsbemühungen aus

RippleX beabsichtigt, die Sicherheit des XRP Ledger durch KI-gestützte Schwachstellenerkennung, adversariales Testen, formale Verifikation und Zusammenarbeit mit externen Sicherheitsexperten zu stärken.

Ziele dieser Bemühungen sind das Auffinden von Fehlern im Code, das Testen möglicher Angriffe und das Identifizieren von Schwachstellen, bevor sie ausgenutzt werden können. RippleX hat die Arbeit als Bestreben dargestellt, die Sicherheit des gesamten Codesystems zu verbessern, statt lediglich gefundene Schwachstellen zu beheben.

Abwägung zwischen Sicherheit und Transparenz

Der Notfall-Fix verdeutlicht die Herausforderung, blockchain Sicherheit zu wahren und gleichzeitig Transparenz bei Entscheidungen zu bewahren. Obwohl eine schnelle Umsetzung entscheidend ist, um sich vor potenziellen Angriffen zu schützen, wirft sie Fragen zu Governance-Prozessen und zum Zugriff auf den Quellcode auf.

Die Entwickler hielten fest, dass die Schwachstelle das Überspringen des Standardverfahrens notwendig gemacht habe, während die Foundation erklärte, die Koordination zwischen den Beteiligten habe die Unabhängigkeit der Validatoren nicht beeinträchtigt.

Der Vorfall unterstreicht die Notwendigkeit, Notfallprotokolle zu entwickeln, die schnelles Handeln mit der Offenheit des Netzwerks in Einklang bringen können.

Quelle: Tron Weekly