Faille UNCX Vesting V2 : 1,5 M$ Perdus En Comptage

Imaginez un coffre-fort numérique censé protéger des tokens vestés pendant des mois, voire des années. Un jour, une simple erreur de comptage dans le code ouvre la porte. En quelques heures, près de 1,5 million de dollars s’évaporent sur quatre blockchains différentes. C’est exactement ce qui s’est produit avec le contrat Vesting V2 d’UNCX. Une faille de partage de parts a transformé un mécanisme de sécurité en opportunité pour des attaquants, des bots et même des imitateurs. Aujourd’hui, on décortique ensemble cette affaire, sans jargon inutile, pour comprendre comment une ligne de code manquante peut coûter cher à tout un écosystème.

Une faille de comptabilité qui a tout changé

Le problème ne venait pas d’un pirate ultra-sophistiqué capable de contourner des protections complexes. Il s’agissait d’une incohérence pure et simple dans la façon dont le smart contract gérait les parts (shares) des positions de vesting. Gonçalo Magalhães, responsable de la sécurité chez Immunefi, a livré une explication claire et précise qui permet de saisir l’origine de la brèche.

Le contrat proposait deux fonctions principales : le retrait des tokens déjà acquis selon le calendrier de vesting, et l’annulation d’une position. Ces deux opérations auraient dû maintenir un compteur global de parts parfaitement équilibré. Or, ce n’était pas le cas.

Le mécanisme de retrait qui laissait des traces

Lorsqu’un bénéficiaire retirait ses tokens devenus disponibles, la fonction de release ne mettait pas à jour le compteur de parts de la position. Les parts correspondant aux tokens déjà sortis restaient inscrites comme si de rien n’était. Le système pensait encore que ces parts existaient dans le pool.

Cette omission créait déjà un déséquilibre. Mais le vrai problème apparaissait au moment de l’annulation. La fonction de cancellation lisait la valeur non mise à jour et recalculait la part non vestée en se basant sur un chiffre obsolète. Résultat : le pool se voyait attribuer une valeur faussée pour les parts restantes.

Au final, le smart contract n’a pas su garantir qu’aucune fonction ne puisse casser l’invariant autour du compteur global des parts.

Gonçalo Magalhães, Immunefi

Cette phrase résume parfaitement le cœur du problème. Un invariant, en langage de développeur, c’est une règle qui doit rester vraie à tout moment. Ici, le compteur de parts aurait dû toujours correspondre à la réalité des tokens encore présents. Il a été cassé.

Comment les attaquants ont exploité la faille

Selon le récit de Magalhães, un attaquant pouvait ouvrir plusieurs positions de vesting. Il en sacrifiait volontairement deux en combinant retrait et annulation. La troisième position, restée intacte, devenait alors éligible à un retrait massivement gonflé. Les parts restantes se voyaient attribuer une valeur bien supérieure à celle qu’elles méritaient réellement.

Ce n’était plus un simple bug. C’était une machine à multiplier les tokens pour celui qui savait jouer avec les fonctions dans le bon ordre. Et comme le contrat était déployé sur plusieurs chaînes, l’opportunité s’est multipliée.

Les chiffres parlent d’eux-mêmes. Une faille unique, déployée sur plusieurs chaînes, a suffi à générer un impact significatif en très peu de temps. Les bots de maximal extractable value (MEV) ont rapidement flairé l’opportunité et se sont engouffrés dans la brèche, amplifiant les pertes.

La réponse progressive des équipes de sécurité

Face à une faille encore active, la question qui se pose immédiatement est celle de la communication. Faut-il alerter tout le monde publiquement au risque d’attirer encore plus d’attaquants ? Ou privilégier la discrétion ?

Magalhães recommande une approche par étapes. La première consiste à contacter en privé l’équipe du protocole. Si les opérateurs disposent d’un moyen de mettre le contrat en pause, c’est la solution la plus efficace pour stopper immédiatement l’hémorragie.

Si cette voie n’est pas possible, la deuxième étape consiste à joindre les plus gros déposants identifiables publiquement. Leur permettre de retirer leurs fonds avant que la nouvelle ne se répande limite les dégâts collatéraux.

