EIP-7702 ist nicht die Hauptursache des 6,3-Milliarden-Dollar-Raubüberfalls auf Binance; entscheidend ist, wie die Signatur erlangt wurde.

Pekinger Zeit, 30. Oktober 2026, 04:24 Uhr.

Blockchain-Daten zeigen, dass das Geld von der Adresse 0x28C6…1d60 abgeflossen ist. Diese Adresse heißt Binance 14 – eine der größten Ethereum-Hotwallets von Binance, die täglich Tausende Auszahlungen tätigt. Diese Transaktion übertrug 167.464 ETH, 1,615 Mrd. USDT sowie über 60 Tokenarten im Wert von rund 2,5 Mrd. USD zum damaligen Zeitpunkt. Die Wallet verblieb mit nur 1 ETH.

Die Gasgebühr betrug 0,0004 ETH – weniger als 1 USD.

Drei Minuten zuvor, um 04:21 Uhr, hatte jemand eine EIP-7702-Transaktion an diese Adresse gesendet, die 50 Autorisierungen enthielt – mit Nonces von 18.914.775 bis 18.914.824. 49 waren ungültig, eine war erfolgreich. Ein Treffer bedeutet: Ab diesem Zeitpunkt führt jeder Aufruf von Binance 14 den vom Angreifer in der Vorabend-23:59-Uhr bereitgestellten, nicht verifizierten Sweeper-Vertrag mit nur einer Sweep-Funktion aus.

Binance 14 ist damit keine Wallet mehr, sondern eine Hülle mit fremdem Programmcode.

Um 08:06 Uhr war die Delegation immer noch aktiv – 3 Stunden und 45 Minuten, ohne dass jemand sie widerrufen hatte.

Der Widerruf dieser Delegation erfordert lediglich eine weitere Signatur mit demselben Schlüssel. Um 06:55 Uhr nutzte Binance diesen Schlüssel noch, um die nicht abgeräumten Token zurück in eigene Wallets zu transferieren.

Ist EIP-7702 die Hauptursache des Angriffs?

Die Logik von EIP-7702 lautet: Eine normale Adresse (EOA) darf temporär den Code eines Smart Contracts nutzen – Adresse, Saldo und privater Schlüssel bleiben unverändert. Gemietet wird mittels 23 Bytes im Code-Feld der Adresse: 0xef0100 plus Vertragsadresse. Diese Bytes sind kein ausführbarer Code, sondern ein Zeiger. Ab dann lädt die EVM beim Aufruf dieser Adresse den durch den Zeiger adressierten Code und führt ihn im Kontext dieser Adresse aus: address(this) bleibt dieselbe, der Saldo ebenfalls.

Es enthält keinen Fehler. Derek Chiang, Gründer von ZeroDev und Mitwirkender an EIP-7702, erklärte am Tag des Vorfalls klar: EIP-7702 selbst weist keine Schwachstelle auf; Wallet-Nutzer, die diesen Standard unterstützen, brauchen keine Panik zu haben. Er fügte hinzu: Um EIP-7702 zu missbrauchen, muss ein Angreifer entweder den privaten Schlüssel kontrollieren oder Binance zur Signatur einer 7702-Autorisierung bewegen.

Es ist auch nicht das erste Mal, dass es als Angriffswerkzeug genutzt wird. Nach dem Pectra-Upgrade von Ethereum stellte Wintermute innerhalb weniger Wochen fest, dass über 97 % aller 7702-Delegationen im Mainnet auf nahezu denselben »Sweeper«-Vertrag verwiesen; Studien zählten rund 3,66 Mio. Autorisierungs-Transaktionen, davon etwa 63 % im Zusammenhang mit bösartigen Verträgen – bestätigte Schäden: 2,3 Mio. USD. Blockaid verifizierte vier 7702-Vorfälle in der ersten Jahreshälfte 2026 mit insgesamt ca. 1,08 Mio. USD und prognostizierte einen ersten siebenstelligen Fall innerhalb des Jahres.

Das Ergebnis war zehnstellig – drei Größenordnungen höher als ihre Prognose.

Dies führte viele dazu, den 5,6-Milliarden-Dollar-Hack auf Binance – den größten in der Menschheitsgeschichte – auf EIP-7702 zurückzuführen. Doch ist es wirklich ein 7702-Problem?

Wie die Signaturen erlangt wurden

Bevor wir weitergehen: 50 Autorisierungen bedeuten 50 Signaturen – doch wie genau wurden diese 50 Signaturen erzeugt?

Hätte der Angreifer die vollständigen privaten Schlüssel besessen, warum hätte er dann 50 Nonces blind „anschießen“ müssen? Wären die Schlüssel stets bei Binance gewesen, warum fielen dann innerhalb von 12 Minuten 11 Wallets gleichzeitig? Eine Erklärung fehlt bisher.

