Auteur : ZeroDrift
Points clés
- DxSale est le cas le plus lourd, le pirate ayant dérobé environ 7,3 millions de dollars.
- Le problème ne réside pas dans une faille spécifique, mais dans le fait que les anciens contrats ne sont pas désactivés de manière complète, conservant ainsi une valeur économique et des droits d'accès.
Selon une analyse publiée par ZeroDrift le 22 juin 2026, au cours des 40 derniers jours, des attaquants ont volé environ 16,9 millions de dollars sur cinq contrats intelligents obsolètes mais toujours actifs sur la blockchain.
Un « contrat abandonné » n'est pas synonyme de « contrat inactif ». De nombreux contrats, bien que n'étant plus activement développés ou maintenus par les équipes, restent déployés sur la chaîne, capables de recevoir des fonds, d'exécuter des transactions ou de déplacer des actifs. Tant qu'ils contiennent des fonds, des autorisations ou des points d'entrée invocables, ils demeurent des cibles potentielles.
Ces incidents se sont concentrés entre le 7 mai et le 15 juin 2026. TrustedVolumes a perdu environ 5,87 millions de dollars, Huma Finance V1 Pool environ 101 000 dollars, DxSale V1 Locker environ 7,3 millions de dollars, Raydium Legacy AMM Pool environ 1,34 million de dollars, et Aztec Connect a subi deux attaques consécutives pour une perte totale d'environ 2,28 millions de dollars.
Figure : Pertes cumulées liées à cinq incidents sur des contrats obsolètes en 40 jours. Source : ZeroDrift / X.

Des contrats que personne ne surveille plus peuvent toujours détenir des fonds
Le cas de DxSale est particulièrement révélateur. Son ancien contrat « locker » était initialement conçu pour verrouiller la liquidité à long terme, garantissant que les fonds ne soient pas retirés avant une date convenue. Mais le risque inhérent à ce type de système découle précisément de son objectif de conception : ils sont faits pour garder de la valeur sur le long terme.
Avec le temps, l'attention des équipes se tourne vers de nouveaux produits, la surveillance s'affaiblit, le personnel de maintenance change, et les anciennes voies de contrôle et hypothèses historiques tombent peu à peu dans l'oubli. ZeroDrift souligne que dans l'incident DxSale, un ancien chemin de contrôle est redevenu utilisable, permettant le retrait de liquidités qui auraient dû être verrouillées.
Les cinq incidents ne sont pas des réutilisations d'une même vulnérabilité. Ils ont eu lieu sur des systèmes, des architectures et des blockchains différentes, impliquant des composants variés comme le règlement RFQ, des pools de crédit, des lockers LP, des AMM et des sorties de rollup.
Ce qui est véritablement commun, c'est l'état sous-jacent : ces contrats n'étaient plus une priorité de développement active pour les équipes, mais conservaient néanmoins une valeur économique sur la chaîne.
L'analyse automatisée amplifie les risques liés aux anciens contrats
Les anciens contrats se prêtent naturellement à une recherche automatisée : leur code est public, leur historique sur la blockchain est complet, leur surveillance est faible et ils conservent souvent des hypothèses de sécurité dépassées. Auparavant, rechercher systématiquement ces cibles de longue traîne nécessitait un coût humain important ; aujourd'hui, la recherche par similarité de code, la simulation de transactions, l'analyse des données on-chain et l'examen assisté par l'IA réduisent ces coûts de recherche.
ZeroDrift souligne également qu'il n'existe actuellement aucune preuve publique que l'IA ait été utilisée dans ces cinq attaques spécifiques. Ce qui mérite attention, c'est l'évolution de la structure des coûts : il devient de plus en plus facile pour les attaquants de scanner systématiquement « les produits d'hier », tandis que les défenseurs n'ont pas encore systématisé la gestion de « la responsabilité d'hier ».
L'industrie de la sécurité DeFi a établi des processus d'audit relativement matures pour le lancement, mais le retrait, la migration et la mise hors service des contrats manquent encore d'une discipline tout aussi rigoureuse. Un contrat ne devient pas automatiquement sûr parce qu'une équipe cesse de le maintenir. Il ne prend véritablement sa retraite que lorsque les fonds, les autorisations, les accords de confiance et les points d'entrée ont tous été supprimés.





