~320 Mio. $ verloren: Liquid Network- und Symbiosis-Exploits

Während der vergangenen Woche (07.09.2026 - 13.09.2026) haben wir 2 Sicherheitsvorfälle mit einem geschätzten Gesamtschaden von etwa 320 Mio. USD beobachtet.

Datum	Vorfall	Typ	Geschätzter Schaden
06.09.2026 *	Liquid Network	Fehlerhafte Konstruktion des Cache-Schlüssels	~320 Mio. USD
11.09.2026	Symbiosis	Fehlerhafte Validierung von Off-Chain-Einzahlungen	~770.000 USD

*Der Vorfall bei Liquid Network ereignete sich am 6. September und wurde im Bericht der Vorwoche nicht behandelt. Er wird hier der Vollständigkeit halber aufgeführt.

Highlight der Woche: Liquid Network

Der Vorfall bei Liquid Network wurde aufgrund seines subtilen Kollisionsmechanismus bei Cache-Schlüsseln und der erheblichen Verluste, die er verursachte, ausgewählt. Durch das Erstellen einer Transaktion, deren Validierungsdaten die Bytes einer früheren Transaktion neu unterteilten, erhielt der Angreifer für einen niemals geprüften Nachweis ein zwischengespeichertes Validierungsergebnis zurück.

Am 06.09.2026 wurde das Liquid Network, eine Bitcoin-Sidechain, um etwa 320 Mio. USD erleichtert [1]. Eine Kollision im Rangeproof-Validierungscache von Elements, der Node-Software, auf der Liquid läuft, ermöglichte es, dass ein für einen Output vermerktes „valid“-Urteil für einen zweiten, völlig anderen Output zurückgegeben wurde, dessen Nachweis dadurch akzeptiert wurde, ohne jemals geprüft worden zu sein. Der Angreifer nutzte dies, um 4.000 L-BTC zu erzeugen, die durch keinen Bitcoin gedeckt waren, und hob sie anschließend über das gewöhnliche Peg-out-Verfahren des Netzwerks ab. Am folgenden Tag wurden 3.400 BTC an die Föderation zurückgegeben, sodass etwa 598,5 BTC beim Angreifer verblieben [2].

Hintergrund

Das Liquid Network ist eine Bitcoin-Sidechain, die auf Elements aufbaut, einer Open-Source-Blockchain-Plattform, die vom Bitcoin-Quellcode abgeleitet ist. Es existiert, um Bitcoin schneller, kostengünstiger und privater zu bewegen, als es die Hauptkette erlaubt. Bitcoin wechselt über eine Zwei-Wege-Anbindung (Peg) zwischen den beiden Netzwerken: Bei einem Peg-in sperrt ein Nutzer BTC bei der Föderation des Netzwerks, einer festen Gruppe geprüfter Organisationen, die die Peg-Gelder gemeinsam verwahren, und erhält im Gegenzug denselben Betrag an L-BTC; bei einem Peg-out vernichtet der Nutzer L-BTC, und die Föderation gibt die entsprechenden BTC frei. Liquid-Blöcke werden nicht gemint. Eine rotierende Gruppe der Funktionsknoten der Föderation schlägt sie vor, und eine Schwellenwertanzahl von Unterschriften der Föderation finalisiert sie.

Wie Bitcoin verfolgt Liquid Gelder als unverbrauchte Transaktionsausgaben (Unspent Transaction Outputs) und nicht als Kontostände. Eine Transaktion benennt bestehende unverbrauchte Outputs, entsperrt sie und erzeugt neue, wobei der dabei erzeugte Wert dem verbrauchten Wert entsprechen muss. Jeder Output trägt ein Sperrskript, sein scriptPubKey. Ein Output, dessen Skript mit OP_RETURN beginnt, kann niemals ausgegeben werden; er dient dazu, Daten zu transportieren, und ein Peg-out wird genau als eine solche Art von Output ausgedrückt.

