LONDON (IT BOLTWISE) – Entwickler des XRP Ledger haben einen Integer-Overflow im Payment-Engine-Code geschlossen, der theoretisch neue XRP hätte erzeugen können und damit den 100-Milliarden-Token-Cap verletzt. Der Fix erschien mit xrpld 3.4.1 am 25. September, nachdem die Schwachstelle am 9. Oktober öffentlich dokumentiert wurde. RippleX gab an, den Angriff reproduziert und dabei keine Hinweise auf eine Ausnutzung im öffentlichen Netzwerk gefunden zu haben. Zudem blieb die übliche Amendment-Phase beim Patch aus, um die Zeit bis zur Absicherung zu verkürzen.
Der Schutz einer festen Token-Anzahl ist bei öffentlichen Blockchains nicht nur ein wirtschaftliches Versprechen, sondern auch ein sicherheitstechnisches Designziel. Beim XRP Ledger spielt genau diese Verknüpfung aus „muss strikt endlich bleiben“ und „muss in jeder Transaktionsroutine korrekt rechnen“ jetzt eine zentrale Rolle: Laut einer veröffentlichten Schwachstellen-Darstellung haben Entwickler einen Integer-Overflow im Payment-Engine-Teil des Netzwerks behoben, der bei einer speziell konstruierten Abfolge von Orders rechnerisch XRP aus dem Nichts hätte erzeugen können. XRP wurde beim Start 2012 in einem Gesamtvolumen von 100 Milliarden ausgegeben; Institutionen und viele Use-Cases rund um das Ledger bauen auf diese harte Obergrenze als belastbares Fundament. Dass ein Bug trotz dieser Annahme überhaupt so lange im Codepfad existieren konnte, zeigt zugleich, wie anspruchsvoll es ist, Transaktionslogik und mathematische Invarianten über lange Wartungszyklen hinweg fehlerfrei zu halten.
Technisch konkret saß die Verwundbarkeit in der Overflow-Behandlung bei Zahlungen, die mehrere Angebote (Offers) der integrierten Exchange-Schicht konsumieren. Wenn ein Käufer viele Offers in einer einzelnen Zahlung „abarbeitet“, summiert die Software die geschuldete Menge über 64-Bit-Integer-Addition – ohne die notwendige Prüfung auf Überlauf. Das Ergebnis lässt sich als klassischer Wraparound-Effekt beschreiben: Überschreitet die Zwischensumme den maximal darstellbaren Bereich, wird sie modulo des Zahlenbereichs „zurückgewickelt“ auf einen deutlich kleineren Wert. In der Folge wären die Offer-Inhaber in voller Höhe ausgezahlt worden, während der Käufer nur den „gewrappten“ Betrag belastet bekäme. Für Angreifer entsteht dadurch eine Möglichkeit, neu berechnetes XRP in ihren Konten gutzuschreiben, das dann in einer nachgelagerten Folge-Transaktion direkt verwendbar wird.
Bemerkenswert ist dabei nicht nur das Rechenproblem, sondern auch, warum mehrere Schutzmechanismen die Manipulation nicht rechtzeitig abfingen. Zwei Checks hätten den Fehler eigentlich sichtbar machen müssen: Eine „no XRP created“-Invariante, die Netto-Bilanzänderungen konsistent prüfen soll, summiert im beschriebenen Fall offenbar identisch um – der gleiche Wraparound taucht also sowohl in der erwarteten als auch in der gemessenen Bilanzlogik auf und „maskiert“ so den Fehler. Dazu kommt eine per-Konto-Balance-Prüfung, die dem Bericht zufolge nur anspringt, wenn ein einzelnes Konto mehr hält als die Gesamtmenge des Systems. Die Angriffsstrategie konnte diesen Grenzfall vermeiden, indem sie die neu gutgeschriebenen Beträge über viele Konten verteilte, wodurch die Prüfung nicht triggert. Damit wird ein Muster sichtbar, das in vielen Sicherheitsanalysen in Finanzsystemen auftaucht: Ein Check ist nur so stark wie seine Annahmen über die typische Fehlerverteilung – und spezialisierte Adversaries versuchen genau diese Annahmen zu durchbrechen.
Der Patch selbst erschien als Software-Release „xrpld 3.4.1“ am 25. September, die öffentliche Dokumentation folgte am 9. Oktober. Für die Meldung wird beschrieben, dass der Bug am 22. September über das XRPL Bug-Bounty-Programm gemeldet wurde; die Autoren der Meldung nannten dabei sowohl einen Researcher als auch ein KI-gestütztes Analyseangebot. Aus der technischen Aufbereitung geht hervor, dass RippleX den Ablauf auf einer isolierten Standalone-Umgebung nachgestellt und dabei bestätigt hat, dass die neu erzeugten XRP anschließend tatsächlich transferiert werden konnten. Gleichzeitig meldete RippleX nach eigenen Angaben keine Belege dafür, dass der Fehler jemals auf einem öffentlichen Netzwerk ausgenutzt wurde. Besonders interessant ist die Priorisierung der Fix-Implementierung: Die Schwere wurde von „major“ auf „critical“ angehoben, weil die Attacke nach dem beschriebenen Modell günstig war, keine besonderen Zugriffsrechte voraussetzte und direkt spendbares Ergebnis liefern konnte.
Normalerweise durchläuft das XRP Ledger Transaktionslogik eine Amendment-Phase: Eine neue Regel bleibt zunächst inaktiv und aktiviert sich erst, wenn mehr als 80 Prozent der als „trusted“ eingestuften Validatoren sie für zwei Wochen unterstützen. RippleX griff hier jedoch nach eigener Darstellung erstmals seit der Einführung dieses Prozesses mehr als zehn Jahre zuvor zu einer Abkürzung und ließ die übliche Amendment-Route aus. Die Begründung ist nachvollziehbar: Ein Publish-Mechanismus über den Standardweg hätte zwar die Transparenz des Fix erhöht, gleichzeitig aber eine Zeitspanne eröffnet, in der die verwundbaren Logikpfade auf Mainnet weiterhin erreichbar gewesen wären. Für Angreifer wäre „sichtbarer Code, aber weiterhin nutzbar“ genau die Art von Fenster, die man vermeiden will, wenn die Attacke keinen Zugriff auf interne Schlüssel oder Sonderrollen benötigt. Das erhöht allerdings das Risiko eines temporären Mischversionen-Zustands, bis genügend Validatoren die neue Version fahren; laut Bericht sollte dieses Risiko aber begrenzt sein, weil normale Transaktionen den gefährdeten Codepfad nicht erreichen.
Für die Markt- und Vertrauensdimension ist die Episode deshalb mehr als nur ein „Bugfix“, weil sie die Wertthese des Ledgers direkt berührt: Wenn ein System seine Token-Endlichkeit mathematisch beweisen will, müssen selbst Randbedingungen in der Auszahlungslogik zu den Invarianten passen. In der Schwachstellenbeschreibung wird zudem betont, dass der Zahlungscode den beschriebenen Zustand seit der Erstellung des aktuellen Payment-Engines im Jahr 2015 tragen konnte, ohne dass RippleX Hinweise auf eine reale Ausnutzung im öffentlichen Betrieb gefunden hat. Parallel zum Overflow-Fix wurde mit demselben Release auch ein separater Validierungsfehler im Batch-Transaktionswrapper geschlossen, der am 9. Oktober auf Mainnet aktiviert wurde. Ebenso wichtig: RippleX kündigt an, Sicherheitsfindungen, die als „fixed“ markiert sind, vor dem Rollout künftig erneut gegen das Release Candidate Build zu verifizieren. Gerade im Kontext einer weiter zunehmenden institutionellen Ausrichtung – etwa Permission-Delegation für Banken und Stablecoin-bezogene Funktionalität – wird dieser zusätzliche „Re-Test“-Schritt zu einem praktischen Teil des Engineering-Prozesses, nicht zu einer reinen Dokumentationsübung.
Auch für Betreiber und Integratoren liefert der Fall eine klare Lehre: Sicherheitsrelevante Fehler können in scheinbar „internen“ Pfaden entstehen, sobald Summen über feste Integerbreiten gebildet werden, ohne dass Overflow-Semantik überall konsistent abgefangen wird. In der Praxis bedeutet das, dass Testsysteme nicht nur den typischen Transaktionsmix abdecken sollten, sondern gezielt Grenzwerte rund um 64-Bit-Grenzen und die Interaktion mit Exchange-Mechaniken prüfen müssen. Für Teams, die auf dem XRP Ledger aufbauen, erhöht das zudem die Bedeutung schneller Update-Zyklen: Selbst wenn der Fix durch standardisierte Amendment-Mechanismen eigentlich „sauber“ verteilt werden kann, zeigt der Bericht, dass bei kritischen, sofort missbrauchbaren Rechenfehlern der Zeitfaktor die Sicherheitsentscheidung bestimmt. Im Ergebnis bleibt der 100-Milliarden-Cap als zentrale Kennzahl besser geschützt – und das Netzwerk bekommt gleichzeitig ein neues Detail an die Hand, wie sich Invarianten und konkrete Implementierungsdetails gegenseitig beeinflussen.
Schließlich ist die Einordnung auch für die Kommunikationspraxis relevant. Der veröffentlichte Hinweis enthält einen allgemeinen Informations- und Risikokontext, der typische Verbraucher- und Haftungsaussagen in Bezug auf digitale Vermögenswerte aufgreift, ohne daraus finanzielle Empfehlungen abzuleiten. Für Leser heißt das: Die technische Veröffentlichung hilft, Risiken besser zu verstehen, ersetzt aber keine eigene Prüfung der Auswirkungen auf Systeme, Abhängigkeiten und Betriebsprozesse. Wer Ledger-Komponenten betreibt oder Anwendungen integriert, sollte den beschriebenen Patchpfad und die Release-Reihenfolge als Bestandteil seines Sicherheits- und Update-Managements behandeln.
💳 Amazon-Kreditkarte mit 2.000 Euro Limit bestellen!
🔥 Heutige Hot Deals bei Amazon: Bis zu 80% Rabatte!
🎉 Amazon Haul-Store für absolute Schnäppchenjäger!
- ★ 23-stufiges KI-Go-Training – Für Spieler mit Grundkenntnissen der Regeln – Entwickelt als intelligenter Trainingspartner passt sich die KI Spielern von 18K bis 9D an. Ideal für alle, die die Grundregeln bereits beherrschen und ihr Spiel verbessern möchten.
- IHR EMOTIONALER AI-BEGLEITER: Eiliko ist mehr als nur ein Anhänger, es ist ein charismatischer KI-Freund. Mit einem dynamischen LED-Bildschirm, der eine Vielzahl von animierten Gesichtern und Ausdrucksformen anzeigt, reagiert er auf Ihre Interaktionen mit einzigartiger Persönlichkeit und Charme.
- 【MEHR LEBEN FÜR DEINEN SCHREIBTISCH】 Lerne Eilik kennen – deinen kleinen Roboter-Freund mit Persönlichkeit. Mit liebevollen Animationen, ausdrucksstarken Reaktionen und spielerischen Interaktionen bringt Eilik mehr Freude in deinen Alltag. Ob auf dem Schreibtisch, im Büro oder am Nachttisch – Eilik wird schnell zu einem vertrauten Begleiter für besondere Momente.
- 【XL-Größe für gedeihende Pflanzen】Geben Sie Ihren Pflanzen den Raum, den sie verdienen! Unser verbessertes, großes 13,7 cm großes Design bietet Platz für Pflanzen mit einem Durchmesser von bis zu 8,9 cm und damit deutlich mehr Platz für Wurzelwachstum und Pflanzengesundheit im Vergleich zu kleineren, veralteten Modellen. Die Produktabmessungen betragen 13,6 x 13,6 x 13,2 cm und das Gerät wiegt nur 355 g.
- V28 Update - JETZT MIT NEUEN FUNKTIONEN! Als Reaktion auf das Ladeproblem von Loona haben wir das automatische Aufladen 2.0 verbessert. Diese Optimierung hilft Loona, die Ladewege in verschiedenen Szenarien zu erkennen und anzupassen, um die Erfolgsquote beim automatischen Aufladen zu erhöhen. Mobile Hotspots können sich mit Loona verbinden und überwinden WLAN-Einschränkungen, sodass Sie jederzeit und überall mit Loona interagieren können.
- Die besten Bücher rund um KI & Robotik!
- Die besten KI-News kostenlos per eMail erhalten!
- Zur Startseite von IT BOLTWISE® für aktuelle KI-News!
- IT BOLTWISE® kostenlos auf Patreon unterstützen!
- Aktuelle KI-Jobs auf StepStone finden und bewerben!
- Künstliche Intelligenz: Dem Menschen überlegen – wie KI uns rettet und bedroht | Der Neurowissenschaftler, Psychiater und SPIEGEL-Bestsellerautor von »Digitale Demenz«
Du hast einen wertvollen Beitrag oder Kommentar zum Artikel "XRP Ledger behebt Integer-Overflow-Bug und schützt den 100-Milliarden-Cap" für unsere Leser?
#Sophos
#AmazonPrime
#Bestseller
Es werden alle Kommentare moderiert!
Für eine offene Diskussion behalten wir uns vor, jeden Kommentar zu löschen, der nicht direkt auf das Thema abzielt oder nur den Zweck hat, Leser oder Autoren herabzuwürdigen.
Wir möchten, dass respektvoll miteinander kommuniziert wird, so als ob die Diskussion mit real anwesenden Personen geführt wird. Dies machen wir für den Großteil unserer Leser, der sachlich und konstruktiv über ein Thema sprechen möchte.
Du willst nichts verpassen?
Du möchtest über ähnliche News und Beiträge wie "XRP Ledger behebt Integer-Overflow-Bug und schützt den 100-Milliarden-Cap" informiert werden? Neben der E-Mail-Benachrichtigung habt ihr auch die Möglichkeit, den Feed dieses Beitrags zu abonnieren. Wer natürlich alles lesen möchte, der sollte den RSS-Hauptfeed oder IT BOLTWISE® bei Google News wie auch bei Bing News abonnieren.
Nutze die Google-Suchmaschine für eine weitere Themenrecherche: »XRP Ledger behebt Integer-Overflow-Bug und schützt den 100-Milliarden-Cap« bei Google Deutschland suchen, bei Bing oder Google News!