L’EIP-7702 n’est pas la cause principale du vol de 6,3 milliards de dollars subi par Binance ; c’est la manière dont la signature a été obtenue.

Heure de Pékin, 30 octobre 2026, 04h24.

Les données en chaîne montrent que les fonds ont quitté l’adresse 0x28C6…1d60, appelée « Binance 14 », l’un des plus grands portefeuilles chauds Ethereum de Binance, effectuant des milliers de retraits par jour. Cette transaction a transféré 167 464 ETH, 1,615 milliard de USDT et plus de 60 types de jetons, pour une valeur totale d’environ 2,5 milliards de dollars à ce moment-là. Le portefeuille ne contenait plus qu’1 ETH.

Les frais de gaz s’élevaient à 0,0004 ETH, soit moins de 1 dollar.

Trois minutes plus tôt, à 04h21, un tiers a soumis une transaction de type EIP-7702 à cette adresse, contenant 50 autorisations avec des nonces allant de 18 914 775 à 18 914 824. 49 étaient invalides, 1 était valide. Une autorisation valide signifie qu’à partir de cet instant, tout appel à « Binance 14 » exécute le contrat déployé par l’attaquant la veille à 23h59 — un « ramasseur » non vérifié doté d’une seule fonction de vidage.

« Binance 14 » n’est donc plus un portefeuille : il est devenu une coquille exécutant le programme d’un tiers.

À 08h06, la délégation était toujours active. Soit 3 heures et 45 minutes sans révocation.

Or, révoquer cette délégation ne nécessite qu’une seule nouvelle signature avec la même clé privée. À 06h55 ce matin, Binance utilisait encore cette clé pour transférer vers son propre portefeuille les jetons épars non encore vidés.

L’EIP-7702 est-elle la cause principale de l’attaque ?

Le principe de l’EIP-7702 est le suivant : permettre à une adresse ordinaire (EOA) d’emprunter temporairement le code d’un contrat intelligent, sans modifier son adresse, son solde ni sa clé privée. Ce « prêt » s’effectue en écrivant 23 octets dans le champ code de l’adresse : 0xef0100 suivi de l’adresse du contrat. Ces 23 octets ne sont pas du code exécutable, mais un pointeur. Dès lors, tout appel à cette adresse amène la machine virtuelle Ethereum (EVM) à charger et exécuter le code pointé, dans le contexte de l’adresse appelante : address(this) reste inchangé, ainsi que le solde.

Elle ne comporte aucun bug. Derek Chiang, fondateur de ZeroDev et contributeur à l’EIP-7702, a déclaré clairement le jour de l’incident : l’EIP-7702 en elle-même ne présente aucune vulnérabilité, et les utilisateurs de portefeuilles compatibles n’ont aucune raison de s’inquiéter. Il a ajouté : pour exploiter l’EIP-7702, un attaquant doit soit contrôler la clé privée, soit tromper Binance afin qu’elle signe une autorisation 7702.

Ce n’est pas la première fois qu’elle est utilisée comme vecteur d’attaque. Après la mise à niveau Pectra d’Ethereum, Wintermute a découvert en quelques semaines que plus de 97 % des délégations 7702 sur le réseau principal pointaient vers un même « ramasseur » malveillant ; environ 3,66 millions de transactions d’autorisation ont été recensées, dont environ 63 % liées à des contrats malveillants, causant des pertes confirmées de 2,3 millions de dollars ; Blockaid a identifié quatre incidents 7702 au premier semestre 2026, représentant environ 1,08 million de dollars, et avait prédit qu’un premier cas à sept chiffres se produirait d’ici la fin de l’année.

Le résultat atteint dix chiffres, soit trois ordres de grandeur supérieurs à leur estimation.

Cela a conduit bon nombre d’observateurs à attribuer le piratage de 5,6 milliards de dollars subi par Binance — le plus important de l’histoire — à l’EIP-7702. Mais s’agit-il réellement d’un problème lié à l’EIP-7702 ?

Comment les signatures ont-elles été obtenues ?

Avant d’aller plus loin, précisons un point essentiel : 50 autorisations = 50 signatures — comment ces 50 signatures ont-elles donc été générées ?

