Sécurité de l'account abstraction : pièges ERC-4337 en production

En 2026, l'account abstraction (ERC-4337 en production depuis deux ans, ERC-7702 largement adopté post-Pectra) a déplacé le paysage wallet. Smart contract wallets, transactions gasless, social recovery et session keys ne sont plus expérimentaux. C'est comme ça qu'une part significative des utilisateurs interagit aujourd'hui avec les protocoles on-chain. Cet article détaille les pièges de sécurité qu'on voit en production sur les déploiements AA, et ce qu'un audit d'un stack ERC-4337 doit vraiment couvrir.

Le nouveau modèle de confiance

Un wallet contrôlé par EOA traditionnel a une seule hypothèse de confiance : le détenteur de la clé privée. Compromettez la clé, drainez les fonds. L'account abstraction étend ça en un modèle programmable avec plusieurs acteurs :

• Le smart contract account lui-même, avec sa logique de validation custom.
• Le bundler, qui packagedes user operations et les soumet à l'EntryPoint.
• Le paymaster, qui sponsorise le gas (ou accepte un paiement ERC-20) au nom de l'utilisateur.
• Les session keys / sub-accounts, avec des permissions cadrées et des bornes de temps.
• Les guardians de social recovery, qui peuvent rotation la master key.

Chacun est une nouvelle surface. Le wallet drainer de 2026 n'a pas toujours besoin de la signature de l'utilisateur : il peut exploiter une session key sur-permissionnée, un paymaster buggé, ou un chemin de recovery qui contourne les protections prévues.

Piège 1 : griefing économique de paymaster

Un paymaster peut sponsoriser le gas pour toute user operation qu'il accepte. L'attaque classique : un utilisateur malicieux soumet des opérations qui consomment le dépôt du paymaster plus vite que la base utilisateur légitime, drainant la trésorerie de la dApp.

Ce qu'il faut auditer sur un paymaster :

• Le coût de validation est borné. Si la validation peut appeler des contrats arbitraires (lectures d'état, appels d'oracle), le bundler peut ne pas inclure l'op à cause des estimates de gas. Mais une op malicieuse peut quand même consommer le budget de vérification du bundler.
• Rate limits par utilisateur. Un paymaster qui ne suit pas la consommation par sender est trivialement drainable.
• Règles d'acceptation. Les paymasters qui acceptent toute opération sont des paymasters qui font faillite. Validez le contrat cible, le selector de fonction, la forme de la calldata.
• Protection sur les withdrawals. L'owner du paymaster ne devrait pas pouvoir drainer le paymaster plus vite que ce que les utilisateurs en flight attendent.

Un paymaster en production bien connu a perdu 200 k$ dans un incident de 2025 à cause d'un check de gas par-op manquant. Le bug faisait moins de 10 lignes de Solidity.

Piège 2 : reentrancy et accès storage en phase de validation

La spec ERC-4337 restreint ce que la fonction de validation d'un wallet peut faire, précisément quels slots de storage elle peut lire et quels autres contrats elle peut appeler. La raison : les bundlers doivent pouvoir prédire si une op va réussir sans l'exécuter.

Les wallets qui violent les restrictions de validation (intentionnellement ou par composition avec du code librairie) sont rejetés par les bundlers qui suivent la réputation. Mais plus subtil : les wallets qui techniquement respectent les règles peuvent quand même être designés de façon à ce que le comportement de validation diffère de l'exécution. Cet écart est exploitable.

Ce qu'il faut auditer :

• La validation ne doit pas dépendre d'un état global mutable qui peut changer entre validation et exécution.
• La validation ne doit pas appeler des contrats externes dont les valeurs de retour affectent l'issue de la validation (la spec restreint ça, mais la composition peut le faire passer).
• Les chemins validateUserOp et execute du wallet doivent s'accorder sur ce qu'est « la même opération » : des schémas de signature différents ici, c'est une porte d'entrée.

Piège 3 : session keys au scope trop large

Les session keys sont la feature AA qui shifte le plus directement l'UX : une dApp peut demander à l'utilisateur d'accorder une clé scopée et bornée dans le temps pour une série d'opérations (une session de jeu, une session de trading) sans prompter à chaque transaction.