Liquid verbirgt zudem standardmäßig Beträge. Anstatt eine Zahl in einen Output zu schreiben, schreibt es ein Pedersen-Commitment zu dieser Zahl. Commitments sind additiv, sodass ein Knoten bestätigen kann, dass die Inputs und Outputs einer Transaktion ausgeglichen sind, ohne einen der beteiligten Werte zu erfahren. Diese Eigenschaft wirkt in beide Richtungen: Ein Commitment kann ebenso gut einen Wert verbergen, der sich wie ein negativer Wert verhält, wodurch die Outputs einer Transaktion ihre Inputs übersteigen und dennoch ausgeglichen erscheinen könnten. Jeder Output, dessen Betrag verborgen ist, trägt daher einen Rangeproof, einen Nachweis, dass der zugesagte Betrag im Bereich [0, 2^64) liegt. Die Prüfung eines Rangeproofs ist aufwendig, und derselbe Output wird mehr als einmal geprüft — wenn die Transaktion in den Mempool gelangt, und erneut, wenn sie in einem Block ankommt — daher führt Elements einen Cache der bereits akzeptierten Nachweise, indexiert nach dem Nachweis und den Daten, gegen die er geprüft wurde.

Schwachstellenanalyse

Der Fehler liegt darin, wie Elements, die Node-Software, die jeder Liquid-Teilnehmer betreibt, bereits verifizierte Rangeproofs zwischenspeichert.

CachingRangeProofChecker::VerifyRangeProof() leitet für den vorliegenden Output einen Cache-Eintrag ab und gibt bei einem Treffer sofort einen Erfolg zurück, ohne den Nachweis überhaupt zu berühren:

Der Eintrag stammt aus ComputeEntryRangeProof(), das vier Felder nacheinander in einen einzigen SHA-256-Stream schreibt und den Hash finalisiert:

Die vier Felder sind der Rangeproof selbst, das Pedersen-Commitment zum Betrag, der Asset-Generator, der angibt, welches Asset der Output enthält, sowie das scriptPubKey, das eingeschlossen wird, damit ein akzeptierter Nachweis an genau ein bestimmtes Sperrskript gebunden ist.

Keines der vier Felder trägt ein Längenpräfix oder einen Trenner. Der Rangeproof und das scriptPubKey variieren in der Länge; das Pedersen-Commitment und der Asset-Generator sind stets 33-Byte-Punkte. Der Hash speichert daher nur die verketteten Bytes, ohne jegliche Markierung, wo ein Feld endet und das nächste beginnt. Zwei unterschiedliche Sätze von vier Feldern, die zufällig zu demselben Byte-Strom verketten, erzeugen denselben Eintrag, und wer auch immer zuerst validiert wird, hinterlässt ein Urteil, das der andere abgreift. Der Hasher wird mit einem knotenspezifischen Zufallssalt initialisiert, aber der Salt wird beiden Streams gleichermaßen vorangestellt, sodass er den Hash zwar verändert, die beiden Eingaben jedoch nicht unterscheidet. Der Fehler wurde im Commit 94000967 [3] behoben.

Angriffsanalyse

Die folgende Analyse basiert auf den Transaktionen 271147...187ec5 und f24a4b...0a183f, die beide von Knoten akzeptiert wurden, auf denen der verwundbare Code lief.

Schritt 1: Der Angreifer veröffentlichte eine Transaktion, deren erster Output ein OP_RETURN ist, der 67 Bytes an Daten trägt.

Ihr scriptPubKey lautet 6a 43 — der OP_RETURN-Opcode gefolgt von einem Push von 67 Bytes — dann zwei 33-Byte-Werte und ein abschließendes 6a. Diese 67 gepushten Bytes sind keine Daten, die diese Transaktion benötigt. Es sind das Wert-Commitment und der Asset-Generator eines Outputs, der zu diesem Zeitpunkt noch nicht existierte. Die Validierung dieses Outputs speicherte ein „valid“-Urteil unter dem Eintrag für seine eigenen vier Felder.

Schritt 2: Der Angreifer reichte anschließend die Inflationstransaktion ein. Ihr OP_RETURN-Output besitzt ein scriptPubKey, das aus dem einzelnen Byte 6a besteht, und ihr Wert-Commitment ist genau der 33-Byte-Wert, der in den Push der vorherigen Transaktion eingebettet war. Ihr Rangeproof-Feld wurde aus dem Rangeproof, dem Commitment und dem Asset-Generator der vorherigen Transaktion gebildet, gefolgt von den beiden Bytes 6a 43.