Ce n’est qu’en dernier recours qu’une alerte publique devient nécessaire. À ce stade, il ne reste plus qu’à appeler les utilisateurs à retirer leurs fonds le plus vite possible.

Une fois toutes les options épuisées, il ne reste plus grand-chose à faire d’autre que d’appeler publiquement les utilisateurs à retirer immédiatement leurs fonds.

Gonçalo Magalhães

Cette séquence de décisions montre à quel point la gestion de crise en DeFi reste délicate. Une communication trop précoce peut accélérer l’exploitation. Une communication trop tardive laisse les utilisateurs exposés plus longtemps.

Quand l’anonymat bloque toute intervention privée

Tous les protocoles ne sont pas égaux face à ce type de situation. Magalhães a évoqué un cas survenu le 6 octobre sur un vault non identifié de Base. Environ 6 millions de dollars avaient été volés. Le chercheur qui avait découvert la faille s’est retrouvé face à un mur : les opérateurs du vault étaient inconnus, et aucun canal de divulgation clair n’existait.

Dans ce genre de configuration, même la meilleure intention de sécurité se heurte à l’absence de point de contact. L’anonymat, souvent présenté comme un avantage dans l’écosystème crypto, devient alors un frein majeur à la protection des utilisateurs.

Comment les enquêteurs démêlent le vrai du faux

Une fois l’attaque passée, reste la question de l’identification des acteurs. Qui est l’attaquant original ? Qui sont les copycats ? Qui sont les bots qui ont simplement suivi le mouvement ?

Les historiques de transactions offrent un point de départ solide. L’attaquant initial apparaît généralement parmi les premiers mouvements. Les utilisateurs établis du protocole ont un historique d’interactions antérieures. Les wallets automatisés montrent souvent des patterns caractéristiques des bots.

Pourtant, la frontière reste floue. Un ancien client du protocole peut parfaitement avoir copié l’exploit. Avoir déjà interagi avec le contrat ne prouve rien. Magalhães le reconnaît sans détour : la ligne est difficile à tracer.

Quand des bots reçoivent des fonds, la seule option consiste à contacter leurs opérateurs pour tenter de récupérer les actifs. Ce n’est pas toujours simple, et le taux de succès varie considérablement selon les cas.

Un précédent survenu le 15 septembre illustre parfaitement cette complexité. Un bot nommé Yoink avait exécuté une transaction avant même l’attaquant suspecté, dans le même bloc. L’exploit original avait échoué, mais le bot avait récupéré l’équivalent de 7,8 millions de dollars en rsETH. La course aux millisecondes peut parfois inverser complètement les rôles.

La question de la responsabilité partagée

Qui doit rembourser les victimes ? Le fournisseur d’infrastructure qui a laissé passer le bug, ou les projets qui ont choisi d’utiliser ce service ? Magalhães est clair sur ce point : la responsabilité de travailler à rendre les utilisateurs indemnes incombe aux deux parties.

La responsabilité de travailler à rendre les utilisateurs entiers incombe à la fois au fournisseur qui a le bug et aux projets qui ont fait confiance à ce fournisseur.

Gonçalo Magalhães

Cette position nuance le débat. Un projet qui intègre une solution externe ne peut pas se contenter de pointer du doigt le prestataire. Il a aussi le devoir d’avoir examiné soigneusement le code et la réputation de l’outil qu’il adopte. Une due diligence technique reste indispensable, même face à un acteur connu.

De leur côté, les équipes d’UNCX ont réagi en augmentant temporairement les frais pour décourager de nouvelles exploitations. Elles ont également engagé une coordination avec les projets touchés, les forces de l’ordre et le groupe SEAL 911. Un rapport technique et un plan de récupération sont annoncés.

Ce que les audits ne garantissent pas

Beaucoup d’utilisateurs croient encore qu’un smart contract audité est à l’abri de tout problème. Magalhães rappelle une réalité parfois oubliée : un audit ne promet jamais un code infaillible. Il s’agit d’une revue approfondie, pas d’une assurance tous risques.

Les auditeurs peuvent manquer une vulnérabilité. Les conditions d’exploitation peuvent n’apparaître que dans des scénarios très spécifiques. Et surtout, le code évolue. Une mise à jour post-audit peut réintroduire des risques.

