Le 22 mai, le protocole DEX de premier plan sur l'écosystème Sui, Cetus, a été victime d'une attaque de hacker, une vulnérabilité étant apparue dans le contrat principal du protocole, permettant à l'attaquant de siphonner une grande quantité d'actifs. L'incident a suscité une large attention dans un court laps de temps, touchant non seulement les utilisateurs concernés, mais incitant également plusieurs projets Sui à entrer en état d'urgence.
Mais ce qui a suivi n’était pas un retour en arrière en chaîne ou une intervention de super autorisation, mais un démarrage rapide : vote des validateurs, arrêt actif du projet, gel des actifs sur la chaîne, auto-inspection et mise à niveau du protocole...... L’ensemble du processus constitue un véritable exercice de gouvernance de la sécurité financière on-chain.
À la date de rédaction de cet article, cela fait cinq jours que cet incident de piratage s'est produit. Cet événement a eu un large impact, suscitant des discussions animées au sein de la communauté sur la "sécurité sur la chaîne", la "gouvernance décentralisée" et la "réponse d'urgence des protocoles".
Cet article essaie de clarifier : que s'est-il passé cette fois-ci ? Qui est responsable ? Comment l'écosystème Sui a-t-il réagi ? Que devons-nous en apprendre ?
Comment l'attaque s'est-elle produite ?
L'attaque a eu lieu le 22 mai 2025 au matin, ciblant le pool de liquidités CLMM de Cetus. L'attaquant a découvert une vulnérabilité dans le contrat et a exploité les transactions pour siphonner des actifs au cours de plusieurs opérations.
Le processus spécifique est le suivant :
Vers 10h30 UTC, l'attaque a commencé. Les hackers ont fait chuter le prix dans le pool par des transactions anormales, tout en ouvrant des positions de liquidité à prix élevé, et ont exploité des failles logiques dans les contrats pour injecter une grande quantité de liquidité "falsifiée" avec une très petite quantité de jetons.
Ensuite, le hacker exécute à plusieurs reprises "Ajouter/Retirer de la liquidité", siphonnant ainsi des actifs réels du pool.
L'attaque a duré environ 20 minutes, et certains systèmes de surveillance ont commencé à sonner l'alarme.
40 minutes après l’attaque
À 10h40 UTC, le système de surveillance de Cetus a détecté un comportement anormal du pool.
10:53 UTC, l'équipe de Cetus a confirmé la source de l'attaque et a informé d'autres projets de l'écosystème Sui.
10:57 UTC, Cetus a immédiatement fermé le pool de liquidité principal pour éviter d'autres pertes.
11:20 UTC, arrêt complet des contrats concernés.
Cette réaction est très rapide, mais les hackers ont déjà volé une grande quantité de fonds.
Comment les fonds des hackers sont-ils gelés ?
Après l’extension de l’incident, l’écosystème a lancé une réponse d’urgence plus large :
Les validateurs Sui commencent rapidement à collaborer sur la chaîne, votant pour savoir s'ils doivent refuser de regrouper les transactions des adresses des hackers ;
Après avoir atteint le seuil de 33 % de mise, l'adresse du hacker a été efficacement gelée, et les transactions ne peuvent plus être traitées sur la chaîne.
Ce n'est pas un retour en arrière du système, ni une intervention en arrière-plan, mais une action effectuée par les validateurs via un mécanisme de consensus. L'état de la chaîne n'a pas été modifié, les transactions des utilisateurs n'ont pas été altérées, tout est réalisé en fonction des règles existantes sur la chaîne.
Ce que l’on appelle le « retour en arrière du système » fait référence au retour de l’état de l’ensemble du réseau blockchain à un certain moment avant l’attaque, comme un retour dans le temps. Cela signifie généralement que les transactions qui ont déjà été confirmées sont effacées et que l’historique de la chaîne est réécrit. L'« intervention back-end » fait référence au contrôle direct de nœuds ou de fonds par une autorité centralisée (telle qu’une partie du projet ou une fondation), en contournant le processus normal de prise de décisions de traitement.
Dans ce cas, rien de tout cela ne s’est produit. Les validateurs gèlent selon des règles on-chain par le biais du vote public, de la prise de décision autonome et de la décentralisation, qui est l’incarnation de la gouvernance décentralisée.
Quelle est la situation financière actuelle ?
Les données publiées par Cetus sont les suivantes :
Les hackers ont volé des actifs d'environ 230 millions de dollars.
Parmi cela, 160 millions de dollars d'actifs sont toujours bloqués dans deux adresses Sui gelées et ne peuvent plus être transférés ;
60 millions de dollars d’actifs ont été transférés vers Ethereum à travers les chaînes, et deux adresses sont connues pour être toujours tracées.
Le protocole encourage le vote de la communauté pour décider comment procéder au remboursement et à l'indemnisation des actifs.
Pourquoi cela s'est-il produit ? Est-ce un problème lié à la chaîne elle-même ? Ou est-ce un problème de vulnérabilité au niveau de l'application ?
Selon le rapport de Slow Mist et les analyses de grands influenceurs techniques, tous pointent vers le même problème : la racine de l'incident réside dans un problème de logique de code open source utilisé dans le contrat Cetus. L'attaquant a exploité une erreur liée à une vérification de débordement de données dans le contrat de couche application ; si cette vulnérabilité avait été détectée et corrigée à l'avance, elle n'aurait pas causé de pertes. Il ne s'agit donc pas d'une vulnérabilité de langage de programmation Move en soi.
Il est tout aussi important de noter que le réseau Sui lui-même n'a pas été attaqué et qu'aucun risque systémique n'est apparu.
C'est un événement standard de "sécurité de couche de protocole", ce n'est pas un problème de sécurité de couche de chaîne.
Que doivent faire les autres projets de l'écosystème Sui après une attaque ?
Après l’arrêt de Cetus, un certain nombre de projets sur Sui ont commencé à effectuer des auto-inspections de sécurité, et nous avons observé que le protocole Momentum suspendait également les transactions dès que l’attaque se produisait, terminait l’audit du code de la chaîne complète et la vérification des risques, et reprenait après le gel des fonds volés.
En tant que leader actuel de Dex dans l’écosystème Sui, le protocole Momentum a cessé de trader dès que possible et a coopéré avec la Fondation Sui pour bloquer les fonds volés afin d’empêcher les pirates de les propager à d’autres comptes d’actifs de trading via le trading Dex. Dans le même temps, un auto-examen minutieux a été effectué, et après que les résultats de l’auto-examen étaient corrects, et après avoir confirmé que les fonds volés avaient été gelés avec succès par la Fondation Sui, la fonction de transaction a d’abord été rétablie.
Quel est le suivi de l'événement ?
Actuellement :
Cetus a terminé la correction des vulnérabilités majeures et est en train de revoir le code avec l'équipe d'audit ;
Le plan de compensation des utilisateurs est en cours d'élaboration, en partie déterminé par le vote sur les propositions de gouvernance écologique.
D'autres projets Sui ont également repris leur fonctionnement ou sont en train de finaliser leur renforcement de sécurité.
L'ensemble de l'écosystème n'a pas été paralysé, mais a plutôt examiné de manière plus systématique les mécanismes de sécurité après l'événement.
Que nous dit cet événement ?
Cette attaque contre Cetus confronte à nouveau tous les bâtisseurs et utilisateurs à un problème de réalité :
À quoi repose vraiment la sécurité des protocoles ?
La réponse devient de plus en plus claire :
S'appuyer sur l'intelligence collective apportée par la décentralisation, et non utiliser la décentralisation comme excuse pour ne rien faire ;
S'appuyer sur des investissements systémiques continus, pas seulement sur un ou deux rapports d'audit ;
S'appuyer sur la préparation quotidienne et la construction de mécanismes, pas seulement sur des mesures correctives après coup ;
Cela dépend de chaque participant prêt à assumer ses responsabilités et à agir de manière proactive, plutôt que de rejeter le problème sur la "chaîne" ou la "technologie".
Nous avons constaté que les hackers ont effectivement causé des pertes, mais ils n'ont pas détruit le système ;
On voit aussi que la décentralisation n'est pas de se cacher derrière des règles en observant froidement, mais de se rassembler spontanément, de défendre les limites et de protéger les utilisateurs.
Conclusion
La véritable décentralisation, ce n'est pas un slogan, c'est une responsabilité.
Il n'y a pas de sauveur dans cette tempête.
Les validateurs Sui ont gelé les transactions à risque ; d'autres protocoles ont terminé leur auto-vérification de sécurité, certains ont rapidement repris leurs opérations ; les utilisateurs continuent également de surveiller et d'encourager des améliorations.
La décentralisation n'est pas un abandon, mais une collaboration avec des limites, des principes et des responsabilités.
Dans un système sans arrière-plan, la confiance doit être soutenue par chaque ligne de code, chaque mécanisme, chaque décision.
Cet événement est une crise, un examen et aussi un miroir.
Elle nous dit :
La décentralisation n'est pas un but, mais une méthode, l'objectif étant de construire la confiance ; la décentralisation apporte la sagesse collective.
La décentralisation est certes importante, mais l'efficacité des fonds et la sécurité des protocoles sont encore plus importantes.
Le contenu est fourni à titre de référence uniquement, il ne s'agit pas d'une sollicitation ou d'une offre. Aucun conseil en investissement, fiscalité ou juridique n'est fourni. Consultez l'Avertissement pour plus de détails sur les risques.
Après l'attaque de Cetus par des hackers : que devrions-nous comprendre de cette tempête ?
Présentation
Le 22 mai, le protocole DEX de premier plan sur l'écosystème Sui, Cetus, a été victime d'une attaque de hacker, une vulnérabilité étant apparue dans le contrat principal du protocole, permettant à l'attaquant de siphonner une grande quantité d'actifs. L'incident a suscité une large attention dans un court laps de temps, touchant non seulement les utilisateurs concernés, mais incitant également plusieurs projets Sui à entrer en état d'urgence.
Mais ce qui a suivi n’était pas un retour en arrière en chaîne ou une intervention de super autorisation, mais un démarrage rapide : vote des validateurs, arrêt actif du projet, gel des actifs sur la chaîne, auto-inspection et mise à niveau du protocole...... L’ensemble du processus constitue un véritable exercice de gouvernance de la sécurité financière on-chain.
À la date de rédaction de cet article, cela fait cinq jours que cet incident de piratage s'est produit. Cet événement a eu un large impact, suscitant des discussions animées au sein de la communauté sur la "sécurité sur la chaîne", la "gouvernance décentralisée" et la "réponse d'urgence des protocoles".
Cet article essaie de clarifier : que s'est-il passé cette fois-ci ? Qui est responsable ? Comment l'écosystème Sui a-t-il réagi ? Que devons-nous en apprendre ?
Comment l'attaque s'est-elle produite ?
L'attaque a eu lieu le 22 mai 2025 au matin, ciblant le pool de liquidités CLMM de Cetus. L'attaquant a découvert une vulnérabilité dans le contrat et a exploité les transactions pour siphonner des actifs au cours de plusieurs opérations.
Le processus spécifique est le suivant :
Vers 10h30 UTC, l'attaque a commencé. Les hackers ont fait chuter le prix dans le pool par des transactions anormales, tout en ouvrant des positions de liquidité à prix élevé, et ont exploité des failles logiques dans les contrats pour injecter une grande quantité de liquidité "falsifiée" avec une très petite quantité de jetons.
Ensuite, le hacker exécute à plusieurs reprises "Ajouter/Retirer de la liquidité", siphonnant ainsi des actifs réels du pool.
L'attaque a duré environ 20 minutes, et certains systèmes de surveillance ont commencé à sonner l'alarme.
40 minutes après l’attaque
À 10h40 UTC, le système de surveillance de Cetus a détecté un comportement anormal du pool.
10:53 UTC, l'équipe de Cetus a confirmé la source de l'attaque et a informé d'autres projets de l'écosystème Sui.
10:57 UTC, Cetus a immédiatement fermé le pool de liquidité principal pour éviter d'autres pertes.
11:20 UTC, arrêt complet des contrats concernés.
Cette réaction est très rapide, mais les hackers ont déjà volé une grande quantité de fonds.
Comment les fonds des hackers sont-ils gelés ?
Après l’extension de l’incident, l’écosystème a lancé une réponse d’urgence plus large :
Les validateurs Sui commencent rapidement à collaborer sur la chaîne, votant pour savoir s'ils doivent refuser de regrouper les transactions des adresses des hackers ;
Après avoir atteint le seuil de 33 % de mise, l'adresse du hacker a été efficacement gelée, et les transactions ne peuvent plus être traitées sur la chaîne.
Ce n'est pas un retour en arrière du système, ni une intervention en arrière-plan, mais une action effectuée par les validateurs via un mécanisme de consensus. L'état de la chaîne n'a pas été modifié, les transactions des utilisateurs n'ont pas été altérées, tout est réalisé en fonction des règles existantes sur la chaîne.
Ce que l’on appelle le « retour en arrière du système » fait référence au retour de l’état de l’ensemble du réseau blockchain à un certain moment avant l’attaque, comme un retour dans le temps. Cela signifie généralement que les transactions qui ont déjà été confirmées sont effacées et que l’historique de la chaîne est réécrit. L'« intervention back-end » fait référence au contrôle direct de nœuds ou de fonds par une autorité centralisée (telle qu’une partie du projet ou une fondation), en contournant le processus normal de prise de décisions de traitement.
Dans ce cas, rien de tout cela ne s’est produit. Les validateurs gèlent selon des règles on-chain par le biais du vote public, de la prise de décision autonome et de la décentralisation, qui est l’incarnation de la gouvernance décentralisée.
Quelle est la situation financière actuelle ?
Les données publiées par Cetus sont les suivantes :
Les hackers ont volé des actifs d'environ 230 millions de dollars.
Parmi cela, 160 millions de dollars d'actifs sont toujours bloqués dans deux adresses Sui gelées et ne peuvent plus être transférés ;
60 millions de dollars d’actifs ont été transférés vers Ethereum à travers les chaînes, et deux adresses sont connues pour être toujours tracées.
Le protocole encourage le vote de la communauté pour décider comment procéder au remboursement et à l'indemnisation des actifs.
Pourquoi cela s'est-il produit ? Est-ce un problème lié à la chaîne elle-même ? Ou est-ce un problème de vulnérabilité au niveau de l'application ?
Selon le rapport de Slow Mist et les analyses de grands influenceurs techniques, tous pointent vers le même problème : la racine de l'incident réside dans un problème de logique de code open source utilisé dans le contrat Cetus. L'attaquant a exploité une erreur liée à une vérification de débordement de données dans le contrat de couche application ; si cette vulnérabilité avait été détectée et corrigée à l'avance, elle n'aurait pas causé de pertes. Il ne s'agit donc pas d'une vulnérabilité de langage de programmation Move en soi.
Il est tout aussi important de noter que le réseau Sui lui-même n'a pas été attaqué et qu'aucun risque systémique n'est apparu.
C'est un événement standard de "sécurité de couche de protocole", ce n'est pas un problème de sécurité de couche de chaîne.
Que doivent faire les autres projets de l'écosystème Sui après une attaque ?
Après l’arrêt de Cetus, un certain nombre de projets sur Sui ont commencé à effectuer des auto-inspections de sécurité, et nous avons observé que le protocole Momentum suspendait également les transactions dès que l’attaque se produisait, terminait l’audit du code de la chaîne complète et la vérification des risques, et reprenait après le gel des fonds volés.
En tant que leader actuel de Dex dans l’écosystème Sui, le protocole Momentum a cessé de trader dès que possible et a coopéré avec la Fondation Sui pour bloquer les fonds volés afin d’empêcher les pirates de les propager à d’autres comptes d’actifs de trading via le trading Dex. Dans le même temps, un auto-examen minutieux a été effectué, et après que les résultats de l’auto-examen étaient corrects, et après avoir confirmé que les fonds volés avaient été gelés avec succès par la Fondation Sui, la fonction de transaction a d’abord été rétablie.
Quel est le suivi de l'événement ?
Actuellement :
Cetus a terminé la correction des vulnérabilités majeures et est en train de revoir le code avec l'équipe d'audit ;
Le plan de compensation des utilisateurs est en cours d'élaboration, en partie déterminé par le vote sur les propositions de gouvernance écologique.
D'autres projets Sui ont également repris leur fonctionnement ou sont en train de finaliser leur renforcement de sécurité.
L'ensemble de l'écosystème n'a pas été paralysé, mais a plutôt examiné de manière plus systématique les mécanismes de sécurité après l'événement.
Que nous dit cet événement ?
Cette attaque contre Cetus confronte à nouveau tous les bâtisseurs et utilisateurs à un problème de réalité :
À quoi repose vraiment la sécurité des protocoles ?
La réponse devient de plus en plus claire :
S'appuyer sur l'intelligence collective apportée par la décentralisation, et non utiliser la décentralisation comme excuse pour ne rien faire ;
S'appuyer sur des investissements systémiques continus, pas seulement sur un ou deux rapports d'audit ;
S'appuyer sur la préparation quotidienne et la construction de mécanismes, pas seulement sur des mesures correctives après coup ;
Cela dépend de chaque participant prêt à assumer ses responsabilités et à agir de manière proactive, plutôt que de rejeter le problème sur la "chaîne" ou la "technologie".
Nous avons constaté que les hackers ont effectivement causé des pertes, mais ils n'ont pas détruit le système ;
On voit aussi que la décentralisation n'est pas de se cacher derrière des règles en observant froidement, mais de se rassembler spontanément, de défendre les limites et de protéger les utilisateurs.
Conclusion
La véritable décentralisation, ce n'est pas un slogan, c'est une responsabilité.
Il n'y a pas de sauveur dans cette tempête.
Les validateurs Sui ont gelé les transactions à risque ; d'autres protocoles ont terminé leur auto-vérification de sécurité, certains ont rapidement repris leurs opérations ; les utilisateurs continuent également de surveiller et d'encourager des améliorations.
La décentralisation n'est pas un abandon, mais une collaboration avec des limites, des principes et des responsabilités.
Dans un système sans arrière-plan, la confiance doit être soutenue par chaque ligne de code, chaque mécanisme, chaque décision.
Cet événement est une crise, un examen et aussi un miroir.
Elle nous dit :
La décentralisation n'est pas un but, mais une méthode, l'objectif étant de construire la confiance ; la décentralisation apporte la sagesse collective.
La décentralisation est certes importante, mais l'efficacité des fonds et la sécurité des protocoles sont encore plus importantes.