Les attaquants ont conduit 63 % de l'utilisation précoce de la nouvelle fonctionnalité de portefeuille intelligent d'Ethereum

Le raccourci d'Ethereum vers le comportement de portefeuille intelligent est arrivé avec un nouveau problème de confiance : un portefeuille peut rendre une adresse régulière programmable sans déplacer les actifs de l'utilisateur, tandis que le code délégué acquiert le pouvoir d'agir avec l'autorité de ce compte.

Une étude évaluée par des pairs publiée pour USENIX Security '26 a révélé que les contrats liés aux attaquants étaient associés à 2 322 548 des 3 664 166 transactions d'autorisation EIP-7702 qu'elle a observées à travers sept chaînes jusqu'au 15 juillet 2025. Cela représente 63 % du volume historique des transactions dans le jeu de données des chercheurs.

Les auteurs ont lié un ensemble relativement restreint de contrats malveillants à des autorisations répétées et ont décrit certaines activités contrôlées par des attaquants comme probablement des tests de pratique ou de preuve de concept lors d'une phase précoce et exploratoire.

La figure mesure les transactions, tandis que la prévalence des portefeuilles distincts et le taux d'attaque actuel de 2026 se situent en dehors du champ d'application de l'étude.

Pourquoi les attaquants ont dominé le nombre d'autorisations précoces

Ethereum a activé Pectra, y compris EIP-7702, le 7 mai 2025. La spécification finale a introduit une transaction de type 4 qui permet à un compte détenu de l'extérieur de définir un pointeur vers le code de contrat déployé.

L'adresse reste la même, la clé privée d'origine conserve le contrôle, et les appels au compte peuvent exécuter le code délégué dans le contexte du compte.

Ce design peut donner à un portefeuille conventionnel des fonctionnalités associées aux comptes intelligents, y compris des appels groupés et des transactions sponsorisées, sans forcer l'utilisateur à migrer vers une nouvelle adresse. Il transforme également la cible de délégation en infrastructure de portefeuille.

Un code bogué ou hostile peut être capable de faire des approbations, des transferts et des appels d'application en tant que compte.

Il est dit que les applications ne devraient pas s'attendre à demander aux utilisateurs des signatures d'autorisation arbitraires car il n'existe pas d'interface générique sécurisée pour que les utilisateurs évaluent le code avec un accès illimité au compte. Les portefeuilles sont censés vérifier la mise en œuvre.

Les attaquants pourraient préparer des champs d'autorisation hors chaîne et demander à une victime de signer, et un portefeuille pourrait réduire la décision à une invite de mise à niveau de compte de haut niveau tout en obscurcissant l'adresse du contrat ou le code recevant l'autorité.

Le protocole vérifie la signature du propriétaire du compte, tandis que le portefeuille doit encore établir si le code sélectionné mérite le contrôle.

Les chercheurs ont analysé plus de 22,8 milliards de transactions historiques sur Ethereum, Binance Smart Chain, Polygon, Optimism, Arbitrum, Base et Gnosis.

Dans ces données, ils ont examiné 3 664 166 autorisations EIP-7702 jusqu'à la date limite et utilisé des filtres de transaction, une analyse de bytecode et un examen manuel pour identifier 924 contrats malveillants. Ils ont classé 793 comme ciblant les EOA, 124 comme ciblant les comptes de contrat et sept comme attaques composites.

Une carte des risques EIP-7702 montre que 63 % des autorisations, 2,36 millions de dollars de pertes détectées et 10,14 millions de dollars d'exposition potentielle.

Le document indique que les contrats malveillants ont été réutilisés de manière disproportionnée, ce qui signifie que le nombre de transactions peut augmenter beaucoup plus rapidement que le nombre de contrats distincts ou d'utilisateurs affectés. Dans un marché d'autorisation jeune, cette activité d'attaquant répétée a eu un effet démesuré sur le dénominateur.

Les attaquants ont trouvé un chemin répétable vers l'autorité au niveau du compte avant que les portefeuilles n'aient pris la décision de confiance aussi lisible et contrainte que le pouvoir qu'elle transmettait.

Le risque dépasse les portefeuilles détournés

L'étude a mesuré 2 362 848,76 $ de pertes réalisées dans ses trois catégories d'attaque. Une estimation distincte a couvert des contrats plus anciens dont les défenses supposaient que des EOA programmables ne pouvaient pas exister.

