Hier, nous étions encore en train de flipper à cause de la fuite de clé privée de la fondation Humanity Protocol, qui a entraîné la disparition de 36 millions de dollars en tokens $H, et aujourd'hui, l'écosystème Solana connaît également un vol.
Le 12 juin 2026, le DEX phare de l'écosystème Solana, Raydium, a subi une attaque, entraînant une perte d'environ 1,34 million de dollars.
Heureusement, l'équipe de Raydium a confirmé que cette attaque n'a pas affecté les fonds des utilisateurs utilisant la dernière version de leur protocole ou produit. Les attaquants ont exploité un ancien contrat qui était déjà obsolète.
Récapitulatif de l'attaque de Raydium
Selon les analyses on-chain et les informations divulguées par la communauté, le chemin central de l'attaque est le suivant :
Identifier les "actifs fantômes" : l'attaquant a, par une analyse systématique, trouvé un ancien contrat utilisé pour gérer un pool de liquidité (LP) spécifique déployé sur Raydium il y a plusieurs années. Ce contrat a depuis été remplacé par une nouvelle version, et l'interface frontale associée a également été mise hors ligne, presque complètement oubliée par tout le monde.
À la recherche de la "clé oubliée" : le point crucial est que, bien que ce contrat ait été abandonné, ses privilèges suprêmes - c'est-à-dire les "droits du propriétaire" (Owner Authority) - n'ont pas été officiellement révoqués ou détruits. Ce privilège pointe toujours vers un portefeuille d'un déployeur précoce. L'attaquant a d'une manière ou d'une autre (peut-être par une attaque d'ingénierie sociale ciblant ce portefeuille ou en exploitant une vulnérabilité historique) pris le contrôle de cette "clé".
Exécuter le pillage "légitime" : armé des plus hauts privilèges, l'attaquant peut "interagir légitimement" avec ce vieux contrat. Ils ont appelé une fonction de privilège dans le contrat, semblable à withdraw_pnl, qui permet au propriétaire du contrat de retirer les frais cumulés ou des actifs spécifiques du pool. Comme ce vieux pool contenait encore des actifs de liquidité de certains utilisateurs, l'attaquant a facilement siphonné environ 1,34 million de dollars.
Une fois les fonds en main, l'attaquant a rapidement exécuté un processus typique de "blanchiment" : transférant les actifs volés de la chaîne Solana via un pont inter-chaînes vers le réseau Ethereum, puis les a envoyés dans des protocoles de mixage comme Tornado Cash, coupant complètement les pistes. Pendant tout le processus, pour le système principal actuel de Raydium, c'était presque "insensible", jusqu'à ce que l'alerte de mouvement de fonds sur la chaîne retentisse, et que l'équipe s'en rende compte.
Qui est le prochain Raydium ?
"La dette technique" devient le principal tueur des protocoles DeFi.
La "dette technique", en termes simples, c'est lorsque le projet cherche à aller vite pour le lancement et à itérer rapidement, en adoptant des solutions temporaires non optimales, pensant "on le peaufine plus tard". Éliminer et retirer les vieux contrats est l'un des aspects les plus facilement repoussés à plus tard. De nombreux projets nés de la frénésie DeFi de 2020-2022 ont déployé une multitude de contrats pour suivre les tendances. Aujourd'hui un minage de liquidité, demain un pool IDO, après-demain un nouvel algorithme... Les versions évoluent rapidement, mais ces vieux contrats qui ont accompli leur mission historique sont souvent simplement "abandonnés" plutôt que "détruits".
Cette approche a entraîné une expansion exponentielle de la surface d'attaque. Chaque ancien contrat mal géré est une bombe à retardement potentielle. Les hackers ont déjà compris cela, et ils scannent systématiquement et par scripts toutes les grandes chaînes, cherchant spécifiquement ceux qui :
Anciens projets déployés tôt (généralement avant 2022).
Le contrat détient encore certains actifs (même si ce ne sont que des fonds résiduels des utilisateurs).
Contrats dont les droits du propriétaire ou les droits administratifs n'ont jamais été révoqués.
Il n'est pas exagéré de dire qu'une vague d'attaques "archéologiques" ciblant les premiers protocoles DeFi pourrait être en préparation. Surtout pour ceux qui ont subi de nombreuses mises à jour majeures et qui portent un lourd héritage, ces projets doivent être particulièrement vigilants. Combien de projets se souviennent encore clairement de leur premier contrat LP de staking déployé il y a deux ans, de savoir si ses droits d'administrateur ont été transférés, révoqués ou s'ils ont disparu avec un ancien employé ?
Prévenir plutôt que guérir : liste de contrôle de sécurité pour les projets.
Créer un "bilan d'actifs du contrat" : dresser immédiatement une liste détaillant toutes les adresses de contrats intelligents déployés depuis la création du projet. Indiquer l'utilisation de chaque contrat, son état actuel (actif/abandonné/retrait), son mode de contrôle des permissions ainsi que l'adresse actuelle de l'administrateur ou du propriétaire.
Exécuter le "sunset des permissions" : pour tous les contrats confirmés comme abandonnés, les permissions doivent être révoquées immédiatement.
Comment "retirer en toute sécurité" un contrat ? L'industrie a déjà des meilleures pratiques établies, par exemple en utilisant la bibliothèque standard OpenZeppelin largement auditée.
Mettre en place une surveillance automatisée : configurer une surveillance des activités sur la chaîne pour toutes les adresses de contrats abandonnés. En théorie, ces adresses ne devraient plus avoir de transactions. Si une invocation se produit, en particulier des invocations liées aux permissions, cela devrait immédiatement déclencher une alerte de sécurité de niveau supérieur.