C'est le genre de bug qui empêche les équipes de protocole de dormir la nuit. Un exploit de 5 millions de dollars sur ZKSwap, rendu possible par une seule déclaration laissée au mauvais endroit. Voici une analyse approfondie de la façon dont cela s'est produit, et comment la surveillance on-chain aurait pu l'arrêter. 🧵

1/ Le 9 juillet, GMX a été piraté pour 42 millions de dollars. Mais quelque chose d'autre s'est produit ce jour-là et à peine quelqu'un l'a remarqué : le pont de ZKSwap a été discrètement vidé de 5 millions de dollars. La partie intéressante ? Il n'y avait pas d'exploit sophistiqué impliqué. Juste une fonction critique qui ne faisait... rien.

2/ ZKSwap est un zk-rollup construit sur Ethereum. Comme de nombreux rollups, il utilise un pont pour déplacer des actifs entre L1 et L2. En tant que mesure de sécurité, le pont inclut un "Mode Exodus", un moyen pour les utilisateurs de récupérer des fonds sans avoir besoin de l'opérateur. En théorie, c'est une excellente idée. En pratique…

3/ Le mode Exodus permet aux utilisateurs de prouver manuellement qu'ils possédaient des tokens dans le dernier état L2 vérifié. C'est un mécanisme de secours : sans confiance, auto-géré, non interactif. Mais l'implémentation de ZKSwap avait un défaut fatal : la fonction responsable de la vérification des preuves ne vérifiait rien. Littéralement.

4/ Voici le code qui aurait dû arrêter l'attaque 👇 À première vue, cela ressemble à un véritable vérificateur de zk-proof. Mais regardez de plus près la première ligne : return true; C'est tout. Rien d'autre ne s'exécute.

5/ Le résultat ? Chaque "preuve" de retrait (peu importe à quel point elle est fausse) a passé la validation. Le contrat a accepté des revendications arbitraires concernant les soldes de tokens... et les a crédités comme s'ils étaient réels. Il a transformé un mécanisme de secours sans confiance en un robinet non protégé.

6/ L'attaquant n'avait pas besoin d'exploits sophistiqués - juste des appels répétés à exit() avec des données inventées. Ils ont contourné les vérifications de solde, retiré à travers plusieurs tokens et abusé d'une logique de nullificateur faible pour éviter la détection. Tout cela pendant que le contrat disait : ✅

7/ Ce n'était pas un cas marginal obscur. C'était la logique fondamentale pour la récupération d'actifs, laissée complètement ouverte. Et parce que le Mode Exodus est rarement déclenché, le chemin défectueux est passé inaperçu... pendant des mois.

8/ Voici ce qui aurait dû déclencher des alarmes : • Le mode Exodus étant déclenché après une longue période d'inactivité • Des dizaines de demandes de retrait se produisant toutes en même temps • Une augmentation soudaine des changements de soldesÀRetirer Tout cela était visible et aurait pu être arrêté avec une surveillance on-chain en temps réel.

9/ Quelle est la leçon ? • Le code d'urgence est toujours du code de production • Les chemins de secours ne servent à rien s'ils ne fonctionnent pas • La surveillance en temps réel n'est pas optionnelle, elle est cruciale pour la survie