Die vier Felder dieses Outputs verketten sich daher zum selben Byte-Strom wie die der ersten Transaktion, lediglich entlang anderer Grenzen neu unterteilt:

Primer:     P0 │ C0 │ X │ S0,  where S0 = 6a 43 <33-byte C1> <33-byte X> 6a
Inflation:  P1 │ C1 │ X │ S1,  where P1 = P0 ‖ C0 ‖ X ‖ 6a 43  and  S1 = 6a

Both concatenate to:  P0 ‖ C0 ‖ X ‖ 6a 43 ‖ C1 ‖ X ‖ 6a

Der Cache gab das frühere Urteil zurück, und P1 wurde niemals verifiziert — es handelt sich überhaupt nicht um einen Rangeproof. C1 sagt einen kleinen negativen Betrag zu. Der andere Output der Transaktion, ein gewöhnlicher Pay-to-Witness-Public-Key-Hash-Output an die Adresse des Angreifers ex1q7kg...qa2w, trug ein großes positives Commitment mit einem echten Rangeproof, und beide glichen sich gegenseitig aus, sodass die Transaktion ausgeglichen war. Übrig blieben 4.000 unverbrauchte L-BTC, die durch keinen Bitcoin gedeckt waren.

Schritt 3: Der Angreifer führte einen Peg-out durch. Zwei Transaktionen verbrannten 3.996,01834922 und 2,65138358 L-BTC über gewöhnliche OP_RETURN-Peg-out-Outputs, insgesamt 3.998,66973280 L-BTC. Die Funktionsknoten, die Peg-outs autorisieren, validierten sie mit demselben verwundbaren Code und gaben den Bitcoin frei: 3.995,99999857 BTC und 2,49749857 BTC erreichten den Angreifer auf Bitcoin, insgesamt 3.998,49749714 BTC.

Das Netzwerk pausierte und spaltete sich während der Bearbeitung des Vorfalls in zwei Ketten auf [4] und wurde anschließend fortgesetzt, wobei der ungültige Peg-out abgelehnt wurde [2]: Ein Block-Explorer zeigt heute die Primer-Transaktion als bestätigt, nicht jedoch die Inflationstransaktion, obwohl der dadurch freigegebene Bitcoin die Wallet der Föderation bereits verlassen hatte. Am folgenden Tag um 16:09:25 UTC gab der Angreifer 3.400,00000000 BTC an die Peg-Wallet der Föderation zurück und behielt die verbleibenden ~598,5 BTC ein [2], während beide Seiten über in Bitcoin-Transaktionen eingebettete Nachrichten verhandelten [4].

Fazit

Der Angreifer brach keine Kryptografie und kompromittierte keinen Schlüssel. Der Fehler lag darin, wie der Rangeproof-Cache identifizierte, was bereits geprüft worden war. Sein Schlüssel verkettete vier Felder — zwei davon von variabler Länge — zu einem einzigen Hash-Stream, ohne jegliche Markierung, wo jedes Feld endet, sodass ein zweiter Satz von Feldern dieselben Bytes neu unterteilen und auf denselben Eintrag treffen konnte. Ein gespeichertes „valid“-Urteil wurde daraufhin für einen Nachweis zurückgegeben, den kein Knoten jemals verifiziert hatte, und sobald ein Rangeproof den dahinterstehenden Betrag nicht mehr einschränkt, verliert ein vertrauliches Ledger das Einzige, das seine verborgenen Werte nicht-negativ hält. Ein präparierter Output wurde zu 4.000 L-BTC, und die Zwei-Wege-Anbindung verwandelte sie in Bitcoin auf der Hauptkette.

Jeder Bezeichner, der aus mehr als einer Eingabe variabler Länge abgeleitet wird, muss sich auf die Grenzen zwischen ihnen festlegen, sei es durch Voranstellen der Länge jedes Feldes oder durch Hashen der Felder in getrennte, feste Slots. Ohne dies ist die Ableitung nicht injektiv, und zwei unterschiedliche Eingaben können miteinander verwechselt werden. Diese Anforderung ist dort am schärfsten, wo ein Cache eine Prüfung ersetzt, denn dort ist ein Treffer die Entscheidung, sie nicht auszuführen.