Les erreurs courantes :

• Le scope est trop large. « Autoriser cette dApp à appeler n'importe quel contrat » est fonctionnellement équivalent à « donner votre clé privée à cette dApp pour la durée ».
• Les expressions de scope sont fausses. Les règles de scope ABI-decoded avec des erreurs off-by-one sont courantes. Une session key censée autoriser « trades jusqu'à 100 $ » qui autorise « trades jusqu'à 1 000 000 $ » est une mauvaise journée.
• La révocation n'est pas testée. Certaines implémentations de session keys ont des chemins de révocation on-chain qui ne propagent pas immédiatement. Révoquer + supposer révoqué est un trou de sécurité.
• Stockage de la clé côté dApp. Une session key compromise sur le frontend de la dApp (XSS, extension malicieuse) est fonctionnellement équivalente à une compromission de clé côté utilisateur.

Piège 4 : edge cases du social recovery

Le social recovery (un set de guardians qui peuvent collectivement rotation la master key) est une feature UX puissante avec de vrais compromis sécurité.

Ce qu'il faut auditer :

• Onboarding des guardians. Les guardians sont-ils vérifiés out-of-band, ou peuvent-ils être ajoutés par l'owner du wallet seul (ce qui collapse le social recovery sur la clé d'origine) ?
• Compromission d'un guardian. Si un guardian est compromis, quel est l'impact ? Threshold + timelock est la réponse standard.
• Race conditions. Les flows de recovery qui impliquent un timelock plus un quorum de guardians peuvent avoir des race conditions où un guardian est ajouté ou retiré pendant un recovery en cours.
• Abus de recovery. Certaines implémentations laissent les guardians initier le recovery sans le consentement de l'owner. Avec assez de collusion entre guardians, ça est la master key.

Piège 5 : délégation transitoire ERC-7702

ERC-7702 (live depuis Pectra) permet à un EOA de déléguer temporairement à un smart-contract wallet pour une seule transaction. C'est un gros gain UX, apportant les features AA aux EOA existants sans migration. C'est aussi de la nouvelle surface d'attaque.

Ce qu'il faut auditer :

• Code délégué. Le contrat délégué tourne avec l'autorité de l'EOA. S'il a la moindre fonction « drain to caller », l'EOA est maintenant drainable par toute personne qui peut la déclencher.
• Révocation de délégation. Les délégations EIP-7702 sont persistantes jusqu'à révocation explicite. Un utilisateur qui délègue une fois et ne révoque jamais est de façon permanente soumis à la logique du contrat délégué.
• Surface de phishing. L'attaque phishing de 2026, c'est « signez cette délégation 7702 d'apparence innocente » : la délégation résultante donne au contrat malicieux un contrôle permanent jusqu'à révocation.

Ce que couvre un audit AA crédible

Un audit d'un stack ERC-4337 / 7702 doit explicitement répondre à :

1. Le validateUserOp du wallet respecte-t-il les restrictions de storage et de call de l'ERC-4337 ?
2. Le paymaster (si présent) a-t-il des rate limits par sender et un coût de validation borné ?
3. Les expressions de scope des session keys sont-elles correctement ABI-decoded et bornées ?
4. Les chemins de recovery sont-ils timelockés, threshold-gated, et la révocation testée ?
5. (Pour 7702) l'interface du contrat délégué est-elle délibérément minimale et replay-protected ?
6. Y a-t-il des « fast paths » (fonctions admin, pauses d'urgence) qui contournent le modèle de confiance prévu ?

Construire de l'AA en production

L'account abstraction est vraiment bonne pour l'UX. La barre sécurité est aussi plus haute que pour les wallets contrôlés par EOA, parce que le wallet est un smart contract et que les bugs ont les mêmes conséquences que dans n'importe quel contrat DeFi.

Si vous expédiez de l'infra AA (un wallet provider, un paymaster, un système de session keys), l'audit de smart contract doit être scopé explicitement sur les risques AA ci-dessus, pas seulement sur la logique « core » du wallet. Les chemins d'attaque intéressants en 2026, ce sont ceux que la spec n'interdit pas mais que l'implémentation rate.