Dans le cas d’UNCX, la faille concernait précisément la cohérence entre plusieurs fonctions. Ce type de bug d’invariant est particulièrement difficile à détecter, car il nécessite de vérifier non seulement chaque fonction isolément, mais aussi leurs interactions dans tous les ordres possibles.

Les leçons pour les projets qui utilisent des infrastructures partagées

De nombreux projets confient leurs tokens à des solutions de vesting ou de locking gérées par des prestataires spécialisés. Cette mutualisation apporte de la simplicité et parfois des économies. Elle crée aussi une concentration de risques.

Magalhães insiste sur la nécessité pour chaque équipe d’avoir ses propres experts sécurité qui examinent le code du fournisseur. La réputation d’un prestataire compte, mais elle ne remplace jamais une revue technique indépendante.

Les projets doivent aussi anticiper les scénarios de crise. Qui contacter en cas de problème ? Existe-t-il un canal de pause d’urgence ? Comment communiquer avec les utilisateurs déposants ? Ces questions devraient être tranchées avant qu’un incident ne survienne.

Le rôle des chercheurs en sécurité et les bonnes pratiques de divulgation

La question de la divulgation responsable reste centrale. Mitchell Amador, PDG d’Immunefi, a rappelé dans un autre contexte qu’un chercheur ne doit pas s’emparer des fonds des utilisateurs pour ensuite négocier une prime. Les canaux de divulgation privée et les conditions de bounty préalablement acceptées restent la voie recommandée.

Cette distinction est importante. Certains chercheurs ont parfois été tentés de « prouver » la vulnérabilité en drainant les fonds, puis de demander une récompense. Cette pratique, même motivée par de bonnes intentions, pose des problèmes juridiques et éthiques majeurs.

Dans le cas d’UNCX, l’intervention d’Immunefi a permis d’apporter une analyse claire et publique après les faits. Le travail de reconstruction technique aide l’ensemble de l’écosystème à comprendre ce qui s’est passé et à éviter de reproduire les mêmes erreurs.

Pourquoi les failles de comptabilité restent dangereuses

Les bugs de logique métier, et particulièrement ceux qui touchent à la comptabilité interne, sont parmi les plus coûteux en DeFi. Contrairement aux erreurs de réentrance ou aux problèmes d’accès, ils ne nécessitent parfois aucune compétence technique avancée pour être exploités une fois découverts.

Il suffit de comprendre la séquence d’appels qui produit l’incohérence. Dans le cas d’UNCX, la combinaison retrait puis annulation suffisait. Une fois le pattern identifié, des bots et des imitateurs ont pu le reproduire rapidement sur plusieurs chaînes.

Ce type de vulnérabilité rappelle que la sécurité d’un smart contract ne se limite pas à la protection contre les attaques classiques. Elle exige une vérification rigoureuse de toutes les invariants métier, c’est-à-dire des règles qui doivent rester vraies quelle que soit la séquence d’opérations.

L’impact sur la confiance dans les solutions de vesting

Les contrats de vesting jouent un rôle central dans l’écosystème crypto. Ils permettent de distribuer des tokens de façon progressive aux équipes, aux investisseurs ou aux contributeurs. Quand une faille touche ce type d’infrastructure, c’est toute la confiance dans le mécanisme qui est ébranlée.

Les projets qui utilisaient UNCX Vesting V2 se retrouvent aujourd’hui confrontés à des questions difficiles. Comment rassurer leurs communautés ? Comment compenser les pertes éventuelles ? Comment choisir le prochain prestataire avec plus de discernement ?

UNCX a indiqué que ses liquidité lockers et ses contrats de vesting plus anciens n’avaient pas été touchés. Cette précision est importante, car elle limite la contagion de la méfiance. Pourtant, l’image d’un prestataire se construit sur l’ensemble de ses produits, et un incident sur une version peut affecter la perception globale.

Ce que révèle cette affaire sur l’état de la DeFi en 2026

Malgré des années de maturité progressive, les smart contracts restent des objets complexes où une erreur de conception peut avoir des conséquences disproportionnées. Les audits se multiplient, les programmes de bug bounty se développent, les outils d’analyse formelle progressent. Et pourtant, des failles de logique métier continuent d’apparaître.