24 Sekunden nach dem Haupt-Abzug übertrug Binance 16 28.005,6 ETH, 55,7 Mio. USDT, 25,9 Mio. RLUSD und 84,5 WBTC an dieselbe Empfängeradresse.

Innerhalb von 12 Minuten taten zehn weitere Binance-Hotwallets dasselbe über vier Chains: Binance 55 auf Optimism übertrug 44,2 Mio. USDT OP; vier Wallets auf Arbitrum übertrugen 74,6 Mio. ARB und 8.426 ETH; vier Wallets auf Avalanche übertrugen 1,81 Mio. AVAX und 8,41 Mio. USDT.

Keine dieser Wallets enthielt Code. Jede Transaktion war eine gewöhnliche Übertragung, signiert mit dem privaten Schlüssel der Wallet, eingebettet zwischen routinemäßigen Abhebungen.

Wer den privaten Schlüssel besitzt, muss Nonces nicht blind-snipe. eth_getTransactionCount abzufragen dauert eine Sekunde.

Die Art Person, die 50 Autorisierungen für 50 aufeinanderfolgende Nonces auf einmal erstellen muss, ist eine andere: jemand, der Signaturen erhalten kann, aber keinen Zugriff auf den Echtzeit-Zustand der Wallet hat; oder jemand, der nur einen Batch vorab zusammengestellter Autorisierungen auf einmal einreichen kann, damit das System sie versucht.

Auffälligerweise wurden diese 50 Autorisierungen alle gemeinsam in einer einzigen Transaktion genehmigt.

Die Sicherheitsfirma Blockaid bewertet, dass „der Schlüssel missbraucht wurde“, nicht dass der private Schlüssel direkt extrahiert wurde. Yuga Labs‘ Blockchain-VP Quit tendiert ebenfalls dahin: Der Angreifer erhielt „autorisierte Signaturen“, nicht den privaten Schlüssel; die Nutzung eines Relayers zur Einreichung diente möglicherweise gezielt der Verschleierung der Signaturherkunft.

Shenyu erwähnte in seiner morgendlichen Zusammenfassung ein Detail: Bis 06:55 Uhr nutzte Binance noch denselben privaten Schlüssel zum Signieren und übertrug Fragment-Token, die nicht abgeräumt worden waren, zurück in ihre eigene Wallet.

Dies deutet darauf hin, dass der Schlüssel am Morgen noch unter Binances Kontrolle war.

Gerade jetzt um 10:26 Uhr gab Binance ihre vorläufige Stellungnahme ab: Möglicherweise war das Laptop eines DevOps-Ingenieurs kompromittiert worden, wodurch der Angreifer Zugriff auf Service-Container erlangte und unbefugte Auszahlungstransaktionen einreichte; bislang gibt es keinerlei Hinweise auf einen Leak des Wallet-privaten Schlüssels.

Der Verlust erfolgte nicht on-chain.

Das Kernproblem ist daher nicht EIP-7702, sondern der Abschnitt vor der Signatur.

Eine Hotwallet signiert täglich Tausende Transaktionen – sie muss also automatisiert sein; sie muss sicher sein, daher benötigt sie HSMs, MPC, Multi-Sig und Genehmigungsprozesse. So komprimiert sich das gesamte Sicherheitsmodell in einen Satz: Kann dieser Prozess vor der Signatur entscheiden, dass „diese Transaktion nicht signiert werden darf“?

Das Problem ist, dass die meisten Bewertungskriterien nur zwei Spalten haben: Betrag und Adresse.

EIP-7702-Autorisierungen haben beides nicht. Sie enthalten keinen Betrag. Was sie ändern, ist nicht „wie viel übertragen wird“, sondern „was diese Adresse ist“.

Es ist nicht so, dass Binance nicht geschützt hätte.

Drei Tage vor dem Vorfall, am 27. Oktober, enthüllte Binance proaktiv etwas Bedeutsames: In der vergangenen Woche hatte das Sicherheitsteam mehrere nordkoreanische Angriffe abgefangen. Die Methode heißt „Contagious Interview“ – der Angreifer stellt sich als Recruiter dar, nutzt Interviews, Codierungs-Tests und den Satz „Installieren Sie zunächst ein Entwickler-Tool“ zur Täuschung, um Opfer zum Ausführen schädlicher Programme zu bewegen; sobald das Programm läuft, entsteht ein Einstiegspunkt für Schlüssel, interne Netzwerke und anschließende Geldbewegungen.

Doch es scheiterte daran, zu verhindern: „Sollte diese Transaktion signiert werden?“