Dans le monde de la blockchain, la clé privée a toujours été considérée comme le dernier rempart protégeant les actifs numériques.
Tant que votre clé privée n’a pas été compromise, il est très difficile pour quelqu’un d’autre de prendre directement le contrôle de votre portefeuille.
Mais si un jour, sans avoir effectué de virement vous-même et sans que la compromission de votre clé privée ait été clairement confirmée, les actifs de votre portefeuille risquaient malgré tout d’être transférés, cela vous surprendrait-il ?
L’incident de sécurité survenu le 29 octobre 2026 sur un portefeuille chaud de Binance a mis sous les projecteurs un sujet technique jusqu’alors plutôt spécialisé : le mécanisme de délégation de compte EIP-7702 et les risques de sécurité qu’il pourrait entraîner.
Selon des analyses de sécurité publiques, cet incident aurait impliqué l’exploitation du mécanisme EIP-7702 par un attaquant pour déléguer les portefeuilles concernés à un contrat malveillant de vidage, puis transférer les actifs.
Que s’est-il passé exactement ?
Qu’est-ce qu’EIP-7702 ? Pourquoi peut-il affecter les actifs d’un portefeuille ? Comment les utilisateurs ordinaires peuvent-ils identifier et prévenir les risques associés ?
Cet article explique ces questions progressivement, en commençant par les principes de base.
I. Comprendre d’abord une question : pourquoi les autorisations d’un portefeuille comportent-elles des risques ?
Supposons que votre portefeuille Ethereum contienne :
2 ETH ;
5 000 USDT ;
d’autres jetons ERC-20.
Vous avez toujours gardé votre clé privée et n’avez effectué aucun transfert vous-même.
Un jour, vous consultez un site DeFi. Le site vous demande de signer un message d’autorisation. Vous pensez qu’il s’agit d’une opération normale et cliquez sur Confirmer.
Plus tard, vous remarquez une activité inhabituelle sur les actifs de votre portefeuille.
La question se pose alors : vous n’avez effectué aucun transfert vous-même, alors comment vos actifs peuvent-ils quand même être transférés ?
Cela s’explique notamment par le fait que l’opération que vous avez signée n’était peut-être pas une simple connexion ou vérification de message, mais qu’elle accordait à un autre programme une certaine capacité à gérer vos actifs.
Pour comprendre ce risque, il faut d’abord distinguer deux mécanismes d’autorisation différents.
1. Autorisation ERC-20 traditionnelle : autoriser une adresse donnée à utiliser un type de jeton
Prenons l’USDT comme exemple.
Lorsque vous appelez la méthode approve d’un contrat de jeton, vous pouvez autoriser une adresse donnée à utiliser vos jetons dans la limite d’un montant défini.
Par exemple :
Adresse du portefeuille : W
Jeton : USDT
Adresse autorisée : A
Montant autorisé : 5 000 USDT
Cela signifie que tant que l’autorisation reste valide, A peut utiliser les méthodes correspondantes du contrat du jeton pour transférer vos USDT, dans la limite autorisée.
À noter :
A n’obtient pas votre clé privée ;
A n’obtient pas l’autorisation d’utiliser vos autres jetons ;
Cette autorisation concerne un contrat de jeton spécifique ;
Si le montant autorisé n’a pas été entièrement utilisé, le risque peut persister.
C’est aussi pour cela que les outils de sécurité des portefeuilles vérifient souvent les autorisations de jetons (Token Approval).
2. Délégation EIP-7702 : autoriser un portefeuille à utiliser le code d’un contrat donné
EIP-7702 est un autre mécanisme.
Il permet à un compte externe traditionnel Ethereum [EOA], après autorisation, de déléguer l’exécution de son code à un contrat intelligent déjà déployé.
Pour simplifier :
Une autorisation de jeton traditionnelle signifie :
J’autorise A à utiliser un de mes jetons.
Une délégation EIP-7702 se rapproche plutôt de ceci :
J’autorise mon portefeuille à exécuter des opérations en utilisant la logique de programme fournie par A.
Ces deux mécanismes n’ont pas la même portée.
Si le code auquel le portefeuille est délégué est conçu de manière sûre, il peut permettre au portefeuille de prendre en charge les transactions groupées, la prise en charge des frais de gas et une gestion des autorisations plus flexible, entre autres fonctionnalités.
Mais si la cible de la délégation est un contrat malveillant, ou si le code comporte un défaut grave, le risque dépasse largement celui d’une simple autorisation de jeton.
La spécification officielle d’Ethereum avertit également qu’un code de délégation mal conçu peut permettre à un attaquant d’obtenir un contrôle presque total sur les actifs du compte.
II. Qu’est-ce qu’EIP-7702 exactement, et pourquoi a-t-il été conçu ?
EIP est l’abréviation d’Ethereum Improvement Proposal, c’est-à-dire proposition d’amélioration d’Ethereum.
Le nom officiel d’EIP-7702 est :
Set Code for EOAs : définir du code pour les comptes externes.
Cette proposition fait partie de la mise à niveau Pectra d’Ethereum et a été activée sur le réseau principal Ethereum en mai 2025, avec cette mise à niveau.
Pour comprendre son fonctionnement, il faut d’abord connaître les deux types de comptes courants sur Ethereum.
1. EOA : compte de portefeuille traditionnel
Les comptes ordinaires que nous créons avec des portefeuilles tels que MetaMask sont généralement des EOA.
Leurs caractéristiques typiques sont les suivantes :
contrôlés par une clé privée ;
capables de signer des transactions de manière autonome ;
ils ne comportent pas en eux-mêmes de code métier déployé, contrairement aux contrats intelligents ordinaires ;
Les opérations traditionnelles nécessitent généralement que l’utilisateur signe les transactions correspondantes.
2. Compte de contrat intelligent : un comportement défini par du code
Le comportement d’un compte de contrat intelligent est déterminé par le code déployé sur la chaîne.
Les développeurs peuvent mettre en œuvre par le code :
l’exécution groupée de plusieurs opérations ;
une gestion complexe des autorisations ;
la prise en charge des frais de transaction ;
des procédures de gestion des actifs plus flexibles.
Cependant, l’expérience d’utilisation des EOA traditionnels diffère de celle des comptes de contrats intelligents.
L’un des objectifs d’EIP-7702 est de permettre aux EOA traditionnels de bénéficier de certaines fonctionnalités des comptes intelligents sans devoir abandonner leur adresse de compte d’origine.
3. Comment EIP-7702 fonctionne-t-il ?
Supposons que vous ayez un portefeuille ordinaire W auquel vous souhaitez ajouter des fonctionnalités de compte intelligent.
Avec EIP-7702, vous pouvez autoriser W à déléguer l’exécution de son code à un contrat A déjà déployé.
Conceptuellement, on peut le représenter ainsi :
Portefeuille W d’origine
|
| Signature d’une autorisation EIP-7702 valide
|
v
Le portefeuille W définit un marqueur de délégation
|
v
Pointant vers le contrat A
|
v
Lorsque le portefeuille W est appelé
il peut exécuter le code fourni par le contrat A
Attention : cela ne signifie pas que les actifs du portefeuille sont transférés au contrat A.
Le portefeuille W conserve son adresse de compte d’origine, et ses actifs ne sont pas transférés automatiquement par la simple définition d’une délégation.
Ce qui change, c’est que le comportement d’exécution du code du portefeuille W peut être influencé par le code fourni par la cible de la délégation.
C’est à la fois ce qui fait son intérêt et ce qui comporte des risques.
III. Incident du portefeuille chaud de Binance : quels sont les points à surveiller ?
Lors de l’incident du portefeuille chaud de Binance, survenu le 29 octobre 2026, l’attaquant a utilisé le mécanisme de délégation EIP-7702 pour faire pointer les portefeuilles chauds concernés vers un contrat de vidage déployé par l’attaquant, puis a transféré les actifs. Des analyses indépendantes ont également décrit des flux de fonds sur plusieurs chaînes.
Cependant, tous les détails d’attaque qui n’ont pas encore été confirmés ne doivent pas être considérés comme des faits. En particulier, la manière dont l’attaquant a obtenu les signatures, les raisons pour lesquelles l’opération a passé les systèmes de sécurité et l’utilisation ou non d’une méthode identique sur les différentes chaînes doivent être établies à partir de l’enquête officielle et de preuves ultérieures fiables.
Du point de vue des principes de sécurité, trois aspects de ce type d’incident méritent l’attention.
1. EIP-7702 n’est pas l’attaquant
EIP-7702 est une fonctionnalité du protocole.
Il permet aux portefeuilles de déléguer du code et ainsi de bénéficier de fonctionnalités de compte plus flexibles.
Sans cette fonctionnalité, l’attaquant ne pourrait pas exploiter le mécanisme de délégation EIP-7702 de la même manière. Cela ne signifie toutefois pas que le protocole lui-même comporte une vulnérabilité.
Tout comme une voiture peut faciliter les déplacements, mais aussi être utilisée par des criminels, il faut distinguer les capacités technologiques des attaques qui en font usage.
2. Comment l’attaquant a obtenu une autorisation valide
L’autorisation EIP-7702 doit respecter les conditions du protocole, notamment celles concernant les signatures et l’état du compte.
Par conséquent, une question importante lors de l’analyse d’un incident précis est la suivante :
Comment l’attaquant a-t-il pu obtenir une autorisation valide, ou faire accepter l’autorisation correspondante par le système ?
Les problèmes de sécurité possibles comprennent :
la divulgation de la clé privée ou de la capacité de signature ;
la compromission du portefeuille ou du système de signature des transactions ;
la manipulation d’un utilisateur ou d’un opérateur pour lui faire signer une autorisation dangereuse ;
des défauts dans la vérification des autorisations, l’approbation des transactions ou la surveillance de sécurité.
Il s’agit de vecteurs d’attaque différents. En l’absence de preuves, on ne peut pas affirmer directement que l’un d’eux est la cause réelle de l’incident.
3. Autoriser un contrat malveillant peut exposer les actifs à un risque considérable
Supposons qu’un portefeuille ait délégué son exécution à un contrat de vidage malveillant.
Si le code de ce contrat peut accéder aux capacités de gestion des actifs du portefeuille et qu’aucune restriction de sécurité efficace n’est en place, l’attaquant peut tenter de transférer les actifs vers une adresse donnée.
Il faut donc examiner non seulement le nom de la cible de la délégation, mais aussi :
la cible de la délégation ;
ce que son code fait concrètement ;
qui peut appeler les fonctions concernées ;
si les adresses et montants des transferts sont limités ;
s’il existe des chemins dangereux pouvant être exécutés sans autorisation.
C’est pourquoi une délégation EIP-7702 ne peut pas être simplement assimilée à une autorisation ERC-20 ordinaire.
IV. Un portefeuille peut-il déléguer son exécution à plusieurs contrats ?
C’est une question très importante.
Supposons que votre portefeuille W délègue d’abord son exécution au contrat A, puis remplace la cible de la délégation par le contrat B.
Première étape :
Portefeuille W
|
v
Cible de la délégation A
Deuxième étape : remplacement de la cible de la délégation
Portefeuille W
|
v
Cible de la délégation B
Pour un portefeuille sur une même chaîne, une nouvelle délégation EIP-7702 peut remplacer la précédente.
A ne conserve pas indéfiniment la capacité d’exécuter du code par l’intermédiaire de l’ancienne délégation au seul motif qu’il a été une cible auparavant.
Cela ne signifie toutefois pas que le remplacement de la délégation élimine complètement les risques liés à A.
Il faut distinguer trois situations.
Situation 1 : A ne dispose que de l’ancienne délégation EIP-7702
Si A ne peut exécuter le code concerné que par la relation de délégation EIP-7702 actuellement définie par W, alors, une fois la délégation de W remplacée par B, A ne peut plus exécuter ce code par l’intermédiaire de l’ancienne relation de délégation.
Situation 2 : A dispose également d’une autorisation de jeton indépendante
Supposons que vous ayez aussi autorisé A à utiliser 5 000 USDT.
Plus tard, vous remplacez la délégation EIP-7702 de A par B.
Cette autorisation USDT indépendante n’est pas automatiquement révoquée par le changement de la relation de délégation.
Tant que l’autorisation de jeton concernée reste valide, A peut continuer à utiliser le montant restant.
Remplacer la cible de la délégation ne revient pas à révoquer toutes les autorisations de jetons.
Situation 3 : l’attaquant a déjà obtenu la clé privée du portefeuille
Si l’attaquant a déjà obtenu la clé privée de W, la situation est plus grave encore.
L’attaquant peut utiliser la clé privée pour signer de nouvelles transactions ou autorisations. Même si vous effacez l’ancienne délégation, cette seule mesure ne suffit pas à rétablir la sécurité du portefeuille.
Précisons une idée reçue :
Un contrat intelligent ne peut pas lire directement la clé privée de votre portefeuille simplement parce que vous lui avez délégué votre exécution.
La clé privée est généralement conservée dans l’environnement sécurisé du portefeuille et n’est pas automatiquement divulguée à un contrat par une délégation EIP-7702.
Le véritable risque vient du fait qu’un code malveillant peut exploiter les capacités d’exécution du compte qui lui ont été accordées, ou que l’attaquant dispose déjà d’une capacité de signature valide.
Si votre clé privée a été divulguée, transférez vos actifs, utilisez un nouveau portefeuille sécurisé et vérifiez les autres autorisations toujours valides.
V. Comment vérifier si votre portefeuille a une délégation EIP-7702 ?
Une fois les principes compris, la question la plus pratique est :
Comment savoir si mon portefeuille a déjà délégué son exécution à un contrat ?
Sur le réseau principal Ethereum, nous pouvons consulter le code du portefeuille sur la chaîne à l’aide d’un RPC.
1. À quoi ressemble une délégation EIP-7702 sur la chaîne ?
Le marqueur de délégation EIP-7702 standard se compose de deux éléments :
0xef0100 + adresse cible de délégation de 20 octets
Le marqueur de délégation standard a donc une longueur totale de 23 octets.
Par exemple :
0xef0100
490aac77c960b0569c8e446ac7e12490bd44ca1d
Les trois premiers octets, 0xef0100, constituent le marqueur de délégation ; les 20 octets suivants correspondent à l’adresse cible de la délégation.
Ce format est défini par la spécification EIP-7702.
2. Pourquoi peut-on vérifier cela avec eth_getCode ?
Ethereum fournit la méthode RPC eth_getCode, qui permet de consulter le code d’une adresse sur la chaîne pour un état de bloc donné.
Si le portefeuille dispose actuellement d’une délégation EIP-7702 standard, le résultat de la requête permet d’identifier le marqueur de délégation décrit ci-dessus.
La procédure de détection peut donc être simplifiée ainsi :
Saisir l’adresse du portefeuille
|
v
Consulter le code sur la chaîne via RPC
|
v
Vérifier si la longueur du code est de 23 octets
|
v
Vérifier si les 3 premiers octets sont ef0100
|
+---- Oui : analyser les 20 octets suivants
| Afficher l’adresse cible de la délégation
|
+---- Non : aucun marqueur de délégation standard détecté
3. Exemple d’un programme simple de détection en Go
J’ai également mis en place et testé moi-même ce programme de détection élémentaire.
Le projet utilise Go et la bibliothèque cliente go-ethereum pour consulter le code sur la chaîne d’un portefeuille donné via un RPC du réseau principal Ethereum.
Voici le code principal :
code, err := client.CodeAt(ctx, address, nil)
if err != nil {
\tlog.Fatalf("Échec de la récupération du code du portefeuille sur la chaîne : %v", err)
}
fmt.Printf("Longueur du code sur la chaîne : %d octets\\n", len(code))
fmt.Printf("Code sur la chaîne : 0x%x\\n", code)
fmt.Println()
if len(code) == 23 \u0026\u0026 bytes.Equal(code[:3], delegationPrefix) {
\tdelegateAddress := common.BytesToAddress(code[3:])
\tfmt.Println("Résultat de la détection : délégation EIP-7702 détectée")
\tfmt.Printf("Cible actuelle de la délégation : %s\\n", delegateAddress.Hex())
\tfmt.Printf("Explorateur de la cible de délégation : https://etherscan.io/address/%s\\n", delegateAddress.Hex())
\tfmt.Println()
\tfmt.Println("Remarque : la détection d’une délégation ne signifie pas que sa cible est nécessairement malveillante.")
\tfmt.Println("Il est recommandé de vérifier également le code du contrat cible, sa provenance et sa sécurité.")
\treturn
}
fmt.Println("Résultat de la détection : aucun marqueur de délégation EIP-7702 standard détecté")
fmt.Println("Remarque : le code sur la chaîne obtenu lors de cette requête ne correspond pas au format standard du marqueur de délégation.")
fmt.Println("Cela ne signifie pas que le portefeuille n’a aucune autorisation ERC-20 ni qu’il n’a jamais utilisé EIP-7702.")
Si une délégation est détectée, le programme affiche l’adresse cible actuelle. Dans le cas contraire, il indique qu’aucun marqueur de délégation standard n’a été détecté.
========== Détection de délégation EIP-7702 ==========
Réseau : Ethereum Mainnet
RPC : https://ethereum-rpc.publicnode.com
Adresse du portefeuille : 0x1111111dD38A3739119BeA9fB2211A13e0306A8c
Longueur du code sur la chaîne : 23 octets
Code sur la chaîne : 0xef0100490aac77c960b0569c8e446ac7e12490bd44ca1d
Résultat de la détection : délégation EIP-7702 détectée
Cible actuelle de la délégation : 0x490Aac77c960B0569C8E446aC7E12490bD44Ca1D
Explorateur de la cible de délégation : https://etherscan.io/address/0x490Aac77c960B0569C8E446aC7E12490bD44Ca1D
Remarque : la détection d’une délégation ne signifie pas que sa cible est nécessairement malveillante.
Il est recommandé de vérifier également le code du contrat cible, sa provenance et sa sécurité.
Ce programme se contente d’identifier la relation de délégation. Il ne détermine pas si le contrat cible est malveillant.
Le résultat de la requête reflète uniquement l’état de la chaîne sélectionnée au moment de la consultation. Il ne prouve pas que le portefeuille n’a jamais utilisé EIP-7702 et ne remplace pas une vérification indépendante des autres chaînes.
4. La détection d’une délégation signifie-t-elle que le portefeuille a été piraté ?
Bien sûr que non.
Un portefeuille peut déléguer son exécution à un contrat audité pour bénéficier normalement de fonctionnalités de compte intelligent.
Après avoir détecté une délégation, il faut donc approfondir l’analyse :
la cible de la délégation est-elle l’adresse prévue ?
le contrat cible a-t-il été audité ?
le contrat comporte-t-il des fonctions dangereuses que n’importe qui peut appeler ?
cette délégation a-t-elle été mise en place par vous-même ou par un service de portefeuille de confiance ?
le portefeuille possède-t-il également des autorisations ERC-20 indépendantes ?
De même, l’absence de délégation EIP-7702 détectée ne signifie pas que le portefeuille est absolument sûr.
Les autorisations de jetons traditionnelles, la divulgation de la clé privée et d’autres types d’autorisations de signature peuvent présenter différents risques.
VI. Vérifier séparément les délégations EIP-7702 et les autorisations de jetons traditionnelles
Pour éviter toute confusion, comparons les deux méthodes de détection.
À retenir :
Ces deux méthodes de détection sont complémentaires et ne peuvent pas se substituer l’une à l’autre.
VII. Comment les utilisateurs ordinaires peuvent-ils réduire les risques ?
Tous les utilisateurs n’ont pas besoin d’éviter complètement EIP-7702.
Cette technologie peut réellement améliorer l’expérience d’utilisation des portefeuilles. Toutefois, pour les utilisateurs ordinaires, comprendre le contenu des autorisations est plus important que de rechercher aveuglément de nouvelles fonctionnalités.
1. Ne signez pas à la légère des autorisations que vous ne comprenez pas
Si votre portefeuille vous demande soudainement de signer une autorisation qui ne correspond manifestement pas à l’opération en cours, en particulier si elle concerne une délégation de code, des autorisations de compte ou une transaction complexe, interrompez l’opération.
Ne partez pas du principe que toutes les signatures sont sûres simplement parce qu’un site affiche « réclamer une récompense », « vérifier le portefeuille » ou « recevoir des jetons gratuitement ».
2. Vérifiez attentivement la cible de la délégation
Si votre portefeuille vous indique que votre compte va déléguer son exécution à un contrat, vérifiez :
si l’adresse provient d’une source officielle ;
si le contrat correspond bien à l’implémentation prévue ;
s’il existe un rapport d’audit fiable ;
si le portefeuille indique clairement la cible de la délégation et ses conséquences réelles.
La seule adresse du contrat ne suffit pas, car les utilisateurs ordinaires ne sont généralement pas en mesure de déterminer directement si le code est sûr.
3. Vérifiez régulièrement les autorisations de jetons traditionnelles
Si vous avez déjà utilisé des DEX, des protocoles de prêt ou d’autres applications DeFi, vérifiez régulièrement vos autorisations de jetons.
Vous pouvez envisager de révoquer les autorisations dont vous n’avez plus besoin, mais n’oubliez pas que la transaction de révocation nécessite également le paiement de frais de gas.
Par ailleurs, la révocation des autorisations de jetons ne supprime pas une délégation EIP-7702.
4. Si vous découvrez une délégation inconnue, ne poursuivez pas immédiatement vos opérations
Commencez par confirmer le réseau actuel et la cible de la délégation, puis évaluez les risques.
Si vous confirmez que la délégation n’a pas été autorisée par vous ou qu’elle présente un comportement manifestement malveillant, privilégiez la protection des actifs restants et utilisez des outils de portefeuille fiables pour gérer la délégation et les autres autorisations.
Si vous avez des raisons de penser que votre clé privée ou votre système de signature a été compromis, le simple remplacement de la cible de délégation ne suffira pas à résoudre le problème.
5. Pour les plateformes d’échange, la gestion des risques ne peut pas reposer sur une seule mesure technique
Les portefeuilles chauds des plateformes d’échange font généralement intervenir plusieurs éléments : systèmes de signature, approbation des transactions, gestion des autorisations, surveillance et gestion des fonds.
Pour gérer les risques liés à EIP-7702, il est possible d’envisager les mesures suivantes :
mettre en place un processus d’approbation plus strict pour les autorisations sensibles ;
limiter les opérations que les portefeuilles chauds peuvent effectuer ;
surveiller les délégations inhabituelles et les mouvements de fonds importants ;
isoler les systèmes de signature et contrôler leur accès ;
ajouter une vérification indépendante avant la diffusion des transactions importantes.
Ces mesures visent à réduire le risque de pertes considérables en cas de défaillance d’un seul maillon.
VIII. En résumé : EIP-7702 n’est pas le problème ; la sécurité des autorisations est essentielle
Revenons à la question de départ :
Pourquoi un portefeuille Ethereum peut-il être exposé à un risque grave pour ses actifs même si sa clé privée n’a pas été directement compromise au sens traditionnel ?
La sécurité d’un compte ne dépend pas uniquement de la divulgation de la clé privée. Elle dépend aussi des autorisations accordées par l’utilisateur, de la manière dont elles sont vérifiées et de ce que le code auquel elles donnent accès peut réellement faire.
EIP-7702 apporte de nouvelles fonctionnalités de compte aux portefeuilles traditionnels, mais introduit également de nouvelles considérations en matière de sécurité.
Retenons trois conclusions :
Premièrement, EIP-7702 est une fonctionnalité du protocole. Une attaque utilisant cette fonctionnalité ne doit pas être automatiquement assimilée à une vulnérabilité du protocole.
Remplacer ou effacer une délégation EIP-7702 ne révoque pas automatiquement toutes les autorisations indépendantes de jetons et ne résout pas une compromission déjà survenue de la clé privée.
Pour évaluer la sécurité d’un portefeuille, il faut examiner à la fois la délégation actuelle, les autorisations de jetons traditionnelles et la sécurité de la clé privée ou du système de signature. Aucun contrôle isolé ne peut prouver qu’un portefeuille est absolument sûr.
Merci d’avoir lu jusqu’au bout. En réalité, le plus important n’est pas de retenir tous les termes techniques, mais de comprendre, avant chaque signature :
Qu’est-ce que je suis en train d’autoriser ?
Qui obtiendra quelles capacités ?
Comment révoquer cette autorisation si je change d’avis ?
Comprendre ces questions permet de mieux protéger ses actifs numériques tout en profitant des avantages de la technologie blockchain.
Suivez-moi pour ne pas manquer le prochain décryptage des marchés.