Weitere Vorfälle dieser Woche

Symbiosis

Am 11.09.2026 wurde die Bitcoin-Route der Cross-Chain-Brücke Symbiosis auf ihren Implementierungen auf BNB Smart Chain, Ethereum und Rootstock ausgenutzt, was Liquiditätsanbieter und Nutzer schätzungsweise 9,97 BTC (~770.000 USD, zum Preis von ~77.000 USD am 11. September) kostete [5]. Off-Chain-Code, der entscheidet, wie viel synthetisches Bitcoin aus einer Bitcoin-Einzahlung geprägt werden soll, entnahm die Identität des Einzahlers einem Teil der Transaktion, den der Einzahler selbst kontrolliert, wodurch sich der Angreifer als Administrator ausgeben und die Mindestgebühr unter null drücken konnte; anschließend wurde diese Gebühr ohne Vorzeichenprüfung von der Einzahlung abgezogen, sodass die Subtraktion den Betrag tatsächlich erhöhte.

Hintergrund

Symbiosis ist ein Cross-Chain-Liquiditätsprotokoll, das Werte zwischen Ketten bewegt, indem es sperrt und prägt, anstatt das Asset selbst zu übertragen: Auf Chains mit Smart Contracts werden die Token eines Nutzers durch den Portal-Contract auf der Quellkette gesperrt, und der Synthesis-Contract prägt einen gleichwertigen Betrag eines synthetischen Tokens, eines sTokens, auf der Zielkette; das Verbrennen des sTokens gibt das Original frei [6]. Bitcoin gelangt über diese Route als syBTC, ein Token mit 8 Dezimalstellen entsprechend der kleinsten Bitcoin-Einheit, ausgegeben auf BNB Smart Chain, Ethereum und Rootstock und in Pools gegen BTCB, cbBTC, WBTC und RBTC gepaart [5].

Bitcoin verfügt über nichts dergleichen: keine Smart Contracts, also auch keinen Portal-Contract, um Einzahlungen zu sperren. An dessen Stelle tritt das Portal — eine dafür vorgesehene Bitcoin-Adresse, die dieselbe Rolle übernimmt. Eine Einzahlung ist eine gewöhnliche Bitcoin-Transaktion, die an diese Adresse zahlt, wobei die Anweisungen für die Zielkette als Daten angehängt sind. Off-Chain-Code der Brücke liest diese Daten aus, um zu erfahren, wer einzahlt, wie viel und wohin das synthetische Token gehen soll, und setzt die Gebühr des Portals durch — abgezogen vom eingezahlten Betrag, bevor der zu prägende Betrag festgelegt wird —, deren Minimum ein vom Administrator festgelegter Parameter ist.

Nichts von der Bitcoin-Seite ist für die Zielkette sichtbar, daher überträgt ein Relayers Network die daraus resultierende Anfrage. Die Anfrage erreicht BridgeV2, den On-Chain-Einstiegspunkt der Brücke, als kodierter Aufruf, den dieser an Synthesis weiterleitet. Die Autorisierung beruht auf einem MPC-Schlüssel: Die Signer des Protokolls halten Anteile eines einzigen privaten Schlüssels und erzeugen gemeinsam eine Signatur über die Anfrage. Der Einstiegspunkt für weitergeleitete Anfragen trägt einen einzigen Modifier und tut nichts weiter, bevor er den Aufruf ausführt:

Dieser Modifier hasht die Anfrage und verlangt, dass die beigefügte Signatur für die MPC-Adresse gültig ist:

Was der Contract feststellt, ist, dass der MPC-Schlüssel die Anfrage signiert hat. Der in der Anfrage enthaltene Betrag wird auf der Bitcoin-Seite berechnet.

Schwachstellenanalyse

