Hack Binance : comment vider 2,5 milliards en 3 minutes avec la faille EIP-7702 ?
Cinquante clés pour une seule serrure. Pour comprendre le hack de Binance, il faut passer par une ligne de code d’Ethereum. Pourtant, la plupart des utilisateurs ne l’ont jamais remarquée. Arrivé avec la mise à jour Pectra en mai 2025, l’EIP-7702 permet à un portefeuille classique de se comporter comme un contrat intelligent. Le pirate l’a utilisé pour transformer le hot wallet « Binance 14 » en aspirateur. Ce seul portefeuille a perdu environ 2,5 milliards de dollars, sur un total estimé à 6,3 milliards par Binance pour l’ensemble du hack. Or, sur les 50 autorisations qu’il avait préparées, une seule a réussi.
Voici l’anatomie technique de l’attaque, avec les deux explications qui s’opposent sur l’origine de la signature.
Les points clés de cet article :
- L’EIP-7702 autorise un compte ordinaire à déléguer son exécution à un contrat, sur simple signature de son propriétaire.
- L’attaquant ignorait le compteur exact du portefeuille. Il a donc signé cinquante autorisations consécutives, et l’une d’elles a fait mouche.
- Cette signature exige la clé privée du compte. La faille se situe donc dans la chaîne de signature de Binance.
- Binance parle d’un ordinateur d’ingénieur compromis, TRM Labs d’une infrastructure de signature percée.
EIP-7702 : ce que Pectra a changé pour les wallets
Jusqu’au 7 mai 2025, Ethereum vivait avec deux types de comptes bien séparés. D’un côté les comptes externes, les EOA, contrôlés par une clé privée, ceux de votre MetaMask ou de votre Ledger. De l’autre les comptes de contrat, pilotés par du code. Un EOA ne pouvait rien faire d’autre qu’envoyer des transactions une par une. L’EIP-7702, poussé par Vitalik Buterin, a brouillé cette frontière. Concrètement, le propriétaire d’un EOA signe une autorisation. Elle dit en substance « jusqu’à nouvel ordre, exécute le code de ce contrat à ma place ». Le compte garde son adresse et son solde, mais se met à obéir à la logique d’un contrat.
Les usages sont concrets : grouper plusieurs opérations en une transaction, ou laisser un tiers payer les frais de gas. Les wallets grand public ont adopté la délégation EIP-7702 dès l’été 2025. Mais tout le monde connaissait le revers dès le départ. En effet, si quelqu’un obtient une autorisation vers un contrat malveillant, le compte entier devient le sien. Et il n’a même pas besoin de « voler » la clé privée au sens classique.
Trois garde-fous encadrent cette autorisation. D’abord, la clé privée du compte la signe. Ensuite, elle mentionne l’identifiant de la chaîne. Enfin, elle porte le nonce du compte, ce compteur qui augmente à chaque transaction envoyée. Or une autorisation ne vaut que si son nonce correspond exactement au compteur du compte. Ce contrôle a lieu au moment où un bloc l’inclut. C’est ce détail qui explique le chiffre 50.
Hack Binance : la mécanique des 50 autorisations
Blockaid, la société de sécurité qui a détecté l’opération, a reconstitué la séquence. L’attaquant détenait de quoi signer des autorisations au nom de Binance 14. En revanche, il ne connaissait pas le nonce courant de ce portefeuille, qui enchaînait les retraits clients. Il a donc signé cinquante autorisations, du nonce 18 914 775 au 18 914 824. Puis il les a envoyées en une seule transaction de type 4, le format créé par Pectra. Les quarante-neuf autres ne correspondaient à aucun compteur valide. Une tombait pile sur le compteur en cours. Blockaid résume sur X : « une seule sur 50 a fait mouche ».
À partir de là, Binance 14 exécute le code du contrat de l’attaquant. D’après Blockaid, le premier transfert part 3 minutes et 24 secondes après la délégation. Il emporte 167 464 ETH, 1,6 milliard d’USDT et une soixantaine d’autres jetons. Le même rôle de propriétaire a ensuite servi à extraire 823 millions d’USDC d’un autre portefeuille intelligent. Rien, dans cette chaîne, n’a exploité un bug de l’EIP-7702. Le protocole a fait exactement ce qu’on lui demandait, avec une signature valide.
Ces cinquante signatures posent une question simple. En effet, pour les produire, il faut la clé privée de Binance 14 ou l’accès au système qui l’utilise. Pour Ido Ben-Natan, le patron de Blockaid, il s’agit d’un « usage détourné de la clé », pas d’un vol.
De 2,5 à 6,3 milliards : le détail du hack Binance
Le chiffre de 2,5 milliards de dollars ne concerne que Binance 14. Le pirate a frappé sur une dizaine de blockchains en même temps. Binance estime l’impact total à « environ 6,3 milliards de dollars ». TRM Labs, qui a suivi les fonds, arrive à 6,36 milliards, répartis ainsi au moment des transferts :
- Ethereum : environ 3,79 milliards de dollars, dont Binance 14, les 823 millions d’USDC et d’autres hot wallets de l’exchange ;
- Bitcoin : environ 1,47 milliard, soit 18 270 BTC ;
- Tron : environ 628 millions, en USDT (612,7 millions) et en TRX ;
- XRP Ledger : environ 296 millions, soit 233,46 millions d’XRP, vidés en premier, quinze minutes avant Binance 14 ;
- Solana : environ 96 millions ;
- Arbitrum, Optimism, Base, Avalanche et Polygon : environ 77 millions à eux cinq.
L’écart entre les estimations tient au périmètre retenu. Blockaid, qui ne compte qu’Ethereum, Bitcoin et Tron, s’arrête à 5,57 milliards. Binance affirme de son côté avoir gelé environ 3 milliards de dollars on-chain, notamment grâce à Tether et Circle, qui ont bloqué les USDT et USDC volés.
Laptop DevOps ou infrastructure de signature : les deux versions du hack Binance
Binance a donné sa lecture dans son point d’étape publié dans la nuit. Selon l’exchange, le pirate aurait piraté l’ordinateur portable d’un ingénieur DevOps. Cet accès lui aurait permis « d’accéder à un conteneur de service et de soumettre des transactions de retrait non autorisées ». Binance dit toutefois n’avoir trouvé « aucune preuve de fuite de clé privée ». Traduction : le pirate a dialogué avec le service autorisé à demander des signatures. Ce service a ensuite signé ce qu’on lui présentait, sans que la clé elle-même ne sorte. Y compris cinquante autorisations 7702 qu’un retrait client n’a aucune raison de contenir.
TRM Labs formule la même idée autrement et conclut à « une compromission de l’infrastructure de signature des hot wallets ». Les deux versions se rejoignent sur l’essentiel. Le maillon faible se trouve dans un composant interne qui a le droit de signer, pas dans le protocole Ethereum. Ce qui aurait dû bloquer ? Plusieurs garde-fous existent. Une règle peut refuser toute transaction de type 4 émise par un hot wallet de retrait. Une liste blanche peut limiter les contrats de délégation. Enfin, une simulation peut tester chaque transaction avant signature, précisément le produit que vend Blockaid. Binance promet un post-mortem détaillé une fois l’enquête terminée. D’ici là, les exchanges dont les signataires acceptent des autorisations EIP-7702 sans filtre ont intérêt à revoir leur configuration avant lundi.
En mai 2025, Pectra avait été un succès sans incident en mai 2025, et le réseau tient toujours. La faille du 29 octobre ne change rien au code d’Ethereum. En revanche, elle change les questions à poser à votre plateforme : qui signe, et avec quels filtres.
Magali
Tombée dans le terrier du lapin blanc en 2017, je suis passée de lectrice assidue à Rédactrice en chef du Journal du Coin. J’aime m'investir dans les coulisses de projets pour porter ma vision d'un futur décentralisé. Amoureuse des belles lettres, je coordonne nos équipes pour transformer la complexité technique en une information humaine, précise et sans jargon inutile. Entre entrepreneuriat et rédaction, ma mission est claire : vulgariser demain, mais le faire aujourd'hui.