Le 5 mai 2026, une faille liée à des autorisations persistantes a permis à des pirates de retirer environ 1,42 million de dollars depuis des portefeuilles ayant donné un accès à un routeur du protocole Ekubo — un rappel que les permissions accordées sur la blockchain peuvent rester actives bien au‑delà d’une simple transaction. Cette affaire met en lumière une vulnérabilité récurrente : les autorisations « illimitées » exposent aujourd’hui des dizaines d’utilisateurs à des pertes massives.
Pour comprendre l’enjeu immédiat : si vous avez déjà accepté qu’un contrat puisse prélever vos tokens, cet accès demeure tant que vous ne le révoquez pas.
Pourquoi une autorisation ne s’arrête pas après l’échange
Avant d’échanger un jeton via une application décentralisée, l’utilisateur signe une autorisation donnant au contrat la possibilité de prélever des tokens en son nom. Ces permissions sont inscrites sur la blockchain dans le contrat du token et ne sont pas stockées dans votre navigateur ou portefeuille.
Autrement dit, se déconnecter d’un site ne supprime pas l’accès : seule une révocation explicite coupe la liaison. La plupart des standards actuels n’imposent aucune date d’expiration par défaut, ce qui permet à ces autorisations de subsister — parfois pendant des années.
Ce qui s’est passé chez Ekubo
Le protocole Ekubo, présent sur plusieurs chaînes compatibles Ethereum et sur Starknet, utilisait un routeur appelé HuffRouter pour optimiser les frais d’échange. Un défaut d’analyse des données envoyées au routeur a autorisé l’injection d’octets arbitraires après un trajet d’échange valide, provoquant la mauvaise interprétation de ces données lors du règlement.
Concrètement, l’attaquant a pu faire apparaître n’importe quel utilisateur autorisant le routeur comme le payeur d’un échange. Le premier vol enregistré remonte au 5 mai 2026, à 17:50 UTC.
Les conséquences :
- Perte totale estimée : 1,42 million de dollars répartis sur 31 adresses.
- Une seule adresse a concentré l’essentiel des fonds : environ 17 WBTC (~1,37 M$) et 0,34 cbBTC — soit près de 98 % du montant total.
- Les pools de liquidité et la version Starknet du protocole n’ont pas été affectés.
Ekubo admet qu’aucun audit n’avait été réalisé sur le contrat vulnérable. Le routeur concerné ne peut plus être modifié et reste donc exposé. Le 23 juin, l’équipe a annoncé un fonds de remboursement mis en place par la DAO, plafonné par adresse et distribué sur une base volontaire.
Un schéma déjà connu dans l’écosystème
Les attaques exploitant des autorisations persistantes ne sont pas inédites. Les bilans publics montrent une série d’exploits similaires :
- 2024 : environ 80 millions de dollars perdus sur des incidents liés aux autorisations.
- Juillet 2024 : la plateforme LI.FI a subi un vol d’environ 11,6 M$ touchant 153 wallets (autorisation illimitée).
- Janvier 2024 : une faille chez Socket a visé près de 200 utilisateurs, tous concernés par des accès illimités.
- Janvier 2026 : les contrats de SwapNet ont exposé 18 utilisateurs pour 13,43 M$.
Le site Revoke.cash recense ces incidents et signale neuf exploitations d’autorisations en 2025, totalisant plus de 6 M$. À côté de ces vols, les escroqueries par faux signatures représentent un autre vecteur coûteux : ScamSniffer évalue à 83,85 M$ les pertes liées à ces arnaques en 2025.
Comment limiter le risque
Quelques mesures pratiques réduisent significativement l’exposition :
- Limiter le montant d’autorisation lors de la signature — MetaMask et d’autres wallets permettent de définir un plafond au lieu d’accorder un accès illimité.
- Revoir et supprimer régulièrement les permissions : outils publics comme Revoke.cash (plus de 80 réseaux) et le vérificateur d’Etherscan pour Ethereum permettent d’identifier et de révoquer des autorisations. Les révoquations individuelles sont gratuites hors frais réseau ; Revoke.cash facture un petit montant pour les retraits groupés.
- Privilégier les autorisations temporaires quand l’application le propose — certaines interfaces limitent la durée d’accès.
Les autorités de sécurité conseillent aussi ces pratiques : en janvier 2024, la police et l’agence nationale de cybersécurité de Singapour ont recommandé d’auditer et de supprimer les autorisations élevées.
Changements proposés : faire expirer les autorisations par défaut
En réaction aux incidents, Moody Salem (fondateur d’Ekubo) a déposé le 6 mai 2026 la proposition ERC‑8255 sur le dépôt des EIP. L’idée centrale : intégrer une durée maximale par token pour les autorisations, de sorte qu’une permission expire automatiquement si elle n’est pas renouvelée.
La proposition inclut aussi une fonction permettant d’octroyer des autorisations très courtes (jusqu’à un seul bloc) et reste compatible, dans son texte, avec les usages actuels. Le projet divise la communauté : certains développeurs préfèrent maintenir le comportement existant, d’autres réclament des changements structurels — estimant que l’absence d’expiration est une faiblesse, non une fonctionnalité voulue.
D’autres approches techniques sont discutées : l’ERC‑7674 propose d’effacer les autorisations à la fin de la transaction, et depuis la mise à jour Pectra (mai 2025) certains wallets peuvent combiner autorisation et échange en une seule opération pour réduire la fenêtre d’exposition.
Que retenir pour l’utilisateur aujourd’hui
Les autorisations sans durée limitée continuent d’exister et ne s’effacent pas automatiquement — même si un protocole propose des protections supplémentaires. Tant que les contrats vulnérables ne peuvent pas être modifiés, la seule action fiable reste la révocation manuelle par l’utilisateur.
- Contrôlez vos autorisations régulièrement.
- Privilégiez des plafonds plutôt que des accès illimités.
- Utilisez des outils publics (Revoke.cash, Etherscan) pour supprimer les permissions inutiles.
Au moment où ERC‑8255 était encore à l’état de proposition (octobre 2026), aucune implémentation généralisée n’avait été adoptée. Les incidents comme celui d’Ekubo rappellent que la gouvernance technique et la prudence individuelle restent indispensables pour protéger ses actifs sur les blockchains.