Der Fehler liegt nicht in den Contracts der Zielkette. Er liegt im Off-Chain-Dienst, der Bitcoin-Einzahlungen liest und in Cross-Chain-Anfragen umwandelt. Sein Quellcode ist nicht öffentlich verfügbar, daher folgt die untenstehende Darstellung dem Post-Mortem des Teams [5] zusammen mit einem Drittanbieter-Auditbericht aus dem Jahr 2024, der ein offenbar dazu passendes Code-Snippet enthält [7].

Zwei Fehler im Einzahlungspfad mussten zusammentreffen, und der Post-Mortem stellt fest, dass keiner der beiden für sich allein ausreichend war.

Der erste betrifft die Art, wie der Einzahler identifiziert wird. Die einer Einzahlung angehängten Anweisungen werden dekodiert, um zu ermitteln, wer sie vornimmt, und der Decoder entnahm diese Identität einem Teil der Transaktionsdaten, den derjenige kontrolliert, der den Input ausgibt. Ein Einzahler konnte sich daher als jede vom Protokoll anerkannte Partei ausgeben, einschließlich des Administrators des Portals, der Rolle, die die vom Portal akzeptierte Mindestgebühr festlegt.

Der zweite betrifft die Art, wie diese Gebühr angewendet wird. Das Audit von 2024 meldete die Zeile in decodeWrap(), die den zu prägenden Betrag berechnet, indem sie die Gebühr vom Wert des Einzahlungs-Outputs abzieht:

Value: types.Satoshi(tx.TxOut[idx].Value) - info.PortalFee,

Der Befund lautete, dass types.Satoshi ein vorzeichenbehafteter Integer-Typ ist, während die info-Struktur, die PortalFee trägt, nicht vertrauenswürdig und vom Nutzer kontrollierbar ist, sodass das Ergebnis negativ werden kann und, für die Zielkette als vorzeichenloser Wert serialisiert, groß genug wird, um eine beliebige Menge an synthetischem Bitcoin zu prägen. Das Audit verzeichnete das Problem damals als behoben [7]. Der Post-Mortem von 2026 beschreibt dieselbe Art von Fehler: Die Gebühr wurde ohne Prüfung ihres Vorzeichens von der Einzahlung abgezogen [5], sodass eine Gebühr unter null die Einzahlung vergrößerte, anstatt sie zu verringern. Nichts im Einzahlungspfad scheint den zu prägenden Betrag durch das tatsächlich erhaltene Bitcoin zu begrenzen.

Angriffsanalyse

Zwölf gefälschte Prägungen wurden innerhalb von etwa vier Minuten auf BNB Smart Chain, Ethereum und Rootstock durchgeführt [5]. Die folgende Analyse basiert auf einer davon, der Transaktion 0x9a2bc0...21b9b959 auf BNB Smart Chain.

Schritt 1: Der Angreifer gab sich als Administrator des Portals aus und senkte die vom Portal akzeptierte Mindestgebühr unter null, sodass eine Einzahlung mit einer negativen Gebühr verarbeitet statt abgelehnt wurde [5].
Schritt 2: Der Angreifer zahlte 330 Satoshi ein, was als 0x000000000000014a erscheint. Die auf BNB Smart Chain eingegangene Anfrage trug 0x400000000000014a — denselben Wert mit gesetztem Bit für 2^62, 4.611.686.018.427.388.234 Basiseinheiten. Die Differenz zwischen beiden beträgt genau 2^62, sodass die von dieser Einzahlung abgezogene Gebühr -4.611.686.018.427.387.904 Satoshi betrug:
```
330 - (-4,611,686,018,427,387,904) = 4,611,686,018,427,388,234
```
Die Anfrage wurde in dieser Form signiert und weitergeleitet.
Schritt 3: receiveRequestV2Signed() verifizierte die MPC-Signatur über die Anfrage und leitete sie weiter, wobei sie metaMintSyntheticTokenBTC() erreichte. Diese Funktion ermittelte die synthetische Darstellung des echten Tokens für die Quellketten-ID, syBTC, und rief synthesize() für den vollständigen signierten Betrag auf. Alles davon wurde an die Adresse des Angreifers 0x025122...5d3Ba2 übertragen: 46.116.860.184,27388234 syBTC.
Schritt 4: Der Angreifer verkaufte das synthetische Token in die Pools, die es hielten. Ein einzelner Swap über einen Uniswap-v4-Pool syBTC/WBTC wickelte 18.446.744.072.845.450.682 Basiseinheiten von syBTC ab, etwa das Vierfache dessen, was die obige Transaktion geprägt hatte, und entnahm 4,38897292 WBTC.

