Imaginez un coffre-fort numérique censé libérer progressivement des tokens selon un calendrier strict. Tout semble parfaitement verrouillé. Pourtant, un simple oubli dans la façon de compter les parts a suffi pour que des attaquants s’emparent de près de 1,5 million de dollars en quelques transactions. L’affaire UNCX Vesting V2, survenue récemment, n’est pas seulement une nouvelle histoire de hack. Elle met en lumière une fragilité technique que beaucoup croyaient déjà maîtrisée dans les protocoles de vesting.
Quand le comptage des parts devient une porte ouverte
Le cœur du problème se trouve dans un contrat intelligent conçu pour gérer des positions de vesting. Ces outils sont très utilisés : ils permettent de libérer des tokens au fil du temps, évitant ainsi qu’une équipe ou un investisseur ne vende tout d’un coup et ne fasse s’effondrer le cours. Sur le papier, le mécanisme est solide. Dans la pratique, une incohérence entre deux fonctions a tout changé.
Selon l’analyse de Gonçalo Magalhães, responsable de la sécurité chez Immunefi, la faille se situait dans la façon dont le contrat mettait à jour son compteur de parts. Lorsqu’un bénéficiaire retirait les tokens déjà disponibles, la fonction de libération n’ajustait pas correctement le solde de parts de la position. Le compteur restait inchangé. Plus tard, lorsque la fonction d’annulation intervenait, elle se basait sur cette valeur obsolète et soustrayait une seconde fois la portion non encore mature. Résultat : les parts restantes se retrouvaient artificiellement valorisées.
Un attaquant n’avait plus qu’à jouer sur cette distorsion. Il ouvrait plusieurs positions de vesting, en sacrifiait volontairement deux via les fonctions de retrait et d’annulation, et laissait la troisième en place. Celle-ci devenait alors éligible à un retrait bien plus important que ce qu’elle aurait dû permettre. Le contrat avait perdu la cohérence de son invariant global sur le nombre de parts. C’est exactement ce que Magalhães a résumé en une phrase claire : le smart contract n’avait pas veillé à ce qu’aucune fonction ne puisse briser cet invariant.
Un scénario d’attaque simple en apparence
La méthode utilisée n’avait rien de particulièrement sophistiqué sur le plan mathématique. Elle reposait sur une suite logique de transactions parfaitement autorisées par le code. L’attaquant créait trois positions. Il en annulaient deux après avoir retiré ce qui était déjà disponible. Le solde de parts restant sur la troisième position se trouvait alors gonflé. Un dernier retrait permettait d’extraire une quantité de tokens disproportionnée.
Ce type de manipulation rappelle d’autres exploits passés où la logique métier du contrat n’était pas alignée entre toutes ses fonctions. Ici, le problème n’était pas une vulnérabilité cryptographique ou une erreur de signature. C’était purement une question de comptabilité interne. Les parts n’étaient plus le miroir exact des tokens encore retenus dans le pool.
Point clé : Une seule fonction qui oublie de mettre à jour un compteur peut suffire à rompre l’équilibre de tout un système de vesting partagé.
Des pertes estimées à 1,5 million de dollars
Les estimations avancées par des sociétés de surveillance on-chain situent le montant total drainé autour de 1,49 million de dollars. Les fonds ont été extraits sur quatre réseaux différents : Ethereum, BNB Chain, Base et Robinhood Chain. Onze transactions principales ont été identifiées. Parmi elles, on trouve celles de l’attaquant initial, mais aussi des portefeuilles copieurs et des bots de valeur extractible maximale, plus connus sous le nom de MEV bots.
Cette multiplicité d’acteurs complique immédiatement le tableau. Une fois qu’une faille devient publique ou détectable par des outils automatisés, la course commence. Les bots surveillent en permanence la mempool et sont capables de répliquer une transaction rentable en quelques secondes. Dans certains cas, ils peuvent même passer devant l’attaquant d’origine grâce à des techniques de front-running.
Le fait que plusieurs chaînes aient été touchées montre aussi que le contrat défectueux avait été déployé de façon identique ou très similaire sur plusieurs environnements. Une erreur de conception unique s’est ainsi propagée à grande échelle.
Comment distinguer l’attaquant initial des opportunistes
Pour les enquêteurs, la première piste reste l’historique des transactions. Celui qui a découvert et exploité la faille en premier apparaît généralement parmi les tout premiers mouvements. Les utilisateurs légitimes du protocole ont souvent un historique d’interactions antérieures. Les bots, eux, laissent des traces caractéristiques : fréquences élevées, patterns répétitifs, interactions avec des relais de transactions privées.
Magalhães insiste toutefois sur le caractère parfois flou de la frontière. Un ancien utilisateur du protocole peut tout à fait avoir copié l’exploit après l’avoir observé. Avoir déjà interagi avec le contrat ne prouve pas l’innocence. À l’inverse, un bot peut avoir agi de manière purement opportuniste sans connaître le projet.
Lorsque des fonds aboutissent chez des opérateurs de bots, la seule voie réaliste consiste à les contacter et à demander un retour volontaire. Certaines équipes de sécurité ont déjà obtenu des remboursements partiels de cette façon, mais le succès n’est jamais garanti.
La question délicate de la divulgation pendant une attaque active
Que doit faire une société de sécurité lorsqu’elle découvre qu’un exploit est encore en cours ? Magalhães propose une approche progressive. La première étape consiste à contacter en privé l’équipe du protocole. Si celle-ci dispose d’un mécanisme de pause, elle peut stopper immédiatement les nouvelles interactions et limiter les dégâts.
Lorsque cette voie est impossible, par exemple si les opérateurs sont anonymes ou injoignables, la recommandation est de tenter de joindre les plus gros déposants identifiables publiquement. Seulement en dernier recours, une alerte publique invitant les utilisateurs à retirer leurs fonds devient acceptable.
« Une fois toutes les options épuisées, il ne reste plus grand-chose d’autre à faire que d’appeler publiquement les utilisateurs à retirer immédiatement leurs fonds. »
Cette séquence n’est pas une règle absolue. Elle dépend du contexte, de la capacité d’intervention et des risques juridiques. Dans un autre incident survenu sur une vault anonyme de Base, un chercheur s’était retrouvé dans une situation délicate : impossible de savoir à qui s’adresser en privé, et donc difficulté à agir sans exposer le public trop tôt.
Responsabilité partagée entre fournisseur et projets utilisateurs
UNCX proposait une infrastructure de vesting partagée. De nombreux projets y avaient déposé des tokens destinés à leurs équipes, investisseurs ou communautés. Lorsque la faille a été exploitée, la question de la responsabilité s’est immédiatement posée.
Selon Magalhães, les deux parties ont un rôle à jouer. Le fournisseur du contrat défectueux porte évidemment la responsabilité technique. Mais les projets qui ont choisi d’utiliser cette infrastructure ont aussi le devoir de vérifier sérieusement ce qu’ils intègrent. Une simple réputation ne suffit pas. Une revue technique interne, même minimale, reste indispensable.
Après l’incident, la responsabilité de travailler à rendre les utilisateurs indemnes incombe donc aux deux côtés. Aucun pourcentage précis n’a été avancé. L’idée est plutôt que chacun doit contribuer selon ses moyens et son degré d’implication.
Rappel important : Un audit ne garantit jamais un code infaillible. Il réduit les risques, mais ne les élimine pas complètement.
La réaction d’UNCX et les mesures d’urgence
Face à l’attaque, l’équipe d’UNCX a réagi en augmentant les frais de certaines opérations afin de décourager de nouvelles exploitations. Elle a également engagé des discussions avec les projets touchés, les autorités et le collectif SEAL 911, spécialisé dans la réponse aux incidents de sécurité crypto.
Bonne nouvelle relative : les lockers de liquidité et les anciens contrats de vesting de la plateforme n’ont pas été affectés. Seule la version V2 de la fonctionnalité de vesting a été compromise. L’équipe a annoncé son intention de publier une analyse technique détaillée ainsi qu’un plan de récupération proposé.
Ces annonces sont classiques dans ce genre de situation. Elles servent à rassurer les utilisateurs restants et à montrer que le projet ne se défile pas. La suite dépendra de la capacité réelle à retrouver une partie des fonds et à les redistribuer de façon équitable.
Pourquoi les contrats de vesting restent des cibles privilégiées
Les mécanismes de vesting concentrent souvent de grandes quantités de tokens pendant de longues périodes. Ils sont donc attractifs pour les attaquants. De plus, leur logique métier est plus complexe qu’un simple transfert. Il faut gérer des calendriers, des portions libérées, des annulations, parfois des transferts de propriété de positions.
Chaque fonction supplémentaire augmente la surface d’attaque. Si l’état global du contrat n’est pas maintenu de façon cohérente à chaque opération, une faille de comptabilité peut apparaître. C’est précisément ce qui s’est produit ici.
On a déjà vu des cas similaires dans d’autres protocoles où un retrait partiel laissait des variables internes dans un état incohérent. La leçon est toujours la même : les invariants doivent être explicitement vérifiés, idéalement via des assertions ou des tests formels.
Les bots MEV : alliés ou complices involontaires ?
Dans l’affaire UNCX, des bots ont participé au drainage. Leur rôle est purement économique. Ils cherchent des opportunités de profit dans la mempool et les exécutent. Ils ne « volent » pas au sens moral du terme ; ils exploitent une opportunité que le code laisse ouverte.
Pourtant, pour les victimes, le résultat est le même : les tokens disparaissent. Dans certains incidents passés, des bots ont même récupéré des fonds avant l’attaquant principal, ce qui a parfois permis des négociations de restitution. Dans d’autres cas, les fonds ont simplement disparu dans des destinations difficiles à tracer.
Cette dualité rend la gestion des incidents encore plus complexe. Faut-il considérer les bots comme des acteurs neutres du marché ou comme des participants à l’exploitation ? La réponse varie selon les équipes de sécurité et les circonstances.
Ce que les projets devraient vérifier avant d’adopter une infrastructure
Choisir un fournisseur de vesting partagé peut sembler pratique. Cela évite de développer et d’auditer son propre contrat. Mais cela transfère aussi une partie du risque. Magalhães recommande que chaque projet dispose de ses propres ressources de sécurité pour examiner le code du fournisseur.
La réputation est un élément utile, mais insuffisant. Des protocoles bien notés ont déjà connu des incidents. Une revue du code, même partielle, centrée sur les fonctions de retrait, d’annulation et de mise à jour des soldes, peut révéler des incohérences avant qu’elles ne soient exploitées.
Il est également prudent de limiter les montants déposés dans une infrastructure tierce, ou de prévoir des mécanismes de pause contrôlés par le projet utilisateur lui-même.
Les limites des audits de sécurité
Beaucoup d’utilisateurs croient encore qu’un audit équivaut à une garantie. Magalhães rappelle clairement que ce n’est pas le cas. Un service d’audit ne promet pas un code incapable de faillir. Il cherche les vulnérabilités connues et les erreurs de logique les plus fréquentes, mais il ne peut pas prouver l’absence totale de bugs.
Dans le cas d’UNCX, on ne sait pas encore précisément si la faille avait été manquée lors d’un audit précédent ou si le contrat n’avait pas été audité dans sa version finale. Quoi qu’il en soit, l’incident montre une fois de plus que la confiance dans un audit unique est dangereuse.
Les meilleures pratiques actuelles combinent plusieurs audits indépendants, des bug bounties publics, des tests de fuzzing et, lorsque c’est possible, des preuves formelles sur les invariants critiques.
Vers une meilleure culture de réponse aux incidents
L’affaire UNCX s’inscrit dans une série d’incidents où la rapidité de réaction a fait la différence. Contacter en privé, pause des contrats, coordination avec les déposants, collaboration avec des collectifs spécialisés : chaque étape compte.
Les équipes qui ont anticipé ces scénarios s’en sortent généralement mieux. Elles disposent déjà de canaux de communication d’urgence, de clés de pause multisignatures et de relations établies avec des chercheurs en sécurité.
Pour les utilisateurs, la leçon reste prudente : diversifier les expositions, ne pas laisser de gros montants dormants trop longtemps dans des contrats complexes, et suivre l’actualité des protocoles utilisés.
Une faille de conception, pas seulement un bug isolé
Ce qui frappe dans cette affaire, c’est la nature profonde du problème. Ce n’était pas une erreur de calcul mathématique isolée, ni une mauvaise gestion des droits d’accès. C’était l’absence d’une règle claire et systématiquement appliquée : chaque opération doit préserver l’exactitude du compteur global de parts.
Cette idée d’invariant est centrale en programmation de contrats intelligents. Elle signifie qu’à tout moment, certaines propriétés du système doivent rester vraies. Lorsque plusieurs fonctions modifient le même état sans se coordonner, l’invariant peut se briser silencieusement.
Les développeurs expérimentés intègrent désormais des checks explicites après chaque modification critique. Si le check échoue, la transaction est revertée. C’est une défense simple mais efficace contre ce type d’incohérence.
Les leçons concrètes pour l’écosystème DeFi
Premièrement, la complexité est l’ennemie de la sécurité. Plus un contrat multiplie les chemins d’exécution, plus le risque d’incohérence augmente. Deuxièmement, les tests doivent porter non seulement sur les cas nominaux, mais aussi sur les séquences inhabituelles de retraits et d’annulations. Troisièmement, la surveillance on-chain en temps réel devient indispensable pour les protocoles qui gèrent des volumes importants.
Enfin, la transparence après un incident reste essentielle. Publier une analyse technique, reconnaître les erreurs et proposer un plan de récupération crédible permet de limiter les dégâts de réputation. Les projets qui disparaissent après un hack perdent définitivement la confiance de la communauté.
À retenir : Un système de vesting n’est sûr que si chaque fonction qui touche aux parts met à jour correctement l’état global. Un oubli, même mineur, peut coûter des millions.
Que peut-on espérer pour la récupération des fonds ?
À ce stade, une partie des fonds a probablement déjà été déplacée vers des adresses de mélange ou des ponts inter-chaînes. La récupération complète est rare dans ce type d’incident. Cependant, des négociations avec les opérateurs de bots et des actions de gel auprès d’exchanges centralisés peuvent parfois permettre de récupérer une fraction significative.
UNCX a indiqué travailler avec les projets touchés et les forces de l’ordre. Le succès de ces démarches dépendra de la rapidité avec laquelle les fonds ont été tracés et de la coopération des plateformes d’échange.
Pour les victimes, la prudence reste de mise. Les annonces de plans de récupération doivent être suivies de preuves concrètes : adresses de remboursement, mécanismes de claim vérifiables, et calendrier réaliste.
Un rappel salutaire sur la nature des smart contracts
Les contrats intelligents sont souvent présentés comme immuables et donc plus sûrs que le code traditionnel. En réalité, leur immuabilité est aussi leur faiblesse : une fois déployés avec une faille, ils restent exploitables jusqu’à ce qu’ils soient vidés ou abandonnés.
La seule protection réelle reste la qualité du code initial, la rigueur des tests et la capacité de pause. L’incident UNCX Vesting V2 illustre parfaitement ce principe. Une erreur de comptabilité apparemment mineure a ouvert la porte à un drain multi-chaîne de près d’un million et demi de dollars.
Dans un écosystème où des milliards de dollars reposent sur des lignes de code, chaque invariant oublié devient une opportunité pour quelqu’un. La vigilance collective, des développeurs aux utilisateurs en passant par les auditeurs, reste la seule défense durable.
L’histoire d’UNCX n’est pas isolée. Elle s’ajoute à une longue liste d’incidents qui rappellent que la DeFi, malgré ses progrès, n’a pas encore éliminé les erreurs humaines dans la conception des systèmes. Tant que des contrats complexes continueront de gérer des sommes importantes sans mécanismes de sécurité redondants, ce type d’événement restera possible. La bonne nouvelle, c’est que chaque nouvel incident améliore un peu plus les pratiques de l’industrie. À condition que les leçons soient réellement tirées.
