Hook Depeg Swap de Cork Protocol

Le 28 mai 2025 à 11:39 UTC, le protocole d'assurance contre les depegs soutenu par a16z Cork Protocol a été drainé de 3 761 wstETH — environ 12 millions de dollars à l'époque — via un exploit sophistiqué qui a abusé de la logique de création de marché de Cork combinée à un hook Uniswap v4 malveillant. Le drainage s'est exécuté en 16 minutes.

Ce qui s'est passé

Cork Protocol permettait aux utilisateurs de se couvrir contre le risque de depeg d'actifs. Le mécanisme :

• PA (Pegged Asset) — ce que les utilisateurs voulaient protéger (par ex. wstETH).
• RA (Reserve Asset) — ce à quoi le PA était censé être peggé.
• DS (Depeg Swap) — un token que les utilisateurs achetaient pour s'assurer contre le depeg du PA.
• CS (Covered Swap) — un token que les utilisateurs vendaient pour parier contre le depeg.

La fonction de création de marché de Cork permettait à tout utilisateur de créer sans permission de nouveaux marchés en spécifiant le PA et le RA. La faille fatale : la fonction ne validait pas que le RA était un actif sous-jacent légitime — spécifiquement, elle ne vérifiait pas qu'un RA n'était pas déjà lui-même le DS d'un autre marché existant.

L'attaque :

1. Création d'un nouveau marché avec le PA choisi de l'attaquant et un RA pointant vers le DS d'un marché légitime existant.
2. Déploiement d'un hook Uniswap v4 malveillant conçu pour contourner les vérifications d'autorisation dans les contrats CorkHook et FlashSwapRouter de Cork.
3. Exploitation de la logique de tarification de rollover de Cork peu avant l'expiration du marché légitime — manipulant une entrée qui influençait comment le protocole valorisait les positions depeg/cover pendant le rollover.
4. Le hook malveillant a contourné les vérifications d'autorisation dans le chemin de swap de Cork, permettant à l'attaquant de retirer le wstETH sous-jacent qui adossait le marché original.
5. Drainage de 3 761 wstETH et conversion en ETH en 16 minutes.

Conséquences

• Cork a mis en pause toutes les opérations de marché et publié un post-mortem détaillé.
• L'équipe a coordonné avec les enquêteurs white-hat sur le traçage ; une récupération partielle via coopération inter-échanges a suivi mais n'a pas retourné l'essentiel des fonds.
• L'exploit est devenu une étude de cas notable sur les risques des hooks Uniswap v4, étant donné que le hook malveillant était central pour contourner la logique d'autorisation de Cork.

Pourquoi c'est important

Cork Protocol est l'un des premiers incidents majeurs dans l'ère post-Uniswap v4 où le mécanisme des hooks — une primitive délibérément puissante qui laisse des contrats externes intercepter les opérations de pool — est devenu un composant porteur de charge d'un exploit. Les hooks permettent aux protocoles de se composer élégamment, mais ils permettent aussi aux attaquants de se composer malicieusement d'une manière que les protocoles implémentant leur propre contrôle d'accès peuvent ne pas anticiper.

Leçon structurelle, bien documentée mais nouvellement pertinente pour v4 :

1. La création de marché sans permission exige une validation stricte de chaque entrée — y compris des vérifications transitives contre l'état d'autres marchés que le nouveau marché pourrait référencer.
2. Les intégrations de hook doivent être traitées comme des appelants non fiables par défaut, indépendamment de comment le protocole intégrateur est configuré.
3. Même les protocoles bien audités peuvent livrer de nouvelles vulnérabilités quand ils se trouvent à l'intersection de plusieurs couches de composabilité de primitives. L'audit de Cork avait examiné chaque composant isolément ; l'exploit les a combinés.

L'incident Cork est aussi notable pour la vitesse du drainage (16 minutes) et la précision de l'attaque (s'exécutant juste avant l'expiration du marché légitime). Cela signale un attaquant avec une familiarité profonde avec le protocole — possiblement par recherche antérieure ou connaissance interne du codebase.