L'incident de sécurité de Binance a attiré l'attention non seulement en raison de l'ampleur de l'activité suspecte des portefeuilles, mais aussi à cause d'un détail technique visible peu avant que d'importants actifs Ethereum ne commencent à bouger : un lot d'autorisations EIP-7702.
Ce détail a rapidement placé l'EIP-7702 au centre de la discussion. Le mécanisme de délégation de compte d'Ethereum permet à un compte détenu en externe normal, ou EOA, d'exécuter temporairement une logique de contrat intelligent. Dans l'incident de Binance, les chercheurs en blockchain ont identifié une délégation EIP-7702 peu avant que des actifs ne soient transférés depuis un portefeuille chaud lié à Binance.
Mais il existe une distinction importante.
La présence d'une autorisation EIP-7702 ne prouve pas en soi que l'EIP-7702 a été exploité.
L'enquête initiale de Binance pointe plutôt vers une compromission de l'infrastructure opérationnelle. L'échange a déclaré que l'ordinateur portable d'un ingénieur DevOps avait peut-être été compromis, permettant à un attaquant d'accéder à un conteneur de service et de soumettre des transactions de retrait non autorisées. Binance a également affirmé n'avoir trouvé aucune preuve que les clés privées des portefeuilles aient été divulguées.
Cela rend l'incident particulièrement important pour comprendre la sécurité moderne des portefeuilles. Une clé privée peut rester à l'intérieur d'une infrastructure protégée tandis qu'un attaquant abuse d'un autre système autorisé à demander des signatures légitimes.
Cet article explique ce que l'EIP-7702 semble avoir fait dans l'incident, pourquoi les rapports faisant état de multiples autorisations ont attiré l'attention, et pourquoi la différence entre le vol de clés et la compromission de l'infrastructure de signature est importante.
Que s'est-il passé dans l'incident de sécurité de Binance ?
Une activité suspecte impliquant des portefeuilles chauds liés à Binance a commencé à attirer l'attention le 30 octobre 2026.
Les enquêteurs on-chain ont observé d'importants transferts depuis des portefeuilles associés à l'échange vers des adresses nouvellement créées. Les premières estimations variaient considérablement à mesure que les chercheurs suivaient les transactions sur Ethereum, Bitcoin, Tron et d'autres réseaux.
Binance a par la suite reconnu un incident de sécurité et a commencé à enquêter sur la source des transactions non autorisées. L'échange a temporairement suspendu les dépôts et les retraits pendant qu'il effectuait des contrôles de sécurité.
Dans sa mise à jour de sécurité du 30 octobre, Binance a déclaré que son enquête initiale suggérait que l'ordinateur portable compromis d'un ingénieur DevOps avait permis à un attaquant d'accéder à un conteneur de service et de soumettre des transactions de retrait non autorisées.
L'échange a estimé l'impact global à environ 6,3 milliards de dollars à ce stade de l'enquête et a déclaré qu'environ 3 milliards de dollars d'actifs concernés avaient été gelés on-chain. Binance a également déclaré qu'elle couvrirait les pertes à l'aide de son fonds SAFU et de fonds de l'entreprise.
Plus important encore pour la discussion technique, Binance a déclaré :
Qu'elle n'avait trouvé aucune preuve de fuite de clé privée de portefeuille.
Cette déclaration change la façon dont l'activité EIP-7702 rapportée doit être interprétée.
Au lieu de demander uniquement si un attaquant a volé une clé privée de portefeuille chaud, la question plus pertinente devient de savoir si un système interne compromis a pu demander ou faciliter une autorisation valide auprès d'une infrastructure de signature protégée.
Pourquoi l'EIP-7702 est-il devenu partie de l'enquête ?
L'EIP-7702 a été introduit avec la mise à jour Pectra d'Ethereum pour donner aux comptes détenus en externe certaines des capacités normalement associées aux portefeuilles de contrats intelligents.
Traditionnellement, un EOA Ethereum est contrôlé par une clé privée. Il peut signer des transactions, transférer des actifs et interagir avec des contrats intelligents, mais son propre compte ne contient pas de logique d'exécution programmable.
L'EIP-7702 change cette relation.
Il permet à un EOA d'autoriser le code d'un autre contrat à agir comme sa logique d'exécution tout en préservant l'adresse Ethereum d'origine.
Cela permet des fonctionnalités utiles d'abstraction de compte telles que le regroupement de transactions, le parrainage de gaz et des systèmes d'autorisation plus avancés.
Cela signifie également qu'une autorisation EIP-7702 mérite sensiblement plus d'attention qu'une approbation de jeton conventionnelle.
Lors de l'analyse de l'incident de Binance, les chercheurs ont rapporté qu'une adresse financée via Tornado Cash avait soumis plusieurs autorisations EIP-7702 impliquant un portefeuille chaud Ethereum lié à Binance peu avant que d'importants transferts d'actifs ne se produisent.
Une autorisation correspondrait à l'état du portefeuille et serait devenue effective.
Environ trois minutes plus tard, d'importants actifs ont commencé à quitter le portefeuille.
Le timing a naturellement fait de l'autorisation une partie importante de l'enquête.
Cela ne nous dit toujours pas comment l'autorisation valide a été obtenue.
Comment fonctionne une autorisation EIP-7702 ?
La façon la plus simple de comprendre le mécanisme est de considérer l'EIP-7702 comme permettant à un compte Ethereum ordinaire de déclarer temporairement :
« Utilisez la logique d'exécution de ce contrat intelligent lorsque mon compte reçoit des appels. »
Un flux simplifié se présente comme suit :
Ethereum EOA
│
│ Signe une autorisation EIP-7702
▼
La délégation est attribuée
│
▼
Contrat intelligent délégataire
│
│ Fournit la logique exécutable
▼
L'EOA d'origine peut exécuter
un comportement de type contrat intelligent
Le compte d'origine ne disparaît pas.
Son adresse, ses soldes et son historique on-chain existant restent intacts. Ce qui change, c'est le code qui peut être exécuté via ce compte.
L'EIP-7702 inclut également des garde-fous. Les autorisations sont liées à l'état du compte, y compris un nonce, et peuvent être remplacées ou révoquées. Elles ne sont donc pas des instructions arbitraires que quiconque peut attacher au portefeuille d'une autre personne.
Une autorisation valide nécessite toujours une autorisation cryptographique légitime de la part du compte concerné.
Ce point est central pour comprendre l'incident Binance.
Si un attaquant parvient à installer une logique de délégation malveillante, la question de sécurité importante n'est pas simplement :
« L'attaquant a-t-il utilisé l'EIP-7702 ? »
C'est :
« Comment l'attaquant a-t-il obtenu l'autorité de créer une autorisation EIP-7702 valide ? »
Pourquoi plusieurs autorisations EIP-7702 ont-elles été signalées ?
Les chercheurs en sécurité qui ont examiné les transactions ont rapporté que l'attaquant a soumis un lot contenant environ 50 autorisations associées à différentes valeurs de nonce.
À première vue, « 50 autorisations » peut donner l'impression que 50 portefeuilles ont été compromis.
Ce n'est pas nécessairement ce qui s'est produit.
Les comptes Ethereum maintiennent un nonce qui change au fur et à mesure de l'exécution des transactions. Une autorisation EIP-7702 doit correspondre à l'état approprié du compte.
Si un attaquant sait quel portefeuille il veut cibler mais ne peut pas déterminer de manière fiable quel nonce sera valide lorsqu'une transaction atteindra le réseau, il peut préparer des autorisations pour plusieurs valeurs de nonce possibles.
Seule l'autorisation correspondant à l'état valide du portefeuille réussirait.
Cette technique est parfois décrite comme le nonce spraying.
L'implication importante est que l'existence de 50 entrées d'autorisation ne signifie pas nécessairement 50 permissions réussies, 50 clés privées compromises ou 50 attaques de portefeuille distinctes.
Au lieu de cela, le schéma peut avoir été conçu pour augmenter la probabilité qu'une autorisation précédemment obtenue corresponde à l'état du compte cible au moment de la soumission.
Cela soulève une autre question :
Qui — ou quel système interne — avait l'autorité de créer la signature sous-jacente ?
C'est ici que les conclusions préliminaires de Binance deviennent particulièrement pertinentes.
Le vol de clé privée et la compromission de l'infrastructure de signature sont des problèmes différents
De nombreuses discussions sur la sécurité des cryptomonnaies réduisent la protection des portefeuilles à un seul principe :
Protégez la clé privée.
Cela reste essentiel, mais les portefeuilles institutionnels sont considérablement plus compliqués.
Une plateforme d'échange peut utiliser des modules de sécurité matériels, des services de signature, des moteurs de politiques, des services de retrait, des systèmes de contrôle d'accès et d'autres infrastructures autour de la clé sous-jacente.
Un attaquant peut donc tenter de compromettre le processus qui demande une signature plutôt que d'extraire la clé privée elle-même.
L'enquête préliminaire de Binance pointe actuellement beaucoup plus vers le second scénario.
La plateforme d'échange a déclaré qu'un ordinateur portable DevOps compromis aurait pu permettre l'accès à un conteneur de service capable de soumettre des transactions de retrait non autorisées, tout en déclarant explicitement qu'elle n'avait trouvé aucune preuve de fuite de clé privée.
Cette distinction est significative.
Une clé privée protégée par matériel peut techniquement rester sécurisée tandis que l'infrastructure environnante produit une signature pour quelque chose qui n'aurait jamais dû être approuvé.
L'EIP-7702 a-t-il causé le piratage de Binance ?
Sur la base des informations actuellement disponibles, il n'existe aucune preuve publique qu'une vulnérabilité de l'EIP-7702 elle-même ait causé l'incident de sécurité de Binance.
Cette distinction est cruciale.
Un attaquant qui utilise une fonctionnalité légitime du protocole ne signifie pas automatiquement que cette fonctionnalité était défectueuse.
Prenons un exemple plus simple.
Si un attaquant obtient des identifiants légitimes pour un compte bancaire et initie un virement via le système de paiement normal de la banque, le fait que l'infrastructure de virement de la banque ait exécuté le paiement ne prouve pas que le protocole de virement lui-même était défectueux.
Une distinction similaire s'applique ici.
EIP-7702 a peut-être fourni le mécanisme d'exécution par lequel un compte autorisé avec succès pouvait déléguer son comportement à du code malveillant.
Mais EIP-7702 exige normalement une autorisation valide.
La question non résolue est de savoir comment cette autorisation est devenue possible.
L'explication préliminaire de Binance suggère que les enquêteurs examinent une infrastructure opérationnelle compromise plutôt qu'une défaillance du protocole Ethereum.
Par conséquent, l'interprétation la plus exacte à ce stade est :
EIP-7702 semble pertinent pour le chemin d'exécution faisant l'objet de l'enquête, mais il n'a pas été établi comme la vulnérabilité racine.
Qu'est-ce qui a été confirmé et qu'est-ce qui reste sous enquête ?
Parce que les incidents de sécurité majeurs évoluent rapidement, il est particulièrement important de distinguer les conclusions confirmées de l'analyse au niveau des transactions.
Cette distinction est importante car les transactions blockchain offrent une excellente visibilité sur ce qui s'est produit on-chain, mais elles ne révèlent pas nécessairement comment un système de signature interne a été compromis.
Les chercheurs peuvent observer les délégations, les transferts et les interactions avec les contrats.
Ils ne peuvent pas déterminer à partir des seules données de la blockchain si une signature a été créée après le vol d'une clé privée, si un service interne l'a légitimement demandée, ou si un flux de travail compromis a amené un signataire protégé à autoriser des instructions malveillantes.
Cela nécessite des preuves provenant de l'intérieur de l'infrastructure affectée.
Pourquoi l'infrastructure de signature compte autant que le stockage des clés privées
La sécurité institutionnelle des cryptomonnaies se compose de plus en plus de plusieurs couches.
La première est la sécurité des clés.
Où est stockée la clé privée ? Peut-elle être extraite ? Est-elle protégée par un module de sécurité matériel ou un autre système de garde cryptographique ?
La deuxième est la sécurité de signature.
Quels services sont autorisés à demander des signatures à la clé protégée ? Quels mécanismes d'authentification, de politiques et d'approbation ces services doivent-ils satisfaire ?
La troisième est la sécurité d'autorisation.
Même si une demande est cryptographiquement valide, qu'est-ce que le compte est exactement invité à autoriser ?
Cette troisième couche devient de plus en plus importante à mesure que les comptes intelligents et la délégation de comptes gagnent en capacités.
Un transfert de jetons conventionnel peut déplacer un montant fixe d'un actif.
Une délégation peut en revanche modifier la manière dont un compte peut exécuter de futures instructions.
Pour les équipes de sécurité, cette différence signifie que la validation de signature seule ne suffit plus.
La signification de la transaction doit également être évaluée.
Pourquoi EIP-7702 modifie les hypothèses de sécurité des portefeuilles
EIP-7702 est puissant précisément parce qu'il étend ce qu'un compte Ethereum ordinaire peut faire.
Un portefeuille peut acquérir des fonctionnalités programmables sans migrer d'actifs vers un portefeuille de contrat intelligent entièrement nouveau.
Pour les portefeuilles grand public, cela peut améliorer l'ergonomie.
Pour une infrastructure institutionnelle sophistiquée, cela peut prendre en charge des politiques d'exécution plus avancées.
Mais une programmabilité supplémentaire crée des surfaces d'autorisation supplémentaires.
Une approbation ERC-20 malveillante donne généralement à une autre adresse des droits sur un seul jeton.
Une délégation EIP-7702 malveillante peut potentiellement influencer la manière dont un compte exécute des catégories d'actions bien plus larges.
Cela ne rend pas EIP-7702 intrinsèquement dangereux.
Cela signifie que les portefeuilles, les exchanges et les fournisseurs de garde devraient traiter l'autorisation de délégation comme une opération de sécurité à haut risque.
Une signature EIP-7702 ne devrait pas être évaluée uniquement comme cryptographiquement valide.
Les systèmes de sécurité devraient également se demander si la cible de délégation est attendue, si son bytecode a été examiné, si l'autorisation demandée correspond au comportement normal du compte, et si la politique interne permet à ce compte de déléguer l'exécution du tout.
Que devrait clarifier l'analyse post-mortem de Binance ?
Binance a déclaré qu'une analyse technique post-mortem détaillée sera publiée une fois son enquête terminée.
Plusieurs questions détermineront comment l'industrie interprétera finalement l'incident.
Premièrement, comment l'attaquant a-t-il obtenu l'accès au chemin de signature ?
L'explication préliminaire des DevOps identifie une partie potentiellement compromise de l'infrastructure, mais la chaîne complète depuis cet accès jusqu'à une autorisation blockchain valide reste importante.
Deuxièmement, quel rôle exact EIP-7702 a-t-il joué ?
Les enquêteurs devront déterminer si une délégation était nécessaire pour exécuter les transferts Ethereum, comment l'autorisation a été préparée et pourquoi les contrôles internes l'ont permise.
Troisièmement, les clés privées ont-elles été exposées ?
Binance affirme actuellement qu'il n'existe aucune preuve de fuite de clé privée. Un rapport forensique complet pourrait fournir plus de détails sur la manière dont les clés ont été isolées de l'infrastructure compromise.
Enfin, quel contrôle aurait dû arrêter la transaction ?
Pour les équipes de sécurité institutionnelles, cela pourrait être la question la plus précieuse de toutes.
Une signature techniquement valide ne devrait pas automatiquement signifier une transaction opérationnellement valide.
Les systèmes de garde les plus robustes séparent l'autorisation cryptographique de l'autorisation métier.
Qu'est-ce que cela signifie pour les utilisateurs ordinaires de portefeuilles Ethereum ?
L'incident Binance implique une infrastructure institutionnelle et ne devrait pas automatiquement être interprété comme la preuve que les portefeuilles Ethereum ordinaires sont exposés au même chemin d'attaque.
Un portefeuille personnel en auto-garde et un système de portefeuille chaud d'échange fonctionnent de manière très différente.
Cependant, EIP-7702 introduit également une leçon importante pour les utilisateurs individuels :
Une signature de délégation mérite le même niveau de prudence que les autres permissions puissantes d'un portefeuille.
Les utilisateurs doivent vérifier attentivement ce qu'un portefeuille leur demande de signer, en particulier lorsqu'un site web inconnu demande une délégation de compte.
Une délégation malveillante ne doit pas être confondue avec une signature de connexion ordinaire.
Les utilisateurs doivent également s'appuyer sur des interfaces de portefeuille établies qui identifient clairement les demandes de délégation et signalent les contrats suspects.
Le principe de sécurité clé reste simple : ne jugez pas une signature uniquement selon qu'elle transfère immédiatement des fonds. Certaines signatures modifient ce qu'un compte sera autorisé à faire ultérieurement.
La leçon plus large : la sécurité des portefeuilles dépasse les clés privées
L'incident de sécurité de Binance met en lumière une évolution plus large de la sécurité blockchain.
Pendant des années, l'hypothèse dominante de l'industrie était simple :
Protégez la clé, protégez le portefeuille.
Ce modèle devient incomplet.
Les portefeuilles institutionnels modernes dépendent souvent de couches d'infrastructure autour de la clé—API, services de signature, moteurs de retrait, systèmes de politiques, contrôles d'accès et environnements d'exécution automatisés.
Les mécanismes d'abstraction de compte tels que EIP-7702 ajoutent une couche supplémentaire en permettant aux portefeuilles de déléguer la logique d'exécution.
Par conséquent, la sécurité des cryptomonnaies dépend de plus en plus de trois questions distinctes :
Qui contrôle la clé ?
Qui peut demander une signature ?
Et quelle autorité cette signature accorde-t-elle réellement ?
Un système peut réussir à la première question tout en échouant à la deuxième ou à la troisième.
Cela semble être l'un des problèmes les plus importants soulevés par l'enquête de Binance jusqu'à présent.
FAQ
EIP-7702 était-il la cause du piratage de Binance ?
Non confirmé. Les conclusions préliminaires de Binance pointent vers une infrastructure opérationnelle compromise, tandis qu'EIP-7702 semble avoir fait partie du chemin d'autorisation faisant l'objet de l'enquête.
Les clés privées de Binance ont-elles été volées ?
Binance a déclaré n'avoir trouvé aucune preuve de fuite de clé privée de portefeuille lors de son enquête initiale.
Qu'est-ce qu'EIP-7702 ?
EIP-7702 permet à un EOA Ethereum de déléguer la logique d'exécution à du code de contrat intelligent tout en conservant la même adresse de portefeuille.
Pourquoi plusieurs autorisations EIP-7702 ont-elles été observées ?
Elles ont peut-être été préparées avec différentes valeurs de nonce pour correspondre à l'état du compte cible. Cela ne signifie pas nécessairement que plusieurs portefeuilles ont été compromis.
Les utilisateurs Ethereum ordinaires sont-ils affectés ?
Il n'existe aucune preuve d'une compromission des portefeuilles Ethereum à l'échelle du réseau. Les utilisateurs doivent néanmoins rester prudents face aux demandes de délégation ou de signature inconnues.
La révocation des approbations de jetons est-elle suffisante ?
Pas toujours. Les approbations ERC-20 et la délégation EIP-7702 sont des autorisations distinctes, de sorte que la suppression d'une approbation de jeton ne supprime pas automatiquement la délégation de compte.
Conclusion
L'apparition de l'EIP-7702 dans l'incident de Binance fait de ce mécanisme une partie importante de l'enquête technique, mais les preuves disponibles n'établissent pas que l'EIP-7702 lui-même ait été compromis.
Les conclusions préliminaires de Binance suggèrent plutôt qu'un attaquant pourrait avoir compromis l'ordinateur portable d'un ingénieur DevOps, obtenu l'accès à un conteneur de service opérationnel et soumis des transactions de retrait non autorisées. La plateforme d'échange affirme n'avoir trouvé aucune preuve de fuite de clé privée de portefeuille.
La distinction est importante.
Si un système de signature protégé peut être amené à autoriser des instructions malveillantes, les attaquants pourraient ne pas avoir besoin de voler la clé privée du tout.
L'EIP-7702 peut accroître les conséquences d'une telle autorisation, car il permet à un compte Ethereum de déléguer une logique d'exécution programmable. Mais utiliser cette capacité de manière malveillante et trouver une vulnérabilité dans le protocole sont deux choses différentes.
Jusqu'à ce que Binance publie son post-mortem technique complet, il est préférable de comprendre l'EIP-7702 comme un composant du chemin d'exécution rapporté—et non comme la cause racine confirmée de l'incident.
Pour les plateformes d'échange, les fournisseurs de garde et les développeurs de portefeuilles, la leçon plus large est déjà claire : la sécurité moderne des portefeuilles doit protéger non seulement les clés privées, mais aussi les systèmes qui demandent des signatures et les autorisations que ces signatures créent.
Avertissement sur les risques : Cet article est fourni à titre informatif et éducatif uniquement. Les systèmes de cryptomonnaie et de blockchain impliquent des risques techniques, opérationnels et de marché. Les lecteurs doivent vérifier indépendamment les informations de sécurité et utiliser des contrôles de risque appropriés lors de la gestion d'actifs numériques.
