Hook de Depeg Swap en Cork Protocol

El 28 de mayo de 2025 a las 11:39 UTC, el protocolo de seguro contra depeg respaldado por a16z Cork Protocol fue drenado de 3.761 wstETH — aproximadamente 12 millones de dólares en el momento — a través de un exploit sofisticado que abusó de la lógica de creación de mercados de Cork combinada con un hook malicioso de Uniswap v4. El drenaje se ejecutó en 16 minutos.

Qué ocurrió

Cork Protocol permitía a los usuarios cubrirse contra el riesgo de depeg de activos. El mecanismo:

• PA (Pegged Asset) — lo que los usuarios querían proteger (p. ej., wstETH).
• RA (Reserve Asset) — a lo que se suponía que el PA estaba anclado.
• DS (Depeg Swap) — un token que los usuarios compraban para asegurarse contra el depeg del PA.
• CS (Covered Swap) — un token que los usuarios vendían para apostar contra el depeg.

La función de creación de mercados de Cork permitía a cualquier usuario crear nuevos mercados sin permiso especificando el PA y RA. El fallo fatal: la función no validaba que el RA fuera un activo subyacente legítimo — específicamente, no comprobaba que un RA no fuera ya en sí el DS de otro mercado existente.

El ataque:

1. Creó un nuevo mercado con el PA elegido por el atacante y un RA que apuntaba al DS de un mercado legítimo existente.
2. Desplegó un hook malicioso de Uniswap v4 diseñado para saltarse las comprobaciones de autorización en los contratos CorkHook y FlashSwapRouter de Cork.
3. Explotó la lógica de precio de rollover de Cork poco antes del vencimiento del mercado legítimo — manipulando un input que influía en cómo el protocolo valoraba las posiciones de depeg/cover durante el rollover.
4. El hook malicioso se saltó las comprobaciones de autorización en la ruta de swap de Cork, permitiendo al atacante retirar el wstETH subyacente que respaldaba el mercado original.
5. Drenó 3.761 wstETH y los convirtió a ETH en 16 minutos.

Consecuencias

• Cork pausó todas las operaciones de mercado y publicó un post-mortem detallado.
• El equipo se coordinó con investigadores white-hat en el rastreo; siguió recuperación parcial vía cooperación cross-exchange pero no devolvió la mayor parte de los fondos.
• El exploit se convirtió en un estudio de caso notable en riesgos de hooks de Uniswap v4, dado que el hook malicioso fue central para saltarse la lógica de autorización de Cork.

Por qué importa

Cork Protocol es uno de los primeros incidentes importantes en la era post-Uniswap v4 donde el mecanismo de hooks — una primitiva deliberadamente potente que permite a contratos externos interceptar operaciones de pool — se convirtió en un componente portante de un exploit. Los hooks permiten a los protocolos componerse elegantemente, pero también permiten a los atacantes componerse maliciosamente de formas que los protocolos que implementan su propio control de acceso pueden no anticipar.

La lección estructural, bien documentada pero nuevamente relevante para v4:

1. La creación de mercados sin permiso requiere validación estricta de cada input — incluyendo comprobaciones transitivas contra el estado de otros mercados que el nuevo mercado pueda referenciar.
2. Las integraciones de hooks deben tratarse como llamadores no confiables por defecto, sin importar cómo esté configurado el protocolo que las integra.
3. Incluso protocolos bien auditados pueden enviar vulnerabilidades novedosas cuando se sitúan en la intersección de múltiples capas de composabilidad primitiva. La auditoría de Cork había revisado cada componente en aislamiento; el exploit los combinó.

El incidente de Cork también es notable por la velocidad del drenaje (16 minutos) y la precisión del ataque (ejecutándose justo antes del vencimiento del mercado legítimo). Estos señalan un atacante con familiaridad profunda con el protocolo — posiblemente de investigación previa o conocimiento interno del código.