Comment 3 000 $ ont failli compromettre 70 milliards d'actifs Aptos

iEXExchanger
Comment 3 000 $ ont failli compromettre 70 milliards d'actifs Aptos

Hexens a découvert une faille critique dans la Move VM d'Aptos : serveur à 3 000 $, 90 % de réussite, accès à Wormhole, LayerZero et droits USDC. Risque systémique : 70 milliards. Patché en février.

Les chiffres parlent d'eux-mêmes : un serveur à 3 000 dollars, un taux de réussite proche de 90 % et un accès potentiel à 70 milliards de dollars d'infrastructure crypto. C'est ce que la société Hexens a documenté en février 2026 et rendu public le 4 juillet en décrivant une faille critique découverte dans la blockchain Aptos.

Le bug se trouvait dans la Move VM, la couche d'exécution des contrats intelligents d'Aptos. Hexens l'a qualifié de stale-cache bug : une gestion défectueuse du cache amenait la VM à confondre des types de données, permettant au code d'un attaquant d'accéder au stockage de contrats tiers comme s'il lui appartenait. En termes de gravité, les chercheurs ont comparé cette faille à un bug Ethereum permettant à du code arbitraire d'écrire dans le storage de n'importe quel contrat.

Les systèmes exposés incluaient le Cross-Chain Transfer Protocol (CCTP) de Circle pour l'USDC, les clés d'administration des ponts LayerZero et Wormhole, les coffres de liquid staking et les voies de crédit de dépôts sur les grandes plateformes centralisées. Le TVL natif d'Aptos s'établissait à environ 250 millions de dollars ; en comptant l'infrastructure de bridges, Hexens a évalué le risque systémique à 70 milliards.

La vulnérabilité a été signalée le 25 février par canaux d'urgence ; le correctif a été intégré le 27 février. Aucun fonds n'a été perdu. La divulgation complète quatre mois après le correctif suit le protocole standard de divulgation responsable.

Pour Aptos, l'épisode est gênant malgré le dénouement favorable. La proposition de sécurité du réseau repose sur Move, un langage conçu pour rendre structurellement impossibles des catégories entières de vulnérabilités. Une faille au niveau du cache de la VM touche les fondations. Sui, Movement et d'autres réseaux Move utilisent une architecture similaire — la question de savoir si une logique de cache comparable y existe est désormais ouverte pour les chercheurs du secteur.

Questions et réponses

Questions fréquemment posées sur le sujet de l'article

Qu'est-ce qu'un stale-cache bug dans la Move VM ?

La Move VM met en cache les informations de type de ressource pour accélérer les transactions. En raison du bug, ce cache n'était pas invalidé correctement lors des changements d'état. Le code d'un attaquant pouvait en profiter pour se faire passer pour un type de ressource différent et s'arroger des permissions non accordées, dont les droits de mint de stablecoins.

Des fonds ont-ils été perdus à cause de cette faille ?

Non. Hexens a signalé la vulnérabilité le 25 février par des canaux d'urgence, et le correctif a été déployé le 27 février. Jusqu'à la divulgation du 4 juillet, seules les équipes d'Aptos et de Hexens connaissaient le bug. Aucune attaque réelle n'a été enregistrée.

Pourquoi le risque systémique est-il de 70 milliards si le TVL d'Aptos n'était que de 250 millions ?

La vulnérabilité touchait non seulement les actifs dans Aptos, mais aussi les clés administratives des ponts LayerZero et Wormhole, qui acheminent des actifs entre de nombreuses blockchains. Elle atteignait également le CCTP d'USDC, qui peut minter le stablecoin sur n'importe quel réseau connecté. Le flux combiné via ces canaux représente des dizaines de milliards, d'où l'estimation à 70 milliards.

Cela signifie-t-il que Sui et Movement sont aussi vulnérables ?

Pas nécessairement — chaque réseau Move utilise sa propre implémentation de VM. La logique de cache peut différer entre Sui, Movement et Aptos. Mais le fait que le bug ait été trouvé au niveau du cache de la VM soulève des questions pour tout l'écosystème. Des chercheurs examinent déjà des schémas similaires dans d'autres implémentations.