EIP-7702 brise l'ancienne hypothèse selon laquelle msg.sender == tx.origin identifie de manière fiable un EOA ordinaire ou bloque le comportement médié par des contrats.

Les chercheurs ont identifié 967 contrats Ethereum actifs dans un sous-ensemble utilisant cette vérification comme défense contre les prêts flash et ont estimé qu'environ 10,1 millions de dollars d'actifs étaient à risque élevé potentiel.

Le vol détecté s'élevait à environ 2,36 millions de dollars, donc les 10,14 millions de dollars représentent des actifs exposés par une hypothèse défensive qui n'était plus valable.

Les chercheurs ont observé que les attaquants réaffectaient des comptes à du code bénin après une attaque, rendant la surveillance basée uniquement sur l'état actuel peu fiable. Ils ont également trouvé 500 cibles de délégation non nulles spéciales sans code déployé.

Une adresse CREATE2 pré-calculée pourrait recevoir du code plus tard, changeant ce que le compte exécute tout en maintenant la cible enregistrée inchangée.

Ces modèles font de l'historique d'autorisation une partie de la frontière de sécurité. Les portefeuilles et les outils de surveillance doivent se souvenir de l'endroit où un compte pointait auparavant, évaluer les changements dans le code délégué et traiter une cible non déployée comme non résolue plutôt que comme inoffensive.

Les règles des auteurs peuvent manquer des contrats malveillants avant que les transactions de préparation ne deviennent visibles ou des attaques utilisant des interfaces nouvelles en dehors de la couverture de la méthode. Les 924 contrats sont l'ensemble détecté et vérifié manuellement, tandis que l'univers total des abus reste inconnu.

Un comportement par défaut sûr commence par faire de la délégation une décision d'installation contrôlée par le portefeuille. Les directives post-étude d'ethereum.org appellent à la mise sur liste blanche des contrats de délégation, à afficher de manière proéminente la cible, à éviter la délégation arbitraire sur les portefeuilles matériels et à s'appuyer sur des mises en œuvre auditées.

Une proposition de capacité de portefeuille d'abstraction de compte prend la même direction, appelant à une liste stricte de mises en œuvre de comptes intelligents bien connues et publiquement auditées. Ces documents ne mesurent pas à quelle fréquence les portefeuilles de production l'ont adoptée.

Les applications devraient demander la fonctionnalité dont elles ont besoin et laisser l'implémentation du compte au portefeuille. Pour une approbation et un échange dans un seul flux, les directives actuelles de la Fondation Ethereum orientent les développeurs vers une interface de portefeuille telle que ERC-5792.

Le portefeuille peut alors choisir EIP-7702, ERC-4337 ou un autre système de compte sans demander à l'utilisateur d'approuver un code de délégation de bas niveau sélectionné par l'application.

Les recommandations actuelles suggèrent de signer les paramètres d'initialisation ou de restreindre la configuration au Point d'Entrée ERC-4337, fermant ainsi un chemin de front-running dans lequel un attaquant substitue ses propres valeurs.

L'étude a identifié un mode de défaillance connexe dans le code des portefeuilles hérités : les constructeurs ne s'exécutent pas à nouveau lorsqu'un compte délègue à un contrat existant, ce qui peut laisser la propriété non définie et revendiquable de l'extérieur.

Un pointeur actuel bénin ne peut pas effacer un historique malveillant, et une cible sans code peut acquérir un comportement ultérieurement. Les portefeuilles ont besoin d'enregistrements d'autorisation durables, d'alertes claires lorsque la délégation change, et d'un chemin de suppression que les utilisateurs peuvent comprendre.

Rendre la programmabilité des portefeuilles EIP-7702 sûre par défaut nécessite que les portefeuilles considèrent la délégation comme l'installation du plan de contrôle du compte : restreindre qui peut le demander, exposer exactement ce qui contrôlera le compte, vérifier comment il s'initialise, et continuer à surveiller après le changement de pointeur.

Ce contenu est fourni à titre informatif uniquement et ne constitue pas un conseil financier, d'investissement, juridique ou fiscal. Les événements, récompenses, promotions en ligne ou informations mentionnées ici ne doivent pas être considérés comme une recommandation, une sollicitation ou une invitation à acheter, vendre, trader ou effectuer toute autre opération sur des actifs crypto. Les actifs crypto sont très volatils et peuvent entraîner des pertes. La disponibilité des services, produits et événements liés à WEEX peut varier selon les régions. Veuillez vous assurer que votre participation respecte les lois et réglementations locales applicables.