Le protocole Drift est victime d’une attaque de pirates informatiques, avec une perte de 285 millions de dollars

Le 1er avril 2026, la plateforme d’échange de contrats perpétuels décentralisés de l’écosystème Solana Drift Protocol a été victime d’une attaque de pirates informatiques, avec un total d’actifs dérobés d’environ 285 millions de dollars. Les attaquants ont obtenu des droits d’administrateur sur le portefeuille multi-signatures (multisig) du protocole, puis ont vidé en l’espace d’une heure plusieurs pools de fonds, notamment USDC, SOL, cbBTC, WETH, etc., avant de transférer ces fonds de manière inter-chaînes vers le réseau Ethereum pour les échanger contre environ 129 000 ETH (valeur d’environ 278 millions de dollars). Au 2 avril 2026, les fonds dérobés ont été répartis sur 4 adresses Ethereum ; la valeur totale verrouillée (TVL) du protocole est passée brutalement de 550 millions de dollars à environ 255 millions de dollars. Cet événement est devenu l’incident de sécurité à la plus grosse perte en un seul cas de l’année 2026 dans le domaine DeFi.

Chronologie de l’attaque et chemin technique

L’attaque n’a pas été soudaine : elle a été précédée d’une période de préparation d’environ huit jours. D’après les données on-chain, l’adresse du portefeuille de l’attaquant HkGz4K… a été créée le 24 mars 2026. Elle a obtenu des fonds initiaux via le système cross-chain NEAR Intents, puis a envoyé un petit test de transaction (environ 2,52 dollars) au Drift Vault afin de vérifier les droits de contrôle du contrat. La fenêtre d’attaque a été officiellement ouverte le 1er avril à 16:00 UTC :

• Première transaction : retrait d’environ 41,70 millions de jetons JLP depuis le coffre Drift (valeur d’environ 155,6 millions de dollars).
• Par la suite, environ 11 transactions coordonnées ont été effectuées et ont extrait successivement des actifs tels que USDC, SOL, cbBTC, wBTC, WETH, etc., dans un délai de 60 minutes, pour un total cumulé de 285 millions de dollars.

Sur le plan technique, l’attaquant n’a pas exploité une faille dans le code d’un contrat intelligent. Il a plutôt, en obtenant des droits d’administrateur du portefeuille multi-signatures, réalisé les opérations suivantes une par une : création de faux jetons CVT → manipulation des prix de l’oracle → désactivation du module de sécurité → extraction des actifs à haute valeur.

Faille de sécurité centrale : mécanisme multi-signatures et absence de timelock

La cause directe de cette attaque réside dans une faiblesse de sécurité dans la configuration du multi-signatures du protocole Drift. Dans son rapport de reconstitution, SlowMist (une organisation de sécurité) indique qu’environ une semaine avant l’attaque, Drift a ajusté le mécanisme multi-signatures en mode « 2/5 » (1 ancien signataire + 4 nouveaux signataires), sans configurer de timelock (Timelock).

Un timelock est un mécanisme de délai imposé : après toute modification de configuration nécessitant des droits élevés, il faut attendre 24 à 48 heures pour que la modification devienne effective, offrant ainsi une fenêtre tampon de détection des anomalies au profit de la communauté et des organismes de sécurité. En l’absence de timelock, dès que la clé privée d’un nouveau signataire est volée ou contrôlée de manière malveillante, l’attaquant peut exécuter immédiatement des opérations de niveau administrateur. L’attaquant a exploité l’unique ancien signataire du multi-signatures, en le faisant signer en coordination avec un autre signataire nouvellement ajouté, afin de transférer les droits d’administrateur vers une adresse qu’il contrôle, contournant ainsi toutes les protections côté utilisateurs.

Logique de blanchiment par transfert inter-chaînes et conversion en ETH

Après avoir réussi, les attaquants ont lancé le processus de traitement des fonds :

1. Transfert inter-chaînes : via des protocoles cross-chain comme Wormhole, transfert d’actifs multi-devises sur la chaîne Solana vers le réseau Ethereum.
2. Conversion unifiée : sur une bourse décentralisée Ethereum, conversion de l’ensemble des actifs tels que USDC, SOL, wBTC, etc., en ETH.
3. Adresses dispersées : environ 129 000 ETH (valeur d’environ 278 millions de dollars) ont été répartis sur 4 adresses Ethereum et stockés.

Le choix de l’ETH comme actif final s’explique par : une liquidité maximale sur le réseau Ethereum, facilitant une réalisation rapide en espèces ; la conversion des fonds illicites multi-devises en un seul actif pour couper la trace de pistage on-chain des fonds d’origine ; et la dispersion des adresses réduisant le risque qu’une adresse unique soit intégralement gelée. Une partie de l’USDC sur le réseau Ethereum a été gelée par l’émetteur Circle, mais sa proportion dans le montant total dérobé est extrêmement faible.

Impact sur la TVL du protocole Drift et sur l’écosystème Solana

L’impact financier direct de l’événement sur le protocole Drift se reflète dans les données TVL. D’après les statistiques de DeFiLlama :

Point dans le temps (UTC)

TVL (en dollars)

1er avril 00:00

Environ 550 millions

1er avril 22:41

Environ 255 millions

