Rédigé par : Gino Matos
Compilé par : Luffy, Foresight News
TL;DR :
- Un pirate a volé environ 1,34 million de dollars d'actifs en exploitant les pools de liquidités du marché automatique (AMM) V3 de Raydium, pourtant désactivés depuis longtemps.
- Cet incident met en lumière un problème répandu : les anciens contrats abandonnés par les projets DeFi restent opérationnels sur la blockchain. Ces infrastructures sous-jacentes oubliées sont désormais des cibles d'attaque faciles à négliger.
- Des rapports publics indiquent qu'au moins 8 incidents de piratage similaires ciblant des contrats anciens se sont produits dans le secteur depuis mars 2025, ce qui signifie qu'une grande quantité de code ancien non géré reste accessible de l'extérieur.
Récemment, une vulnérabilité dans l'AMM V3 de Raydium a entraîné une perte de 1,34 million de dollars, liée à cinq pools de liquidités en dehors de l'écosystème actuel du projet. Ces pools ne sont pas pris en charge par l'interface utilisateur ou le SDK de Raydium et sont inaccessibles aux utilisateurs ordinaires, mais ils ont tout de même été exploités par le pirate.
Cette attaque a ciblé les contrats et infrastructures sous-jacentes anciens et négligés par l'industrie, révélant une faille majeure dans la gestion du cycle de vie complet des contrats intelligents. Ce type de problème ne se limite pas à cet échange décentralisé de l'écosystème Solana.
Une catégorie de risque négligée
Selon les statistiques issues des rapports publics d'incidents de sécurité, depuis mars 2025, il y a eu au moins 8 cas avérés d'attaques exploitant des contrats abandonnés, obsolètes ou anciens, pour un montant total de pertes d'environ 10,8 millions de dollars.
Si l'on inclut les incidents de sécurité déclenchés par d'anciens pools de liquidités et des produits d'accompagnement obsolètes, le nombre total d'événements atteint 10 (y compris le présent piratage de Raydium), pour une perte totale d'environ 22,5 millions de dollars.
Actuellement, la plupart des plateformes de suivi des incidents de sécurité du secteur classent les types d'attaque en fonction de leur cause technique. Les catégories courantes incluent : les vulnérabilités du code des contrats intelligents, les défaillances de contrôle des autorisations, la manipulation des oracles, la fuite de clés privées, les défauts des ponts inter-chaînes, etc.
Les contrats zombies (c'est-à-dire les anciens contrats que le projet a annoncé comme désactivés mais qui restent appelables sur la blockchain) relèvent d'une dimension de risque complètement différente. Ils sont le résultat d'un problème de gestion du cycle de vie du contrat menant à un incident de sécurité, mais ils sont toujours noyés dans les statistiques des vulnérabilités classiques, sans être classés séparément.
La raison de l'abandon des pools AMM V3 de Raydium est l'arrêt définitif du projet Serum dont ils dépendaient, rendant cet ancien ensemble de contrats totalement inopérant, les actifs de liquidité correspondants restant inactifs sur la chaîne.
Les nouveaux contrats actuellement utilisés par Raydium vérifient doublement deux informations clés : premièrement, un mécanisme de vérification des totaux pour contrôler la proportion des actifs, et deuxièmement, la vérification de l'adresse de frappe des jetons de liquidité ainsi que de diverses informations de comptes associés.
Mais cet ancien contrat V3 omet complètement ces deux étapes de vérification. Le pirate a exploité cette vulnérabilité pour forger de nouveaux jetons de liquidité et se faire passer pour des titres légitimes, contournant ainsi toutes les règles de contrôle des risques.
Lors de cet incident, environ 150 177 RAY, 5 603 SOL et 893 700 USDC ont été volés. Ces actifs étaient stockés depuis longtemps dans les anciens pools de la plateforme. Bien que séparés de l'activité principale, leurs autorisations d'appel sur la chaîne n'avaient jamais été fermées.
Huit cas révèlent des problèmes communs
Depuis 2025, plusieurs projets DeFi connus sont tombés dans le piège des anciens contrats. Tous les événements présentent les mêmes caractéristiques : les équipes des projets déclarent que la version actuelle du produit et les utilisateurs actifs ne sont pas affectés, mais comme les anciens contrats n'ont pas été complètement désactivés, c'est finalement le trésor du projet qui supporte l'intégralité des pertes.
Pourquoi le risque des anciens contrats est-il négligé ?
Actuellement, la grande majorité des systèmes de classification des incidents de sécurité dans le secteur se concentrent sur les moyens d'attaque, les objets de manipulation, les points de défaillance du code, adoptant une perspective d'analyse « partant de la vulnérabilité technique ». Cela conduit également à masquer les incidents de type « contrat zombie ». Le cœur de ce type de problème n'a jamais été une erreur d'écriture du code, mais le fait que le projet aurait dû complètement désactiver l'ancien contrat mais ne l'a pas fait.
Un document de recherche du secteur datant de 2025, analysant 50 incidents de sécurité cryptographiques majeurs dans le monde entre 2022 et 2025, pour des pertes cumulées dépassant 1 milliard de dollars, a souligné que les attaques à fort impact sur la chaîne résultent souvent d'une superposition de risques en chaîne, impliquant simultanément plusieurs niveaux : opérations humaines, maintenance quotidienne, modèles économiques, cycle de vie des contrats, gouvernance communautaire, etc.
Le document propose un cadre d'analyse des causes profondes à quatre niveaux, classant clairement les vulnérabilités de gestion du cycle de vie des contrats et les vulnérabilités de gouvernance communautaire comme des catégories de risque indépendantes des vulnérabilités d'écriture de code. Le problème des contrats zombies est précisément une vulnérabilité typique de gestion du cycle de vie. Mais dans les systèmes statistiques de sécurité existants, ce type d'incident est généralement classé sous « vulnérabilité de code », et les données de pertes correspondantes sont masquées sous d'autres classifications, n'attirant pas suffisamment l'attention du secteur.
Méfiez-vous du « cimetière de contrats » : les anciennes infrastructures sont devenues une nouvelle cible d'attaque
Si les projets DeFi continuent de considérer la « désactivation des contrats » comme une tâche optionnelle, se contentant d'indiquer « ce contrat est désactivé » dans la documentation produit, sans retirer les actifs inactifs, fermer les fonctions d'appel, ni surveiller continuellement leur état, alors les pirates continueront de cibler ce « cimetière de contrats ».
Les historiques de déploiement de chaque grand projet DeFi sont désormais des cibles d'attaque consultables et exploitables par les pirates. Les 22,5 millions de dollars de pertes actuellement recensés ne représentent que la valeur des cas rendus publics. Le risque réel est bien plus élevé.
Les anciens pools de liquidités contenant des actifs mais éloignés du flux d'utilisation principal des utilisateurs, les interfaces d'autorisation historiques, les modules de coopération et d'intégration précoces, bénéficient d'une surveillance opérationnelle bien inférieure à celle des systèmes métier actuels, ce qui en fait précisément des cibles de choix pour les pirates.
Pour changer la situation, il faut d'abord classer les « contrats zombies » comme une catégorie de risque indépendante et les comptabiliser séparément dans les incidents. Ensuite, il faut intégrer le processus de désactivation des contrats dans les procédures de sécurité standardisées, au même niveau que l'audit de code. Une maintenance opérationnelle sur l'ensemble du cycle de vie est nécessaire pour réduire efficacement la surface d'attaque.
Les méthodes de traitement actuelles dans le secteur sont très similaires. Raydium a utilisé son trésor de projet pour compenser la perte de 1,34 million de dollars. Transit Finance et Huma Finance ont également assumé les pertes des utilisateurs via les fonds du projet.
Cela signifie également que la désactivation des contrats n'est plus seulement un travail de documentation, mais un maillon indispensable du contrôle de la sécurité.
Sept normes de contrôle de sécurité pour la désactivation des contrats
Pour la désactivation des anciens contrats, le secteur peut établir un processus de contrôle standardisé, avec les exigences et rôles spécifiques suivants :
Se contenter d'indiquer « contrat désactivé » dans la documentation, c'est simplement transférer le risque de sécurité au trésor du projet, tandis que le risque d'attaque persiste. Annoncer la désactivation uniquement au niveau produit sans la mettre en œuvre techniquement signifie que l'ancien contrat restera toujours appelable : l'équipe du projet le néglige, mais les pirates le surveillent constamment.
La valeur des projets DeFi ne réside pas seulement dans le montant actuel d'actifs verrouillés (TVL), mais aussi dans le code historique et l'architecture sous-jacente accumulés au fil du temps. Et ces morceaux d'histoire oubliés sont désormais devenus de nouvelles brèches de sécurité.