Si l’attaquant avait obtenu les clés privées complètes, pourquoi aurait-il eu besoin de tenter aveuglément 50 nonces ? Si les clés étaient restées entre les mains de Binance, pourquoi 11 portefeuilles ont-ils été compromis simultanément en 12 minutes ? Aucune explication n’a encore été fournie.

Vingt-quatre secondes après le balayage principal, Binance 16 a transféré 28 005,6 ETH, 55,7 millions de dollars USDT, 25,9 millions de dollars RLUSD et 84,5 WBTC, tous vers la même adresse de réception.

En moins de 12 minutes, dix autres portefeuilles chauds de Binance ont effectué des opérations similaires sur quatre blockchains : Binance 55 sur Optimism a transféré 44,2 millions de dollars OP ; quatre portefeuilles sur Arbitrum ont transféré 74,6 millions de dollars ARB et 8 426 ETH ; quatre portefeuilles sur Avalanche ont transféré 1,81 million d’AVAX et 8,41 millions de dollars USDT.

Aucun de ces portefeuilles ne contenait de code. Chaque transaction était un simple virement signé par la clé privée du portefeuille, inséré entre des retraits courants.

Celui qui détient les clés privées n’a pas besoin de deviner aveuglément les nonces. Vérifier eth_getTransactionCount prend une seconde.

La personne qui doit générer 50 autorisations couvrant 50 nonces consécutifs d’un seul coup est d’un autre type : soit quelqu’un capable d’obtenir des signatures sans accéder à l’état en temps réel du portefeuille, soit quelqu’un ne pouvant soumettre qu’un lot d’autorisations préassemblées d’un seul coup, laissant le système les tester.

Plus remarquablement, ces 50 autorisations ont été approuvées simultanément dans une seule transaction.

La société de sécurité Blockaid estime que « la clé a été utilisée de façon abusive », plutôt que d’avoir été extraite directement. Quit, VP Blockchain de Yuga Labs, penche également dans ce sens : l’attaquant aurait obtenu des « signatures autorisées », pas la clé privée elle-même, et l’usage d’un relayer pour soumettre les transactions aurait précisément visé à masquer l’origine des signatures.

Shenyu a mentionné un détail dans son récapitulatif matinal : jusqu’à 6 h 55, Binance utilisait encore la même clé privée pour signer des transferts de jetons fragmentés non encore récupérés, les renvoyant vers son propre portefeuille.

Cela indique que la clé restait sous le contrôle de Binance ce matin-là.

À 10 h 26, Binance a publié sa première déclaration : un ordinateur portable d’un ingénieur DevOps aurait été compromis, permettant à l’attaquant d’accéder aux conteneurs de service et de soumettre des transactions de retrait non autorisées ; aucune preuve de fuite de clé privée de portefeuille n’a été trouvée à ce stade.

La perte ne s’est pas produite sur la blockchain.

Le problème central n’est donc pas l’EIP-7702, mais la phase précédant la signature.

Un portefeuille chaud signe des milliers de transactions par jour, ce qui exige une automatisation ; sa sécurité implique des HSM, des MPC, des multi-signatures et des flux d’approbation. Ainsi, tout le modèle de sécurité se résume à une question : ce processus peut-il déterminer, avant la signature, que « cette transaction ne doit pas être signée » ?

Le problème est que la plupart des critères de jugement ne comportent que deux colonnes : montant et adresse.

L’autorisation 7702 n’en possède aucune : elle ne comporte pas de montant. Ce qu’elle modifie n’est pas « combien transférer », mais « ce qu’est cette adresse ».

Il ne s’agit pas de dire que Binance n’a pas assuré de défense.

Trois jours avant l’incident, le 27 octobre, Binance a proactivement signalé un point notable : au cours de la semaine précédente, son équipe de sécurité avait intercepté plusieurs attaques liées à la Corée du Nord, via la méthode « Entretien contagieux » — l’attaquant se fait passer pour un recruteur, utilise des entretiens, des tests de programmation et la phrase « installez d’abord un outil de développement » pour inciter les victimes à exécuter des programmes malveillants ; une fois lancé, ce programme ouvre une porte d’entrée vers les clés, les réseaux internes et les mouvements ultérieurs de fonds.

Mais cela n’a pas empêché de répondre à la question : « Cette transaction doit-elle être signée ? »