L’affaire UNCX illustre aussi la vitesse de propagation des exploits multi-chaînes. Une fois le pattern identifié sur une blockchain, les bots et les attaquants le déploient rapidement sur les autres réseaux où le même contrat existe. La fragmentation des chaînes, souvent présentée comme un avantage, devient un amplificateur de risque.

Enfin, cette histoire rappelle que la sécurité est un continuum. Elle commence par la conception du code, se poursuit par les audits, les tests, le monitoring en production, et se prolonge dans la capacité à réagir efficacement en cas d’incident.

Vers une meilleure coordination face aux incidents

Des initiatives comme SEAL 911 existent précisément pour améliorer la coordination entre chercheurs, projets et forces de l’ordre en cas d’exploit. Leur implication dans le dossier UNCX montre que l’écosystème commence à se doter d’outils collectifs de réponse.

Pourtant, beaucoup reste à faire. Les canaux de communication d’urgence ne sont pas toujours clairs. Les procédures de pause ne sont pas systématiquement prévues. Les plans de compensation restent souvent improvisés après coup.

Les projets qui prennent la sécurité au sérieux intègrent désormais ces dimensions dans leur conception. Ils ne se contentent plus de faire auditer le code. Ils anticipent les scénarios de crise et préparent les réponses possibles.

Les utilisateurs face à ce type de risque

Pour l’utilisateur final, ces événements soulèvent une question simple : comment protéger ses tokens vestés ? La réponse n’est jamais totale. Même les protocoles les plus sérieux peuvent connaître des incidents. Pourtant, quelques réflexes permettent de réduire l’exposition.

Diversifier les prestataires de vesting, ne pas concentrer toutes ses positions sur un seul contrat, suivre les annonces de sécurité des projets utilisés, et être prêt à retirer rapidement en cas d’alerte font partie des bonnes pratiques.

Il faut aussi accepter qu’une part de risque reste inhérente à l’utilisation de smart contracts. La DeFi offre de la transparence et de la programmabilité, mais elle exige en contrepartie une vigilance permanente.

Un incident qui servira d’exemple

L’exploit UNCX Vesting V2 restera probablement dans les annales comme un cas d’école de faille de comptabilité. Il montre comment une omission apparemment mineure dans la mise à jour d’un compteur peut ouvrir la porte à des retraits massifs.

Il illustre aussi la chaîne de responsabilités qui se met en place après un incident : prestataire, projets utilisateurs, chercheurs, forces de l’ordre, et utilisateurs finaux. Chacun a un rôle à jouer dans la limitation des dégâts et dans la prévention des prochaines occurrences.

Les prochaines semaines diront si UNCX parvient à publier un rapport technique transparent et un plan de récupération crédible. La façon dont les projets touchés et le prestataire collaboreront pour indemniser les victimes sera également scrutée de près.

En attendant, cette affaire rappelle une vérité simple mais essentielle : dans la blockchain, la confiance se construit sur le code, mais elle se maintient grâce à la rigueur, à la transparence et à la capacité de réagir quand ce code révèle ses faiblesses.

Les développeurs, les auditeurs et les équipes de sécurité continueront de tirer des enseignements de ce type d’incident. Chaque faille analysée publiquement contribue, paradoxalement, à renforcer l’écosystème. À condition, bien sûr, que les leçons soient réellement intégrées dans les pratiques futures.

Pour l’instant, le bilan s’élève à environ 1,5 million de dollars. Un chiffre significatif, même s’il reste loin des plus grands exploits de l’histoire de la DeFi. Ce qui compte davantage, c’est la nature de la faille et la façon dont elle a été exploitée sur plusieurs chaînes simultanément. Un signal d’alerte clair pour tous ceux qui construisent ou utilisent des infrastructures de vesting partagées.

La vigilance reste de mise. Dans un environnement où le code est loi, chaque invariant non respecté peut devenir une porte ouverte. Et comme le montre cette histoire, il suffit parfois d’une seule fonction qui oublie de mettre à jour un compteur pour que l’ensemble du système bascule.