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. 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 780 millions de dollars 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.
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.