Weitergeleitet ergab der Erlös dieses Swaps rund 137 ether.

Das Team pausierte die Bitcoin-Route, und innerhalb weniger Stunden wurden etwa 15,2 BTC an Portal-Geldern in Reserveadressen verschoben [5]. Es wurde eine Belohnung in Höhe von 20% jeder Rückerstattung angeboten, gültig bis zum 13. September [8]. Die übrigen Routen des Protokolls waren nicht betroffen.

Fazit

Es wurde kein Schlüssel gestohlen, und kein Contract wurde dazu gebracht, Code auszuführen, für den er nicht geschrieben war. Die von der Zielkette geprüfte Signatur war echt; was sie autorisierte, war eine Zahl, die von Off-Chain-Code bereits auf zwei getrennte Arten falsch erzeugt worden war: einmal, als die Identität des Einzahlers aus einem vom Einzahler kontrollierten Feld ausgelesen wurde, wodurch sich der Angreifer als Administrator des Portals ausgeben und dessen Mindestgebühr unter null drücken konnte, und ein weiteres Mal, als diese Gebühr ohne Vorzeichenprüfung von der Einzahlung abgezogen wurde, sodass eine negative Gebühr die Einzahlung vergrößerte, anstatt sie zu verringern.

Eine aus nicht vertrauenswürdigen Eingaben ausgelesene Identität ist keine Identität: Eine privilegierte Rolle kann nur durch etwas festgestellt werden, das der Einzahler nicht selbst wählen kann, etwa die Adresse, die den ausgegebenen Input tatsächlich autorisiert hat, geprüft gegen eine vom Protokoll geführte Liste — nicht ein Feld, das der Einzahler frei ausfüllen kann. Ein Wert, der subtrahiert wird, benötigt Grenzen auf beiden Seiten: Eine Gebühr sollte verpflichtend zwischen null und der Einzahlung liegen, und der zu prägende Betrag sollte niemals das tatsächlich von der Quellkette Erhaltene übersteigen dürfen. Jede der beiden Grenzen hätte dies allein bereits verhindert.

Quellen

[1] https://x.com/Liquid_BTC/status/2096696272447218108

[2] https://x.com/Liquid_BTC/status/2097404704028545175

[3] https://github.com/ElementsProject/elements/commit/94000967f6dc05b1afd435e79b1bbc597e29f816

[4] https://www.coindesk.com/markets/2026/09/08/white-hat-hackers-return-most-of-usd320m-bitcoin-taken-from-liquid-network

[5] https://x.com/symbiosis_fi/status/2099566361940795831

[6] https://docs.symbiosis.finance/crosschain-liquidity-engine/synthesizing-process

[7] https://github.com/symbiosis-finance/audits/blob/master/Symbiosis%20Relayers%20Network/Symbiosis%20Relayers%20Network%202024%20-%20Decurity.pdf

[8] https://x.com/symbiosis_fi/status/2098442463358718264

Über BlockSec

BlockSec ist ein Full-Stack-Anbieter für Blockchain-Sicherheit und Krypto-Compliance. Wir entwickeln Produkte und Dienstleistungen, die Kunden dabei helfen, Code-Audits durchzuführen (einschließlich Smart Contracts, Blockchains und Wallets), Angriffe in Echtzeit abzufangen, Vorfälle zu analysieren, illegale Gelder zurückzuverfolgen und AML/CFT-Pflichten zu erfüllen — über den gesamten Lebenszyklus von Protokollen und Plattformen hinweg.

BlockSec hat mehrere Fachartikel zur Blockchain-Sicherheit auf renommierten Konferenzen veröffentlicht, mehrere Zero-Day-Angriffe auf DeFi-Anwendungen gemeldet, mehrere Hacks blockiert, um mehr als 20 Millionen US-Dollar zu retten, und Kryptowährungen im Wert von mehreren Milliarden abgesichert.