Wie eine KI einen 7 Jahre alten Bug in 30 Sekunden fand – und warum ein Code-Review-Prozess ihn nie entdeckt hat

• Der technische Ablauf des Exploits
• Drei offene Fragen – und ein alarmierender Befund
• Die Rolle der KI
• Was bedeutet das für die Zukunft von KI und Softwaresicherheit?
  • 1. KI als unverzichtbarer Teil des Sicherheits-Workflows
  • 2. Die Kehrseite: KI kann auch Angreifern helfen
  • 3. Neue Verantwortung für Deployment-Prozesse
  • 4. Der Mythos „viele Augen“ ist endgültig tot
• Fazit

Der Liquid-Vorfall ist ein Vorgeschmack auf das, was uns bevorsteht: Die Werkzeuge, die uns retten können, sind dieselben, die uns gefährden können. Entscheidend wird sein, wer sie zuerst und klüger einsetzt.

§Der technische Ablauf des Exploits

Das Liquid Network nutzt „Confidential Transactions“. Dabei werden Überweisungsbeträge und Asset-Typen durch kryptografische Commitments und Range Proofs verborgen. Um die rechenintensive Überprüfung dieser Range Proofs zu beschleunigen, wurde vor etwa sieben Jahren ein Caching-Mechanismus eingeführt. Die Idee: Einmal geprüfte, korrekte Range Proofs zwischenspeichern und bei identischen Bytes nicht erneut berechnen müssen.

Der Fehler lag darin, was der Cache überprüfte – und was nicht:

• Geprüft wurden: die Range-Proof-Bytes und das Value-Commitment.

• Nicht geprüft wurden: der Asset-Typ (z. B. L‑BTC vs. ein anderes Asset) und das Output-Skript (die Ausgabebedingung).

Dadurch konnte ein Angreifer einen Output erzeugen, der zwar andere Asset-Typen oder Skripte enthielt, aber den gleichen Range-Proof wie ein zuvor gültiger Output verwendete. Der Cache lieferte fälschlicherweise ein „gültig“-Ergebnis. Auf diese Weise ließen sich L‑BTC-Token ohne entsprechendes Bitcoin-Backing erschaffen – quasi aus dem Nichts.

Der Angreifer tauschte diese 4000 künstlich erzeugten L‑BTC über SideSwap gegen echte Bitcoin ein. Der Peg-Out (die Rückwandlung von L‑BTC in BTC) funktionierte wie gewohnt: Die Token wurden „verbrannt“ und das Federation-Multi-Sig sendete 3996 BTC an den Empfänger.

§Drei offene Fragen – und ein alarmierender Befund

Die Analyse des Vorfalls wirft mindestens drei ungeklärte Aspekte auf:

1. Fix vor dem Exploit, aber nicht ausgerollt
   Blockstream hatte den Cache-Bug bereits am 3. August 2026 in einem Commit behoben und den Fix am 1. September in den Master-Branch gemerged. Dennoch wurde kein offizielles Release mit dem Patch veröffentlicht. Die SideSwap-Betreiber liefen weiterhin eine ungepatchte Version. Warum wurden sie nicht informiert oder zum Update gedrängt?

2. Warum ließ SideSwap den riesigen Peg-Out zu?
   Normalerweise sollten Peg-Outs durch die Federation-Mitglieder auf Plausibilität geprüft werden – 4000 L‑BTC auf einmal hätten auffallen müssen. Offenbar gab es keine manuelle Überprüfung von ungewöhnlich großen Auszahlungen oder täglichen Limits.

3. Warum divergierten die Explorer?
   Der Blockstream-Explorer akzeptierte den kritischen Block, während der liquidexplorer (betrieben von mempool.space) ihn ablehnte, obwohl beide die gleiche Version (23.3.2) ohne den Fix liefen. Möglicherweise war der Cache bei einem der Nodes nicht aktiv oder wurde regelmäßig zurückgesetzt.

§Die Rolle der KI

