Le 22 mai 2025, Cetus a subi une attaque complexe de contrat intelligent ciblant le pool CLMM. Nous avons immédiatement pris des mesures pour atténuer l'impact. Ce rapport vise à divulguer de manière transparente la chronologie de l'événement, l'analyse des causes, l'état des fonds et les plans futurs, et à avancer ensemble dans les affaires ultérieures.
Chronologie des événements
Heure UTC 10:30:50 – L'attaque a été lancée par des transactions anormales.
UTC 10:40:00 - Le système de surveillance a détecté un comportement anormal du fonds.
UTC 10:53:00 - L'équipe de Cetus identifie la source de l'attaque et alerte les membres de l'écosystème Sui.
UTC 10:57:47 – Le pool CLMM principal a été désactivé pour prévenir l'aggravation des pertes.
UTC 11:20:00 - Tous les contrats intelligents connexes ont été désactivés globalement.
À 12h50 UTC – Les validateurs Sui commencent à voter pour refuser de traiter les transactions signées par des adresses d'attaquants. Lorsque le vote stake dépasse le seuil de 33 %, les validateurs "gèlent" effectivement ces adresses.
UTC heure 18:04:07 – Envoyer un message de négociation sur la chaîne à l'attaquant.
UTC heure 18:15:28 – Le contrat de vulnérabilité a été réparé et mis à niveau (pas encore redémarré).
Analyse d'attaque
L'attaquant a exploité une faille dans la bibliothèque open source inter\_mate du contrat CLMM, le processus d'attaque est le suivant :
a. L'attaquant initie un échange éclair (flash_swap) pour faire temporairement baisser le prix dans le pool de liquidités.
b. Ouvrir une position à des niveaux de prix plus élevés.
c. Utiliser la vérification de débordement incorrecte dans la logique ajouter_de_la_liquidité (add\_liquidity) pour injecter une valeur de liquidité gonflée avec très peu de jetons.
d. Éliminer les réserves de tokens en retirant la liquidité (remove_liquidity) plusieurs fois.
e. En utilisant des calculs non vérifiés (comme overflowing\_sub, get\_liquidity\_from\_a), répétez le processus ci-dessus avec des valeurs de liquidité soigneusement construites.
Cette vulnérabilité n'a pas été détectée lors des audits de sécurité précédents.
Cause fondamentale
La vulnérabilité provient d'une mauvaise compréhension de la sémantique de l'opération de décalage à gauche dans la bibliothèque open source integer-mate, sur laquelle dépend le contrat CLMM. Dans sa méthode checked\_shlw, la vérification réelle devrait être « la valeur d'entrée est-elle ≤2^192 », mais dans la version attaquée, elle a été mal vérifiée comme « ≤2^256 », ce qui a entraîné un échec de la vérification de débordement. C'est la seule véritable raison de l'attaque récente.
Les attaquants ont exploité les défauts mentionnés ci-dessus en manipulant l'échelle de prix (tick) du pool de fonds et le mécanisme de liquidité, réussissant à retirer une grande quantité d'actifs au cours de plusieurs cycles d'attaques.
Il convient de préciser que, récemment, des personnes sur les réseaux sociaux ont faussement pensé que l'attaque provenait de l' "erreur de vérification arithmétique MAX_U64" mentionnée dans le rapport d'audit précédent, ce qui a induit en erreur de nombreux utilisateurs mal informés. Nous déclarons par la présente : ce problème n'est pas lié à cette attaque. Ce problème est en lui-même seulement une suggestion d'optimisation au niveau de l'information, ne pouvant entraîner un retour en arrière des transactions que dans des cas extrêmes, et a déjà été optimisé et corrigé dans les versions précédentes.
Pour préserver l'intérêt commun de l'ensemble de l'écosystème, deux adresses de portefeuilles Sui de l'attaquant ont été d'urgence gelées, avec le soutien de la majorité des validateurs Sui. Les portefeuilles gelés contiennent la majeure partie des fonds volés :
Attaquant Sui portefeuille 1 (gelé) : 0xcd8962dad278d8b50fa0f9eb0186bfa4cbdecc6d59377214c88d0286a0ac9562
Attaquant Sui portefeuille 2 (gelé) : 0xe28b50cef1d633ea43d3296a3f6b67ff0312a5f1a99f0af753c85b8b5de8ff06
Les fonds volés restants ont été entièrement échangés et transférés vers l'ETH par les attaquants, et sont actuellement stockés dans les deux portefeuilles Ethereum suivants :
Portefeuille Ethereum de l'attaquant 1 : 0x0251536bfcf144b88e1afa8fe60184ffdb4caf16
Portefeuille Ethereum de l'attaquant 2 : 0x89012a55cd6b88e407c9d4ae9b3425f55924919b
Plans futurs
Révision des contrats et renforcement de la sécurité
Nous collaborons avec l'équipe de sécurité de Sui et plusieurs partenaires d'audit pour réexaminer les contrats mis à jour et réaliser un audit conjoint. Ce n'est qu'après une validation complète que les pools CLMM et les services connexes seront progressivement réactivés.
Nous prévoyons de lancer immédiatement un audit supplémentaire et de publier des rapports d'audit réguliers basés sur le TVL (valeur totale verrouillée). En même temps, nous continuerons à renforcer la surveillance on-chain, à optimiser la configuration de gestion des risques et à mettre en œuvre des limites de vitesse contrôlées sur la liquidité des actifs.
Récupération des actifs LP
Nous collaborons activement avec des partenaires clés de l'écosystème pour concevoir des solutions de récupération pour les pools de liquidités et les LP affectés, afin de rétablir dès que possible les fonctionnalités de retrait de liquidités et tous les services des pools affectés.
Pour atteindre l'objectif final de récupérer intégralement les pertes des utilisateurs, nous appelons sincèrement tous les validateurs Sui à soutenir le vote en chaîne que nous avons récemment lancé. Ce vote permettra aux utilisateurs de récupérer rapidement la majorité de leurs actifs. Avec votre soutien, nous avancerons le plus rapidement possible sur l'indemnisation des pertes des utilisateurs et la reconstruction de la confiance au sein de la communauté.
Travail juridique et de négociation
Tout en avançant dans les procédures légales et d'application de la loi, nous offrons également aux attaquants l'opportunité de devenir des hackers éthiques. Un avis final sera bientôt émis aux attaquants, et tous les progrès seront divulgués de manière transparente à la communauté.
Conclusion
Nous remercions sincèrement les utilisateurs, la fondation Sui et nos partenaires écologiques pour leur réponse rapide et leur soutien considérable, ce qui nous a permis de geler rapidement plus de 160 millions de dollars de fonds et de transmettre des informations clés aux parties affectées. En même temps, nous savons bien qu'un rétablissement complet prendra du temps et nous agissons activement pour accélérer le processus.
Depuis sa création, Cetus est l’une des équipes DeFi qui a le plus investi dans l’audit des contrats intelligents et la protection du système sur la chaîne Sui. Cependant, la réalité n’est pas aussi bonne qu’elle devrait l’être : les contrats sous-jacents et les bibliothèques open source sur lesquelles ils s’appuient ont fait l’objet de plusieurs séries d’audits et sont largement utilisés par les développeurs de l’écosystème, ce qui nous fait croire à tort qu’ils sont suffisamment sécurisés. Avec le recul, nous n’avons pas été assez vigilants. Cette dure leçon nous a appris qu’il faut faire plus.
À l'avenir, nous renforcerons le système de sécurité et le contrôle des risques par les mesures suivantes :
Utiliser des outils tels que Blockaid pour mettre en œuvre une surveillance en temps réel, détecter et répondre rapidement aux menaces et aux vulnérabilités.
Optimiser la gestion des risques, appliquer des limites de vitesse contrôlables sur la liquidité des actifs.
Améliorer la couverture des tests du code source des contrats intelligents
Indicateur de couverture de code public
Réaliser un audit avant la publication officielle, après des changements de code majeurs et lors de l'atteinte de jalons clés de TVL.
Mise à niveau du programme de récompense pour les bugs de type white hat, récompense élevée pour les rapports de bugs de valeur.
Les multiples mesures mentionnées ci-dessus sont déjà en cours de mise en œuvre, et nous continuerons à les approfondir.
De plus, nous réalisons que la protection des protocoles DeFi ne peut pas dépendre uniquement des efforts de l'équipe et des auditeurs, mais nécessite la force de tout l'écosystème - des développeurs aux contributeurs white hat actifs - pour surveiller, défendre et améliorer ensemble. Nous souhaitons rassembler toutes les forces disponibles pour construire une infrastructure durable et résiliente pour l'ensemble de l'écosystème, capable de résister à l'épreuve du temps.
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.
Cetus publie un rapport sur l'incident de vol : chronologie et détails de l'attaque révélés
Source : Cetus ; traduction : AIMan@Gold Finance
Le 22 mai 2025, Cetus a subi une attaque complexe de contrat intelligent ciblant le pool CLMM. Nous avons immédiatement pris des mesures pour atténuer l'impact. Ce rapport vise à divulguer de manière transparente la chronologie de l'événement, l'analyse des causes, l'état des fonds et les plans futurs, et à avancer ensemble dans les affaires ultérieures.
Chronologie des événements
Heure UTC 10:30:50 – L'attaque a été lancée par des transactions anormales.
UTC 10:40:00 - Le système de surveillance a détecté un comportement anormal du fonds.
UTC 10:53:00 - L'équipe de Cetus identifie la source de l'attaque et alerte les membres de l'écosystème Sui.
UTC 10:57:47 – Le pool CLMM principal a été désactivé pour prévenir l'aggravation des pertes.
UTC 11:20:00 - Tous les contrats intelligents connexes ont été désactivés globalement.
À 12h50 UTC – Les validateurs Sui commencent à voter pour refuser de traiter les transactions signées par des adresses d'attaquants. Lorsque le vote stake dépasse le seuil de 33 %, les validateurs "gèlent" effectivement ces adresses.
UTC heure 18:04:07 – Envoyer un message de négociation sur la chaîne à l'attaquant.
UTC heure 18:15:28 – Le contrat de vulnérabilité a été réparé et mis à niveau (pas encore redémarré).
Analyse d'attaque
L'attaquant a exploité une faille dans la bibliothèque open source
inter\_matedu contrat CLMM, le processus d'attaque est le suivant :a. L'attaquant initie un échange éclair (flash_swap) pour faire temporairement baisser le prix dans le pool de liquidités.
b. Ouvrir une position à des niveaux de prix plus élevés.
c. Utiliser la vérification de débordement incorrecte dans la logique
ajouter_de_la_liquidité (add\_liquidity)pour injecter une valeur de liquidité gonflée avec très peu de jetons.d. Éliminer les réserves de tokens en retirant la liquidité (remove_liquidity) plusieurs fois.
e. En utilisant des calculs non vérifiés (comme
overflowing\_sub,get\_liquidity\_from\_a), répétez le processus ci-dessus avec des valeurs de liquidité soigneusement construites.Cette vulnérabilité n'a pas été détectée lors des audits de sécurité précédents.
Cause fondamentale
La vulnérabilité provient d'une mauvaise compréhension de la sémantique de l'opération de décalage à gauche dans la bibliothèque open source
integer-mate, sur laquelle dépend le contrat CLMM. Dans sa méthodechecked\_shlw, la vérification réelle devrait être « la valeur d'entrée est-elle ≤2^192 », mais dans la version attaquée, elle a été mal vérifiée comme « ≤2^256 », ce qui a entraîné un échec de la vérification de débordement. C'est la seule véritable raison de l'attaque récente.Les attaquants ont exploité les défauts mentionnés ci-dessus en manipulant l'échelle de prix (tick) du pool de fonds et le mécanisme de liquidité, réussissant à retirer une grande quantité d'actifs au cours de plusieurs cycles d'attaques.
Il convient de préciser que, récemment, des personnes sur les réseaux sociaux ont faussement pensé que l'attaque provenait de l' "erreur de vérification arithmétique MAX_U64" mentionnée dans le rapport d'audit précédent, ce qui a induit en erreur de nombreux utilisateurs mal informés. Nous déclarons par la présente : ce problème n'est pas lié à cette attaque. Ce problème est en lui-même seulement une suggestion d'optimisation au niveau de l'information, ne pouvant entraîner un retour en arrière des transactions que dans des cas extrêmes, et a déjà été optimisé et corrigé dans les versions précédentes.
Adresse de l'attaquant (sur la chaîne Sui) :
0xe28b50cef1d633ea43d3296a3f6b67ff0312a5f1a99f0af753c85b8b5de8ff06
État des fonds
Pour préserver l'intérêt commun de l'ensemble de l'écosystème, deux adresses de portefeuilles Sui de l'attaquant ont été d'urgence gelées, avec le soutien de la majorité des validateurs Sui. Les portefeuilles gelés contiennent la majeure partie des fonds volés :
Attaquant Sui portefeuille 1 (gelé) : 0xcd8962dad278d8b50fa0f9eb0186bfa4cbdecc6d59377214c88d0286a0ac9562
Attaquant Sui portefeuille 2 (gelé) : 0xe28b50cef1d633ea43d3296a3f6b67ff0312a5f1a99f0af753c85b8b5de8ff06
Les fonds volés restants ont été entièrement échangés et transférés vers l'ETH par les attaquants, et sont actuellement stockés dans les deux portefeuilles Ethereum suivants :
Portefeuille Ethereum de l'attaquant 1 : 0x0251536bfcf144b88e1afa8fe60184ffdb4caf16
Portefeuille Ethereum de l'attaquant 2 : 0x89012a55cd6b88e407c9d4ae9b3425f55924919b
Plans futurs
Révision des contrats et renforcement de la sécurité
Nous collaborons avec l'équipe de sécurité de Sui et plusieurs partenaires d'audit pour réexaminer les contrats mis à jour et réaliser un audit conjoint. Ce n'est qu'après une validation complète que les pools CLMM et les services connexes seront progressivement réactivés.
Nous prévoyons de lancer immédiatement un audit supplémentaire et de publier des rapports d'audit réguliers basés sur le TVL (valeur totale verrouillée). En même temps, nous continuerons à renforcer la surveillance on-chain, à optimiser la configuration de gestion des risques et à mettre en œuvre des limites de vitesse contrôlées sur la liquidité des actifs.
Récupération des actifs LP
Nous collaborons activement avec des partenaires clés de l'écosystème pour concevoir des solutions de récupération pour les pools de liquidités et les LP affectés, afin de rétablir dès que possible les fonctionnalités de retrait de liquidités et tous les services des pools affectés.
Pour atteindre l'objectif final de récupérer intégralement les pertes des utilisateurs, nous appelons sincèrement tous les validateurs Sui à soutenir le vote en chaîne que nous avons récemment lancé. Ce vote permettra aux utilisateurs de récupérer rapidement la majorité de leurs actifs. Avec votre soutien, nous avancerons le plus rapidement possible sur l'indemnisation des pertes des utilisateurs et la reconstruction de la confiance au sein de la communauté.
Travail juridique et de négociation
Tout en avançant dans les procédures légales et d'application de la loi, nous offrons également aux attaquants l'opportunité de devenir des hackers éthiques. Un avis final sera bientôt émis aux attaquants, et tous les progrès seront divulgués de manière transparente à la communauté.
Conclusion
Nous remercions sincèrement les utilisateurs, la fondation Sui et nos partenaires écologiques pour leur réponse rapide et leur soutien considérable, ce qui nous a permis de geler rapidement plus de 160 millions de dollars de fonds et de transmettre des informations clés aux parties affectées. En même temps, nous savons bien qu'un rétablissement complet prendra du temps et nous agissons activement pour accélérer le processus.
Depuis sa création, Cetus est l’une des équipes DeFi qui a le plus investi dans l’audit des contrats intelligents et la protection du système sur la chaîne Sui. Cependant, la réalité n’est pas aussi bonne qu’elle devrait l’être : les contrats sous-jacents et les bibliothèques open source sur lesquelles ils s’appuient ont fait l’objet de plusieurs séries d’audits et sont largement utilisés par les développeurs de l’écosystème, ce qui nous fait croire à tort qu’ils sont suffisamment sécurisés. Avec le recul, nous n’avons pas été assez vigilants. Cette dure leçon nous a appris qu’il faut faire plus.
À l'avenir, nous renforcerons le système de sécurité et le contrôle des risques par les mesures suivantes :
Utiliser des outils tels que Blockaid pour mettre en œuvre une surveillance en temps réel, détecter et répondre rapidement aux menaces et aux vulnérabilités.
Optimiser la gestion des risques, appliquer des limites de vitesse contrôlables sur la liquidité des actifs.
Améliorer la couverture des tests du code source des contrats intelligents
Indicateur de couverture de code public
Réaliser un audit avant la publication officielle, après des changements de code majeurs et lors de l'atteinte de jalons clés de TVL.
Mise à niveau du programme de récompense pour les bugs de type white hat, récompense élevée pour les rapports de bugs de valeur.
Les multiples mesures mentionnées ci-dessus sont déjà en cours de mise en œuvre, et nous continuerons à les approfondir.
De plus, nous réalisons que la protection des protocoles DeFi ne peut pas dépendre uniquement des efforts de l'équipe et des auditeurs, mais nécessite la force de tout l'écosystème - des développeurs aux contributeurs white hat actifs - pour surveiller, défendre et améliorer ensemble. Nous souhaitons rassembler toutes les forces disponibles pour construire une infrastructure durable et résiliente pour l'ensemble de l'écosystème, capable de résister à l'épreuve du temps.