Von AI entdeckter Fehler im XRP Ledger eröffnete einen Weg zur Prägung von 18,45 Billionen XRP
Veria AI entdeckte einen Fehler im XRP Ledger, mit dem sich nach Angaben von Forschern 18,45 Billionen XRP hätten prägen lassen – trotz des festen Gesamtangebots der Kryptowährung von 100 Milliarden.
Der Exploit kombinierte fehlerhafte Arithmetik in der Zahlungs-Engine des Ledgers mit einer Sicherheitsprüfung, die denselben Fehler wiederholte. Eine speziell konstruierte Zahlung hätte Hunderte Verkäuferkonten gutschreiben können, während dem Käufer nahezu nichts berechnet worden wäre.
RippleX reproduzierte den Exploit, stufte ihn als kritisch ein und veröffentlichte am 25. September 2026 xrpld 3.4.1. Laut der offiziellen Offenlegung fanden die Ermittler keine Hinweise darauf, dass jemand die Schwachstelle in einem öffentlichen Netzwerk ausgenutzt hat.
Diese Unterscheidung ist wichtig. Es handelte sich weder um einen Diebstahl von 18 Billionen XRP, noch hätte der theoretische Betrag einen tatsächlich realisierbaren Marktwert gehabt. Es war jedoch ein glaubwürdiger Weg, die zentrale Angebotsregel von XRP zu verletzen.
Der Vorfall prüft zudem ein weiterreichendes Versprechen rund um AI-gestützte Sicherheit. Offenbar entdeckte ein AI-Agent einen jahrzehntealten Fehler, den Audits und herkömmliche Tests übersehen hatten. Dennoch mussten menschliche Forscher das Ergebnis validieren, eine vertrauliche Behebung koordinieren und Validatoren zum Upgrade bewegen.
Der Fehler im XRP Ledger wurde vor der öffentlichen Offenlegung behoben
Die unmittelbare Geschichte ist eine erfolgreiche Notfallreaktion auf eine Schwachstelle, die fast ein Jahrzehnt lang erreichbar geblieben war.
Veria Labs zufolge richtete das Unternehmen seinen Sicherheitsagenten auf rippled, die Open-Source-Serversoftware des XRP Ledger. Das Unternehmen sagt, sein System habe den verwundbaren Code identifiziert, einen funktionierenden Exploit entwickelt und ihn in einem lokalen Netzwerk getestet.
Die technische Rekonstruktion des Unternehmens datiert den ersten AI-Fund auf den 21. September. Laut Veria erzeugte das System am folgenden Tag einen funktionierenden Proof of Concept.
Der Forscher Cayden Liao prüfte das Ergebnis und meldete es am 22. September über das XRPL-Bug-Bounty-Programm. Ingenieure von RippleX bestätigten das Problem noch am selben Tag, nachdem sie es auf einem eigenständigen Server und innerhalb ihres Test-Frameworks reproduziert hatten.
Die Bestätigung ging über den Nachweis einer Buchhaltungsabweichung hinaus. RippleX stellte fest, dass die neu erzeugten XRP in einer späteren Zahlung übertragen werden konnten, wodurch das Ergebnis praktisch ausgabefähig war.
Entwickler führten am 23. September einen Fix zusammen und veröffentlichten zwei Tage später rippled 3.4.1. Mit der öffentlichen Offenlegung warteten sie bis zum 9. Oktober, nachdem Betreiber Zeit erhalten hatten, die reparierte Software zu installieren.
Veria zufolge nutzten am 25. September mehr als 80 Prozent der Validatoren die Veröffentlichung. Das offizielle XRPL-Konto berichtet ebenfalls, dass an diesem Tag über 80 Prozent der Validatoren auf der Standard-Unique-Node-List ein Upgrade durchgeführt hatten.
Eine Unique Node List oder UNL identifiziert die Validatoren, denen ein Server bei der Bewertung des Konsenses vertraut. Die schnelle Übernahme unter diesen Validatoren verringerte die Gefahr, dass ältere Nodes die anfällige Transaktion weiterhin akzeptierten.
Die Reaktion wich vom üblichen Weg zur Änderung des Transaktionsverhaltens ab. XRPL führt konsenssensible Änderungen normalerweise durch Amendments ein, die Validatoren vor der Aktivierung prüfen.
Die Entwickler nahmen die Overflow-Behebung stattdessen direkt in die Serververöffentlichung auf. Die relevanten Quellcodeänderungen hielten sie vorübergehend zurück, um die Wahrscheinlichkeit zu begrenzen, dass Angreifer die Schwachstelle zurückentwickeln konnten, bevor ausreichend viele Validatoren ein Upgrade durchgeführt hatten.
Diese Entscheidung konzentrierte das Vertrauen für einen kurzen Zeitraum bei Maintainerinnen, Maintainer und Validator-Betreibern. Sie verhinderte zugleich, dass ein öffentlicher Amendment-Prozess zu einer Anleitung für einen unmittelbar ausnutzbaren Inflationsfehler wurde.
Dem offiziellen Bericht zufolge hielten die XRPL Foundation, RippleX und beteiligte Validatoren das vertrauliche Upgrade für sicherer, als einen offenen Exploit über Wochen verfügbar zu lassen. Der Fix wurde veröffentlicht, nachdem das Netzwerk die erforderliche Sicherheitsschwelle überschritten hatte.
Veria erhielt am 8. Oktober die maximale kritische Prämie von 250.000 US-Dollar. Der Betrag würdigt die Schweregradbewertung, sollte jedoch nicht mit einem bezifferten Verlust verwechselt werden.
Es wurden keine unautorisierten XRP gefunden, keine fehlenden Nutzergelder gemeldet und keine öffentliche Ledger-Transaktion mit dem Exploit in Verbindung gebracht. Der Notfall betraf, was der Code akzeptierte – nicht bereits beobachtete Schäden.
Dieses Ergebnis macht es leicht, das Ereignis herunterzuspielen. Das Ausbleiben einer Ausnutzung mindert jedoch nicht die Bedeutung eines Fehlers, der die Annahme eines festen Angebots des Assets hätte ungültig machen können.
Wie der Fehler im XRP Ledger ausgabefähige XRP erzeugen konnte
Der Exploit funktionierte, weil zwei monetäre Schutzvorkehrungen anfällige Berechnungen nahezu auf dieselbe Weise durchführten.
Der erste Fehler trat in der Behandlung von Angeboten aus der integrierten dezentralen Börse des XRP Ledger durch die Zahlungs-Engine auf. Angebote ermöglichen Konten den Tausch von XRP oder ausgegebenen Assets über die Orderbücher des Ledgers.
Ein Angreifer hätte zunächst zahlreiche kontrollierte Konten erstellen und einen wertlosen Token ausgeben müssen. Diese Konten hätten dann Hunderte künstliche Angebote platziert, die für diesen Token extrem hohe XRP-Beträge verlangten.
Der Proof of Concept von Veria nutzte 256 Angebote. Jedes verlangte etwas mehr als 2^56 Drops, wobei ein Drop einem Millionstel XRP entspricht.
Anschließend hätte der Angreifer eine einzelne Zahlung übermitteln müssen, die die gesamte Sammlung von Angeboten verbraucht. Die Zahlungs-Engine musste die jedem Angebot zugeordneten XRP-Beträge addieren, bevor sie dem Käufer etwas berechnete.
Diese Summe überschritt die Kapazität der für die Berechnung verwendeten vorzeichenlosen 64-Bit-Ganzzahl. Ein Integer-Overflow tritt auf, wenn ein Wert sein zulässiges Maximum überschreitet und auf eine deutlich kleinere Zahl zurückspringt.
Hier überschritt die Gesamtsumme 2^64 Drops. Die einzelnen Angebotsinhaber hätten ihre vollständigen Beträge erhalten können, während der Overflow die kombinierte Belastung des Käufers als lediglich 256 Drops erscheinen ließ.
Dies war schwerwiegender als ein fehlerhafter Wechselkurs. Die gutgeschriebenen Salden stellten XRP dar, die kein Quellkonto bereitgestellt hatte.
Das Ergebnis betrug ungefähr 18.446.744.073.709 XRP, vor Berücksichtigung der Belastung des Quellkontos und der Transaktionsgebühr. Veria fasst den nutzbaren Ertrag als etwa 18,45 Billionen XRP auf 256 Konten zusammen.
Diese Verteilung war entscheidend. XRPL begrenzt die XRP-Menge, die ein einzelnes Konto halten darf, doch jeder Empfänger blieb unter dieser Obergrenze.
Der Angriff umging daher eine Schutzvorkehrung, indem die neuen XRP auf viele Konten verteilt wurden. Forscher sagen, die gutgeschriebenen XRP hätten anschließend über gewöhnliche Zahlungen bewegt oder an Börsen transferiert werden können.
XRPL verfügte außerdem über eine Invariante, die genau dieses Ergebnis verhindern sollte. Eine Invariante ist eine Sicherheitsbedingung nach der Transaktion, die weiterhin erfüllt sein muss, bevor das Ledger eine Änderung akzeptiert.
Die Invariante XRPNotCreated berechnete die Nettoveränderung des XRP-Guthabens über die Transaktion hinweg. Sie hätte jedes Ergebnis zurückweisen sollen, das zeigte, dass die Transaktion mehr XRP erzeugte, als sie durch Gebühren zerstörte.
Diese Berechnung verwendete jedoch Arithmetik, die für denselben Overflow anfällig war. Die Nettoveränderung lief über, bis sie einer gewöhnlichen Gebührenverbrennung ähnelte, wodurch die Transaktion passieren konnte.
Tatsächlich berechnete die Zahlungs-Engine falsch, was der Käufer schuldete. Die unabhängig wirkende Angebotsprüfung wiederholte dann den mathematischen Fehler und genehmigte das falsche Ergebnis.
Dieses gemeinsame Versagen ist die zentrale Design-Lehre. Eine Backup-Kontrolle bietet nur begrenzten Schutz, wenn sie auf demselben Datentyp, demselben arithmetischen Verhalten oder derselben Annahme basiert wie die Komponente, die sie überwacht.
Der Angriff war nichts, was ein gewöhnlicher Trader versehentlich hätte auslösen können. Er erforderte Hunderte bewusst bepreiste Angebote und eine Zahlung, die darauf ausgelegt war, sie gemeinsam zu verbrauchen.
Er erforderte zudem einige XRP für Konto- und Angebotsreserven sowie Transaktionsgebühren. Der Schwachstellenbericht schätzt den Bedarf auf einige Hundert XRP, wobei sich die meisten Reserven anschließend zurückholen ließen.
Der Angreifer musste keinen Validator kontrollieren. Nach Vorbereitung und Signierung wäre die Exploit-Transaktion als ansonsten gewöhnliche Zahlung ins Netzwerk gelangt.
Der Angriff war außerdem wiederholbar. Zusätzliche Gruppen kontrollierter Konten hätten das Setup erneut erstellen und eine weitere Charge von 18,45 Billionen XRP ermöglichen können.
Die Behebung führte Overflow-Prüfungen in den Code zum Addieren der Angebote ein. Eine Summe, die den zulässigen Bereich überschreitet, schlägt nun fehl, statt auf eine geringe Belastung zurückzuspringen.
Entwickler erweiterten außerdem den Akkumulator, der von der Angebotsinvariante verwendet wird. Weitere Pfade zur Summierung von Guthaben erhielten verwandte Härtungen, um die Wahrscheinlichkeit eines weiteren gemeinsamen arithmetischen Fehlers zu verringern.
Ein festes Angebot machte den potenziellen Schaden systemisch
Das tatsächliche Risiko war nicht der unrealistische Nennwert von 18,45 Billionen XRP, sondern die Glaubwürdigkeit jeder bereits zirkulierenden legitimen Einheit.
XRP startete mit einem Gesamtangebot von 100 Milliarden Token. Es wird weder durch Mining noch durch Staking erzeugt, und gewöhnliche Transaktionsgebühren zerstören im Laufe der Zeit kleine Mengen.
Dieses Design gibt Nutzern eine einfache monetäre Erwartung. Transaktionen können XRP umverteilen, sollten das Gesamtangebot aber niemals erhöhen.
Der Fehler im XRP Ledger verletzte diese Regel auf der Buchhaltungsebene. Bei einer Ausnutzung hätte er neu geschaffene XRP in normale Konten einbringen können, ohne diese Guthaben sichtbar als anders zu kennzeichnen.
Der gemeldete Ertrag von 18,45 Billionen entsprach etwa dem 184-Fachen des ursprünglichen Angebots. Die Multiplikation dieser Menge mit dem Marktpreis ergibt jedoch ein irreführendes Maß für den wirtschaftlichen Schaden.
Ein Angreifer hätte nicht Billionen XRP zum Preis vor dem Angriff verkaufen können. Die verfügbare Liquidität wäre verschwunden, Börsen hätten den Handel aussetzen können, und der Preis hätte reagiert, lange bevor die meisten Token einen Käufer erreicht hätten.
Der aussagekräftigere Bezugspunkt war die Marktkapitalisierung von XRP von rund 94 Milliarden US-Dollar, als Veria die Schwachstelle bewertete. Sie repräsentierte den Wert, dessen zugrunde liegende Knappheitsannahme unter Druck stand.
Auch diese Zahl ist keine garantierte Verlustschätzung. Marktkapitalisierung entspricht nicht dem in einem Netzwerk hinterlegten Bargeld, und unterschiedliche Inhaber würden unterschiedliche Folgen erleben.
Das systemische Risiko entstand durch Vertrauen. Eine unautorisierte Ausgabe hätte bestehende Inhaber verwässern, die Liquidität an Börsen überfordern, Anwendungen stören und Fragen zu den Buchhaltungsgarantien des Ledgers aufwerfen können.
Institutionen hätten zudem mit operativer Unsicherheit rechnen müssen. Börsen hätten möglicherweise betroffene Einzahlungen identifizieren müssen, Zahlungsanbieter hätten die Abwicklung pausieren können und Verwahrer hätten Auszahlungen während einer Untersuchung beschränken können.
Diese Reaktionen hätten legitimen Nutzern schaden können, selbst wenn ein Angreifer nur einen kleinen Teil des Schlagzeilenbetrags erbeutet hätte. Ein Angebotsversagen reicht über die unmittelbar beteiligten Konten hinaus.
Dies hilft, die vertrauliche Veröffentlichung zu erklären. Die Maintainer schützten sowohl das Protokoll als auch das Reaktionsfenster, das Börsen, Validatoren und Infrastrukturanbietern zur Verfügung stand.
Der Fehler bestand wahrscheinlich seit der Entwicklung der Zahlungs-Engine im Jahr 2015. Eine zweite Schwäche in der Angebotsinvariante datierte Verias Analyse zufolge auf 2017.
Dieser Zeitverlauf setzt die Annahme unter Druck, dass Langlebigkeit allein Sicherheit beweist. Software kann Milliarden von Transaktionen verarbeiten und dennoch einen Exploit-Pfad behalten, den normale Aktivität nie auslöst.
Ripple erklärte im März, XRPL habe seit 2012 mehr als 100 Millionen Ledger und drei Milliarden Transaktionen verarbeitet. Diese Zahlen zeigen eine umfangreiche Nutzung, decken jedoch nicht jeden möglichen arithmetischen Zustand ab.
Der seltene Input war hier entscheidend. Normale Zahlungen konnten den für den Overflow erforderlichen Wert nicht erreichen, weil das legitime XRP-Angebot weit unter dieser Schwelle lag.
Ein Angreifer hätte extreme Orderbuchwerte über viele Angebote hinweg konstruieren müssen. Herkömmliche Tests, die auf plausibles wirtschaftliches Verhalten ausgerichtet sind, hätten diese Kombination möglicherweise nie untersucht.
Auch Audits beseitigten das Risiko nicht. Veria zufolge wurde die Codebasis seit 2024 mehr als einem Dutzend Audits oder Audit-Wettbewerben unterzogen, ergänzt durch ein etabliertes Bug-Bounty-Programm.
Das beweist nicht, dass die Audits nachlässig waren. Audits unterliegen zeitlichen, inhaltlichen und anreizbezogenen Beschränkungen, während seltene Wechselwirkungen zwischen getrennten Komponenten verborgen bleiben können.
Die Lehre ist enger gefasst und hilfreicher. Reife Finanzsoftware braucht Tests, die maschinelle Grenzwerte herausfordern – nicht nur Szenarien, die gewöhnlichem Nutzerverhalten ähneln.
KI-Sicherheit fand den Fehler, doch Menschen begrenzten ihn
Die Entdeckung spricht für KI-gestützte Sicherheit, während die Reaktion zeigt, warum autonomes Scanning nur eine Ebene der Protokollverteidigung ist.
Veria schreibt sowohl die Entdeckung als auch die Konstruktion des Exploits seinem KI-Sicherheitsagenten zu. Nach Angaben des Unternehmens analysierte das System rippled, verknüpfte die beiden arithmetischen Schwächen und erstellte einen funktionierenden lokalen Proof of Concept.
Diese Darstellung ist bedeutsam, weil die Schwachstelle Schlussfolgerungen über Komponenten hinweg erforderte. Das Auffinden des Zahlungsüberlaufs allein hätte keinen Erfolg garantiert, wenn die Angebotsinvariante die Transaktion abgewiesen hätte.
Der Agent erkannte Berichten zufolge, dass die Invariante den Überlauf wiederholte. Anschließend entwickelte er eine Eingabe, die beide Fehler innerhalb einer Transaktion auslöste.
Verias Angaben werden durch bedeutende externe Belege gestützt. RippleX reproduzierte den Exploit unabhängig, bestätigte die Ausgabefähigkeit der erzeugten XRP und stufte den Bericht von schwerwiegend auf kritisch hoch.
Die offizielle XRPL-Offenlegung liefert keine vollständige Bewertung der Autonomie des Agenten. Sie bestätigt den Bericht und das technische Ergebnis, misst aber nicht unabhängig, wie viel menschliche Anleitung zur Entdeckung beitrug.
Diese Lücke ist bei der Bewertung von KI-Sicherheitsprodukten relevant. Ein erfolgreicher Fund kann in unterschiedlichem Verhältnis automatisierte Codeanalyse, von Menschen verfasste Prompts, iterative Überprüfung und manuelle Exploit-Validierung umfassen.
Der Vorfall liefert dennoch mehr Belege als ein Benchmark-Ergebnis. Er führte zu einer bestätigten kritischen Schwachstelle, einem Produktionsrelease und einer maximalen Bounty-Auszahlung.
Ripple hatte bereits im März 2026 ein umfassenderes KI-Sicherheitsprogramm angekündigt. Das Programm kombinierte KI-gestützte Tests mit einem dedizierten Red Team, Fuzzing, formaler Verifikation und einer strengeren Prüfung von Amendments.
Fuzz-Tests versorgen Software mit unerwarteten oder fehlerhaften Eingaben, um Abstürze und ungültige Zustände aufzudecken. Formale Verifikation nutzt mathematische Verfahren, um zu prüfen, ob Software festgelegte Eigenschaften erfüllt.
Diese Methoden adressieren unterschiedliche Fehlermodi. KI kann Code untersuchen und Angriffspfade vorschlagen, Fuzzer können Eingaberäume erkunden, und formale Methoden können kritische Invarianten testen.
Menschliche Ingenieure entscheiden weiterhin, ob ein Fund erreichbar ist, ob seine Auswirkungen real sind und wie er repariert werden kann, ohne den Konsens zu stören. Sie koordinieren zudem die Offenlegung über eine dezentrale Betreiberbasis hinweg.
Die Reaktion des XRP Ledger verdeutlicht diese Aufteilung. Der Agent fand den Pfad, Liao überprüfte ihn, und RippleX reproduzierte den Exploit in kontrollierten Umgebungen.
Die Entwickler änderten anschließend mehrere arithmetische Pfade. Validator-Betreiber installierten das Release, während die Maintainer die Akzeptanz überwachten, bevor sie die Details offenlegten.
Kein einzelner Beteiligter kontrollierte den gesamten Ablauf. Das System beruhte auf der Zusammenarbeit eines privaten Sicherheitsunternehmens, von Open-Source-Entwicklern, einer Stiftung, RippleX und unabhängigen Betreibern.
Diese Koordination ist eine Stärke, weil mehrere Parteien den Fund prüften. Sie ist aber auch eine Governance-Abhängigkeit, die genauer betrachtet werden sollte.
Der Notfall-Patch wurde verteilt, bevor die Erklärung auf Quellcodeebene öffentlich wurde. Validatoren mussten entscheiden, ob sie dem Release vertrauen, ohne die bei Routineänderungen übliche Transparenz zu erhalten.
Die Alternative barg ihre eigene Gefahr. Die Veröffentlichung der exakten Überlaufmechanik vor einer breiten Einführung hätte Angreifern einen funktionierenden Weg gegen jeden ungepatchten Validator eröffnet.
Dies ist der zentrale Zielkonflikt, nicht ein einfacher Wettbewerb zwischen KI und menschlichem Auditing. Schnellere Entdeckung erhöht den Wert schneller, vertrauenswürdiger und sorgfältig gesteuerter Reaktionsverfahren.
Dieselben Werkzeuge, die Verteidigern helfen, alten Code zu untersuchen, können auch Angreifern helfen, nach gleichartigen Fehlern zu suchen. RippleX-Ingenieurin Mayukha Vadari warnte in der Offenlegung, dass KI die zeitliche Dynamik rund um die Entdeckung und Ausnutzung von Schwachstellen verändert.
Ein reifes Programm braucht daher mehr als bessere Scanner. Es benötigt eingeübte vertrauliche Offenlegungen, klare Schweregradstandards, Kommunikationskanäle für Validatoren und messbare Bereitschaft für Upgrades.
Was der Fehler im XRP Ledger nicht beweist
Der bestätigte Exploit war schwerwiegend, doch mehrere Schlagzeilen-Interpretationen gehen über die verfügbaren Belege hinaus.
Erstens gibt es keine Belege dafür, dass 18,45 Billionen XRP in ein öffentliches Ledger gelangten. Forscher erzeugten den Output in einer kontrollierten Umgebung, während sie die Schwachstelle validierten.
Zweitens hat keine Quelle festgestellt, dass Angreifer den Pfad vor Verias Meldung kannten. Das Alter des verwundbaren Codes beschreibt die Dauer der Exposition, nicht bestätigtes Wissen von Angreifern.
Drittens sollte das behauptete Risiko von 94 Milliarden US-Dollar nicht als prognostizierter Verlust verstanden werden. Es beschreibt den Markt, dessen Knappheitsgarantie potenziell beschädigt worden wäre.
Viertens belegt der Vorfall nicht, dass ein KI-System jede Forschungsphase unabhängig abgeschlossen hat. Veria lieferte die detaillierteste Darstellung der Rolle des Agenten, während Menschen Überprüfung und Offenlegung vornahmen.
Diese Einschränkungen machen den Fund nicht im abwertenden Sinn theoretisch. RippleX reproduzierte die Transaktion und bestätigte, dass eine nachfolgende Zahlung die neuen XRP ausgeben konnte.
Die Schwachstelle erreichte zudem Produktionscode. Anders als ein separates Problem bei Batch-Transaktionen, das im selben Release 3.4.1 behoben wurde, handelte es sich nicht um eine vorgeschlagene Funktion, die vor der Aktivierung entdeckt wurde.
Die Zusammenführung dieser Vorfälle kann Verwirrung stiften. Der Batch-Fehler betraf die Validierung eines Wrappers und mögliche Abweichungen zwischen Serverversionen.
Dieses Batch-Amendment war im Hauptnetz nicht aktiviert worden. Validatoren behandelten die Behebung per Amendment-Abstimmung, und die korrigierte Version wurde am 9. Oktober aktiviert.
Der XRP-Überlauf folgte einem anderen Pfad. Er betraf bestehendes Verhalten der Zahlungs-Engine und wurde sofort behoben, als Nodes Version 3.4.1 installierten.
Der Release-Eintrag enthält daher zwei Sicherheitskorrekturen mit unterschiedlicher Expositions- und Governance-Geschichte. Nur der Zahlungsüberlauf schuf den behaupteten Minting-Pfad.
Eine weitere Unsicherheit betrifft die historische Erkennung. XRPL erklärt, keine Hinweise auf eine Ausnutzung in öffentlichen Netzwerken gefunden zu haben, doch Leser sollten „keine Hinweise“ von einem absoluten Abwesenheitsbeweis unterscheiden.
Ein Angreifer, der den Exploit nutzte, würde ungewöhnliche Bilanzänderungen und Orderbuchaktivitäten erzeugen. Diese Spuren sollten rückblickende Analysen erleichtern, insbesondere angesichts des Bedarfs an Hunderten künstlichen Angeboten.
Die öffentliche Offenlegung präsentiert jedoch weder eine vollständige forensische Methodik noch eine unabhängig auditierte Durchsuchung der Ledger-Historie. Ihre Schlussfolgerung bleibt der berichtete Befund der Maintainer.
Auch das schnelle Upgrade des Netzwerks verdient weitere Prüfung. Eine Akzeptanz von mehr als 80 Prozent unter Default-UNL-Validatoren verringerte die unmittelbare Gefährdung, doch andere Nodes und Infrastrukturanbieter folgen anderen Zeitplänen.
Ältere Software wird nicht durch eine Offenlegungserklärung sicher. Betreiber, die rippled 3.4.0 oder früher ausführen, bleiben für ein Upgrade verantwortlich.
Schließlich zeigt dieses Ereignis nicht, dass KI Blockchain-Audits vollständig gemacht hat. Es zeigt, dass ein KI-gestützter Prozess einen wichtigen Fehler in einer reifen Codebasis fand.
Der nächste Test ist die Wiederholbarkeit. Sicherheitsteams benötigen Belege dafür, dass ähnliche Systeme vielfältige, zuvor unbekannte Schwachstellen finden, ohne Maintainer mit schwachen Meldungen zu überfluten.
Sie müssen zudem den missbräuchlichen Einsatz bewerten. Schnellere defensive Entdeckung ist nur dann wertvoll, wenn Reparatur und Bereitstellung die böswillige Reproduktion überholen können.
Drei Signale werden zeigen, ob sich das Sicherheitsmodell verbessert hat
Die nächste Phase sollte anhand von Code, Validatorverhalten und unabhängig reproduzierbaren Sicherheitsergebnissen beurteilt werden.
Das erste Signal ist die fortgesetzte Einführung von rippled 3.4.1 oder neuer. Die Behebung des kritischen Überlaufs greift bei der Softwareinstallation, daher bleiben veraltete Nodes das deutlichste vermeidbare Risiko.
Öffentliche Validator-Telemetrie sollte zeigen, dass die verwundbaren Versionen aus relevanten Konsensrollen verschwinden. Eine langsame Einführung würde die Behauptung schwächen, dass XRPL unter dringenden Bedingungen koordinieren kann.
Das zweite Signal ist eine technische Überprüfung der monetären Invarianten über diesen speziellen Patch hinaus. Die fehlgeschlagene Angebotsprüfung teilte arithmetisches Verhalten mit der Komponente, die sie überwachen sollte.
Entwickler sollten weitere Summen, Konvertierungen und Bilanzpfade mit breiteren Akkumulatoren und expliziter Überlaufbehandlung testen. Eine unabhängige Prüfung würde das Vertrauen stärker erhöhen als eine weitere allgemeine Zusicherung.
Das dritte Signal sind Belege dafür, dass KI-gestützte Tests unter verantwortungsvoller Offenlegung wiederholbare Funde erzeugen. Bestätigte Schwachstellen, niedrige Falschpositivraten und klare menschliche Aufsicht würden Verias weitergehende Behauptung stützen.
Ein Strom sensationeller, aber unbestätigter Berichte würde sie schwächen. Das Gleiche gälte für Funde, die umfangreiche nicht offengelegte menschliche Rekonstruktion erfordern, bevor sie umsetzbar werden.
Der Vorfall verändert bereits die Sicherheitsgrundlage. Lange Betriebsdauer, frühere Audits und ein Design mit sinkendem Angebot verhinderten nicht, dass ein Fehler an einer maschinellen Grenze die zentrale Geldregel von XRP bedrohte.
Gleichzeitig funktionierte die Reaktion, bevor ein öffentlicher Exploit auftauchte. Forscher meldeten das Problem, Ingenieure reproduzierten es, und Validatoren installierten innerhalb weniger Tage eine Notfallkorrektur.
Entwickler und Infrastrukturbetreiber sollten nun fragen, ob ihre eigenen Sicherheitsprüfungen anders versagen als die Systeme, die sie überwachen. Eine doppelte Annahme ist keine echte Defense in Depth.
Für Leser, die den Fehler im XRP Ledger verfolgen, ist es am sinnvollsten, Versionsadoption, unabhängige Codeprüfung und künftige Bounty-Offenlegungen zu beobachten. Diese Signale werden zeigen, ob es sich um eine isolierte Reparatur oder den Beginn eines stärkeren Sicherheitsmodells handelt.