La division par deux de la TVL implique une réduction de la taille des pools de liquidité. Cela entraînera une hausse du slippage lors des transactions, une baisse de l’efficacité des capitaux, puis une compression du volume de transactions du protocole et des revenus de frais. D’un point de vue plus macro de l’écosystème Solana, cet événement constitue le plus grand incident de sécurité DeFi de cet écosystème depuis l’attaque de pont Wormhole en 2022 (326 millions de dollars). Entre janvier et mars 2026, 15 protocoles DeFi ont subi des pertes cumulées d’environ 137 millions de dollars, tandis que la perte liée à l’événement unique de Drift représente environ le double de ce montant, et dépasse largement l’ancien record de perte unique précédent de 27,3 millions de dollars.

Rôle d’intervention de l’émetteur de stablecoins et zone grise de régulation

La vitesse de réaction de l’émetteur de stablecoins Circle a suscité des discussions dans l’industrie. Après l’attaque, une partie de l’USDC a été gelée sur le réseau Ethereum par Circle, mais une grande quantité d’USDC transférés via des ponts inter-chaînes n’a pas été interceptée en temps voulu, car elle ne passait pas par les adresses de custody directes de Circle. ZachXBT, un analyste on-chain, a formulé une critique à ce sujet, estimant que Circle présentait un retard de réponse dans son mécanisme de gel de l’USDC inter-chaînes.

Cette controverse met en lumière une zone grise en matière de régulation dans les événements de sécurité DeFi : l’obligation d’intervention proactive de l’émetteur de stablecoins dans un environnement inter-chaînes ne dispose pas d’un cadre légal clair et d’un consensus industriel. À l’heure actuelle, des émetteurs comme Circle ne peuvent geler que l’USDC contrôlé par des adresses détenues directement par Circle sur sa chaîne native (Ethereum). Pour l’« USDC ponté » généré via des ponts tiers comme Wormhole, ou les actifs enveloppés après inter-chaînage, l’émetteur ne dispose pas d’un droit de gel direct. Ce cas pourrait pousser les autorités de régulation à formuler des exigences plus spécifiques sur les obligations de réponse aux risques des émetteurs de stablecoins.

Conclusion

La contradiction structurelle au cœur de l’incident d’attaque de Drift réside dans le fait que : côté utilisateurs, les protocoles DeFi se présentent comme non-custodial et sans nécessité de faire confiance, mais au niveau de la gestion, ils conservent souvent des droits administrateurs très centralisés (généralement appelés « clé de Dieu »). Une fois les droits administrateur obtenus, l’attaquant est capable d’exécuter trois opérations à haut risque au cours d’une seule transaction : créer de faux marchés, manipuler les prix de l’oracle, et lever les restrictions de retrait. Cela montre que le protocole ne dispose pas de mécanismes de vérification multi-couches, de seuils de retard d’opération, et de conditions de déclenchement de la sécurité en temps réel.

Il convient de noter que le protocole Drift, dans sa version v1 de 2022, avait déjà perdu 14,5 millions de dollars à cause d’un problème similaire lié à des droits de gestion. L’équipe a ensuite effectué un dédommagement intégral et publié une reconstitution technique. Quatre ans plus tard, le même schéma se répète à une échelle plus grande, indiquant que même après des analyses et des itérations, le risque de centralisation des privilèges dans l’architecture de sécurité fondamentale n’a pas été résolu à la racine.

FAQ

Q : Est-il possible de récupérer les 285 millions de dollars dérobés à Drift Protocol ?

Au 2 avril 2026, les fonds dérobés ont été transférés inter-chaînes vers le réseau Ethereum, convertis en ETH et répartis sur 4 adresses. Le taux de récupération global des fonds dans les événements de sécurité DeFi de 2026 est inférieur à 7 % (sur 137 millions de dollars, seuls 9 millions ont été récupérés). Étant donné que l’attaquant a utilisé une dispersion multi-adresses éprouvée et un chemin de blanchiment inter-chaînes, la faisabilité d’une récupération technique est extrêmement faible.

Q : Cette attaque a-t-elle affecté la sécurité d’autres protocoles DeFi de l’écosystème Solana ?

Cette attaque provient d’une faille spécifique du protocole Drift dans la configuration de son multi-signatures et de son mécanisme de timelock, et non d’une déficience systémique de la blockchain sous-jacente de Solana ou d’une norme générale de contrat intelligent. Cependant, l’événement va significativement accroître la rigueur des audits et l’attention des utilisateurs sur la configuration des droits de gestion des autres protocoles DeFi au sein de l’écosystème Solana, ce qui pourrait entraîner une redistribution inter-protocoles de la TVL à court terme.

Q : Comment les développeurs de protocole peuvent-ils empêcher des attaques similaires basées sur des droits administrateur ?

Les standards de sécurité de l’industrie recommandent trois mesures clés : premièrement, définir un timelock d’au moins 24 heures pour tout changement de configuration nécessitant des droits élevés, avec des systèmes de surveillance automatisés et des alertes ; deuxièmement, utiliser un schéma de multi-signatures d’au moins 4/7 ou supérieur, avec les clés privées des signataires stockées dans un module de sécurité matériel (HSM) et isolées physiquement ; troisièmement, déployer un module de gestion du risque on-chain en temps réel, de sorte que lorsque une transaction unique implique des opérations administrateur et que le montant dépasse un seuil prédéfini, une exécution différée et un processus de validation par la communauté soient automatiquement déclenchés.