Der vielleicht wichtigste Punkt dieses Vorfalls ist die Art und Weise, wie der Bug letztlich entdeckt wurde. GitHub Copilot, konkret das Modell Fable 5, fand die Schwachstelle mit einer einfachen Eingabeaufforderung („spot anything erroneous with this?“), die auf den Pull Request mit der Einführung des Cachings angewendet wurde.

Jahrelang war der Code von zahlreichen Entwicklern reviewed und überarbeitet worden – der Fehler blieb trotzdem unsichtbar. Das unterstreicht, dass „Many eyes make bugs shallow“ (Linus‘ Law) ein gefährlicher Mythos ist. Menschen übersehen subtile Logikfehler, insbesondere wenn sie in einer Performance-Optimierung versteckt sind, die bereits etabliert ist.

Eine KI hingegen ist unvoreingenommen, kann riesige Codebasen innerhalb von Sekunden scannen und auf Logiklücken prüfen, die für Menschen kaum erkennbar sind. Der Liquid-Hack ist so zu einem der besten Belege für den produktiven Einsatz von generativer KI in der Cybersicherheit geworden.

§Was bedeutet das für die Zukunft von KI und Softwaresicherheit?

§1. KI als unverzichtbarer Teil des Sicherheits-Workflows

Der Liquid-Vorfall wird wahrscheinlich dazu führen, dass Sicherheitsaudits in Zukunft grundsätzlich durch KI-Code-Reviews ergänzt werden müssen – oder sogar primär von KI gesteuert werden. Wenn ein simpler Prompt einen sieben Jahre alten Bug findet, den Menschen nicht bemerkt haben, sind herkömmliche Penetration-Tests und manuelle Code-Reviews nicht mehr ausreichend.

§2. Die Kehrseite: KI kann auch Angreifern helfen

Derselbe KI-Assistent, der den Bug findet, kann auch von Angreifern genutzt werden, um Sicherheitslücken zu identifizieren und Exploits zu schreiben. Wir sind in einem Wettrüsten mit Angreifern, die ebenfalls Zugang zu leistungsfähiger KI haben. Die Frage ist nicht mehr ob, sondern wie schnell sich defensive und offensive KI-Fähigkeiten entwickeln.

§3. Neue Verantwortung für Deployment-Prozesse

Die Tatsache, dass ein Fix existierte, aber nicht rechtzeitig in Produktion ging, lässt Blockstream nicht gerade gut aussehen. KI-gestützte Systeme könnten hier in Zukunft helfen, indem sie nicht nur Bugs entdecken, sondern auch automatisch Patches testen, priorisieren und ausrollen – und dabei sogar die Dringlichkeit anhand von Exploit-Szenarien einschätzen.

§4. Der Mythos „viele Augen“ ist endgültig tot

Wir müssen anerkennen, dass Open-Source-Reviews allein nicht mehr ausreichen. Der Liquid-Hack demonstriert, dass subtile Fehler über Jahre hinweg unentdeckt bleiben, selbst wenn Hunderte von Entwicklern den Code ansehen. In Zukunft müssen wir auf hybride Ansätze setzen: menschliche Expertise für das große Architekturverständnis und KI für die pixelgenaue Prüfung im Code.

§Fazit

Der Liquid-Hack von 2026 ist kein normaler Sicherheitsvorfall. Er vereint eine technisch raffinierte Ausnutzung eines Cache-Bugs, Versäumnisse bei der Patch-Verteilung und den spektakulären Fall, in dem eine KI eine kritische, jahrelang übersehene Schwachstelle findet. Die Lektionen sind klar:

• Audit-Prozesse müssen KI-gestützt werden – nicht optional, sondern obligatorisch.

• Sicherheit auf Code-Ebene muss durch operationelle Kontrollen ergänzt werden – Limits, manuelle Checks für große Transaktionen, Monitoring von Inkonsistenzen.

Der Liquid-Vorfall ist ein Vorgeschmack auf das, was uns bevorsteht: Die Werkzeuge, die uns retten können, sind dieselben, die uns gefährden können. Entscheidend wird sein, wer sie zuerst und klüger einsetzt.