#6 Incidente del Protocolo Cork: Dos Fallas Independientes Se Combinan en una Devastadora Cadena de Exploits

El 28 de mayo de 2025, el protocolo Cork en Ethereum fue explotado [1], resultando en aproximadamente 12 millones de dólares en pérdidas. La causa raíz fue una combinación de manipulación del precio HIYA (Historical Implied Yield Average) en el momento de expiración y la ausencia de control de acceso en un callback de hook de Uniswap v4. Dado que las primas de riesgo de HIYA crecen exponencialmente a medida que el tiempo hasta el vencimiento se aproxima a cero, los swaps en etapas tardías inflaron el HIYA y provocaron que los mercados recién inicializados subvaloraran gravemente los Cover Tokens. Al mismo tiempo, CorkHook.beforeSwap carecía de autenticación de msg.sender, permitiendo llamadas arbitrarias con parámetros manipulados. Al explotar ambas fallas, el atacante extrajo ~3.760e18 CT y DS y los canjeó por wstETH, drenando las reservas del protocolo.

0x1 Antecedentes

0x1.1 Tokenomía

Cork Protocol [2] introduce un nuevo primitivo para el riesgo tokenizado, funcionando como una capa de riesgo programable para activos onchain como tokens de bóveda, stablecoins con rendimiento y tokens de liquid (re)staking. El componente fundamental es el Cork Pool, que es el mecanismo alrededor del cual se construyen los mercados. Cada Cork Pool se construye en torno a un par de activos: Redemption Asset (RA) y Pegged Asset (PA).

El Cork Pool recibe depósitos de Redemption Asset, que quedan bloqueados. A cambio, se acuñan dos tokens que se devuelven al depositante: Depeg Swap (DS) y Cover Token (CT). Antes de la fecha de expiración establecida, 1 DS + 1 CT/PA se pueden intercambiar por 1 RA; tras la expiración, 1 CT puede canjearse proporcionalmente por el RA + PA restante en el pool.

$$PA+DS=RAPA\; +\; DS\; =\; RA$$

$$CT+DS=RACT\; +\; DS\; =\; RA$$

0x1.2 Implementación del Contrato

Tanto DS como CT son intercambiables. Los usuarios pueden operar CT y RA usando NormalSwap basado en una curva AMM personalizada a través de CorkHook, mientras que DS y RA se intercambian usando FlashSwap mediante Router y CorkHook.

NormalSwap [Curva AMM personalizada]:

$$x^{1-t}{y}^t=kx^\{1-t\}\; y^\{t\}\; =\; k$$

FlashSwap [FlashSwapRouter.swapDsforRa]: Este mecanismo es central para el exploit. El atacante luego activa este camino mediante una llamada directa y no autenticada a beforeSwap (Sección 0x2.2).

1. El comprador transfiere RA al Router.

2. En la primera llamada a beforeSwap, el Router calcula la cantidad de DS a intercambiar. Si es necesario, toma prestados RA y CT del pool de Uniswap v4, convierte el CT prestado y el DS del protocolo en RA, conserva el RA requerido y devuelve el RA prestado al pool de Uniswap.

3. En la segunda llamada a beforeSwap, el Router descompone RA en CT y DS mediante depositPsm, transfiere todos los DS al usuario, devuelve el CT prestado al pool de Uniswap y reembolsa cualquier CT excedente al comprador.

Distribución de Fondos Tras la Emisión:

$$RA+CT:AMMRA+CT:\; AMM$$

$$DS:RouterDS:\; Router$$

0x1.3 Mecanismo de Precios para Nueva Emisión

El protocolo emplea HIYA (Historical Implied Yield Average), calculado como la suma acumulada de volumen ($v_{T}v\_T$) × prima de riesgo ($r_{T}r\_T$), que sirve para medir las primas de riesgo y ajustar los precios de inicialización al vencimiento. Si el HIYA es alto, el protocolo asume un mayor riesgo de depeg, lo que resulta en un precio inicial de CT más bajo.

$CumulativeHIYA={\sum }_T{r}_T{v}_{T}Cumulative\backslash \; HIYA\; =\; \backslash sum\_T\; r\_T\; v\_T$

El cálculo de la prima de riesgo ($r_{T}r\_T$) consta de dos componentes: los precios altos de CT se correlacionan con valores bajos de rt (lo cual es intuitivo), y el tiempo de expiración T tiene un efecto de amplificación exponencial. Cerca del vencimiento, T se aproxima a cero, haciendo que el exponente $1\mathrm{/}T1/T$ crezca rápidamente. Esto amplifica incluso pequeños cambios en el precio de CT en grandes valores de prima de riesgo.

$$r_T=(F\mathrm{/}{p}_T{)}^{1\mathrm{/}T}-1r\_T\; =\; (F\; /\; p\_T)^\{1/T\}\; -\; 1$$

• $FF$ es 1

• $P_{T}P\_T$ es el precio de CT

• $TT$ es el tiempo hasta el vencimiento normalizado entre 1-0

Para ilustrar la amplificación: si CT opera a $p_T=0.95p\_T\; =\; 0.95$ (un descuento del 5%), la prima de riesgo en $T=0.5T\; =\; 0.5$ (a mitad del camino hacia el vencimiento) es:

$$r_{0.5}=(1\mathrm{/}0.95{)}^{1\mathrm{/}0.5}-1=(1.053{)}^2-1\approx 0.108r\_\{0.5\}\; =\; (1/0.95)^\{1/0.5\}\; -\; 1\; =\; (1.053)^\{2\}\; -\; 1\; \backslash approx\; 0.108$$

En $T=0.01T\; =\; 0.01$ (cerca del vencimiento), el mismo precio de CT produce:

$$r_{0.01}=(1\mathrm{/}0.95{)}^{1\mathrm{/}0.01}-1=(1.053{)}^{100}-1\approx 167r\_\{0.01\}\; =\; (1/0.95)^\{1/0.01\}\; -\; 1\; =\; (1.053)^\{100\}\; -\; 1\; \backslash approx\; 167$$

El mismo descuento del 5% en CT genera una prima de riesgo ~1.500 veces mayor cerca del vencimiento. Esta sensibilidad exponencial es el vector de manipulación: un swap ejecutado poco antes del vencimiento infla el HIYA de forma desproporcionada, distorsionando el precio de inicialización del siguiente mercado.

0x2 Análisis de Vulnerabilidades

El mercado afectado involucra los siguientes tokens:

Para mayor claridad, el resto de este informe se refiere a los tokens por sus roles abstractos (RA, DS, CT) en lugar de sus nombres concretos, excepto cuando la distinción sea relevante.

El atacante extrajo tanto DS como CT del AMM y del Router utilizando dos métodos distintos. Dado que DS + CT pueden canjearse por RA, obtener ambos permite la extracción directa de beneficios. El ataque consta de dos componentes.

0x2.1 Extracción de Cover Token: Manipulación de HIYA que Conduce a Precios de Inicialización de Mercado Artificialmente Bajos

Cuando un plazo de mercado expira, el protocolo inicializa el siguiente plazo usando accumulatedHIYA del plazo anterior para establecer la relación de precios CT/RA en el AMM. Un HIYA más alto señala un mayor riesgo de depeg percibido, lo que se traduce en un precio inicial de CT más bajo.

Dado que el HIYA se actualiza en cada swap e incorpora primas de riesgo (Sección 0x1.3), y dado que las primas de riesgo crecen exponencialmente cuando $T\to 0T\; \backslash to\; 0$, los swaps ejecutados poco antes del vencimiento inflan accumulatedHIYA en órdenes de magnitud. El atacante explotó esto llamando a SwapRaForDs() cerca del vencimiento, generando una gran prima de riesgo que se acumuló en el HIYA.

Cuando el nuevo plazo de mercado fue inicializado posteriormente, el protocolo leyó el HIYA inflado, lo interpretó como un riesgo extremo de depeg y estableció el precio inicial de CT en el AMM muy por debajo de su valor justo. El atacante entonces intercambió RA por CT a este precio distorsionado, adquiriendo una gran posición en CT a bajo costo.

0x2.2 Extracción de Depeg Swap: Control de Acceso Ausente en CorkHook.beforeSwap

En el diseño estándar de hooks de Uniswap v4, beforeSwap es llamado exclusivamente por el PoolManager durante un swap. La implementación de Cork no aplicó esta restricción:

// Falta: require(msg.sender == address(poolManager));
function beforeSwap(
    address sender,
    PoolKey calldata key,
    IPoolManager.SwapParams calldata params,
    bytes calldata hookData
) external override returns (bytes4, BeforeSwapDelta, uint24) {
    ...
}

Sin esta verificación, cualquier contrato externo puede llamar a beforeSwap directamente con hookData arbitrario. Cuando hookData no está vacío, la función entra en la ruta de ejecución de FlashSwap (Sección 0x1.2), que descompone RA en CT y DS mediante depositPsm. El atacante explotó esto invocando beforeSwap directamente con hookData manipulado que especificaba los tokens de un mercado falso, haciendo que el protocolo descompusiera los tokens y transfiriera los resultados al atacante.

0x2.3 Cómo se Combinan las Dos Fallas

Ninguna vulnerabilidad por sí sola es suficiente para extraer los 12 millones de dólares completos.

La manipulación de HIYA le proporciona al atacante CT barato, pero CT por sí solo no puede canjearse por RA. La fórmula de canje requiere ambos tokens: CT + DS = RA. El atacante aún necesita una forma de obtener DS.

El control de acceso ausente en beforeSwap proporciona ese camino. Al llamar a beforeSwap directamente con hookData manipulado, el atacante puede activar la ruta de descomposición de FlashSwap con parámetros arbitrarios. Para obtener DS real a través de esta ruta, el atacante despliega un mercado falso que designa el DS real como su RA, luego llama a beforeSwap para descomponer ese "RA" (DS real) en CT falso y DS falso, que pueden intercambiarse de vuelta por DS real a través del mercado falso.

Con tanto CT (de la manipulación de HIYA) como DS (de la llamada no autenticada a beforeSwap mediante el mercado falso) en su poder, el atacante los canjea 1:1 por RA (wstETH).

0x3 Análisis del Ataque

El ataque se desarrolla en tres transacciones, cada una correspondiente a una fase: inflar el HIYA, adquirir CT barato y extraer DS para completar el par de canje.

0x3.1 Preparación: Inflando el HIYA

En esta transacción, el atacante llamó a SwapRaForDs() poco antes del vencimiento del mercado. Dado que $TT$ estaba cerca de cero, este swap generó una prima de riesgo desproporcionadamente grande (Sección 0x1.3), inflando accumulatedHIYA.

El atacante posee después de esta fase: DS del swap (utilizado posteriormente en la Fase 0x3.3), y un accumulatedHIYA inflado almacenado en la cadena.

0x3.2 Inicialización: Adquisición de CT Barato

En esta transacción, se inicializó el nuevo plazo de mercado. El protocolo leyó el accumulatedHIYA inflado y estableció una relación de precios CT/RA distorsionada en el AMM, fijando el precio de CT muy por debajo de su valor justo. El atacante entonces intercambió ~0.000003e18 RA por 3.760e18 CT a este precio deflactado.

El atacante posee después de esta fase: una gran posición en CT (adquirida a bajo costo mediante el precio de inicialización manipulado).

0x3.3 Extracción: Obtención de DS mediante el Mercado Falso

Esta fase utiliza la vulnerabilidad de control de acceso (Sección 0x2.2) para extraer DS, completando el par CT + DS necesario para el canje de RA. La técnica central es un mercado falso que trata el DS real como su activo de canje:

Los pasos clave de la transacción de ataque:

1. El atacante primero intercambió RA por DS en el mercado legítimo.

   El atacante posee: DS real.

2. El atacante desplegó e inicializó el mercado falso, designando el DS real como RA falso.

   

3. El atacante invocó beforeSwap directamente (explotando el control de acceso ausente) con hookData no vacío, activando la ruta de ejecución de FlashSwap contra el mercado falso. Dentro del hookData, el atacante especificó paymentToken como CT falso, haciendo que el protocolo ejecutara la lógica de descomposición de RA contra el mercado falso.

   

4. El protocolo descompuso todo el RA falso (es decir, DS real) en CT falso y DS falso. La totalidad del DS falso fue transferida al atacante, y la porción de CT falso (menos un paymentAmount mínimo) fue reembolsada.

   El atacante posee: 3.761e18 CT falso + 3.761e18 DS falso (ambos derivados de DS real).

5. El atacante intercambió CT falso y DS falso de vuelta a RA falso dentro del mercado falso, recuperando el DS real.

   El atacante posee: 3.761e18 DS real (recuperado).

6. El atacante combinó el DS recuperado con el CT obtenido en la Sección 0x3.2 para canjear RA (wstETH), completando la extracción de beneficios.

   El atacante posee: 3.760e18 RA (wstETH) de beneficio (es decir, $12M).

Resumen

Este incidente combinó dos fallas independientes, ninguna suficiente por sí sola, en una única cadena de exploit que drenó 12 millones de dólares del protocolo.

• Prima de riesgo exponencial cerca del vencimiento. La fórmula de precios HIYA amplifica las primas de riesgo a medida que el tiempo hasta el vencimiento se aproxima a cero, convirtiendo los swaps en etapas tardías en un vector de manipulación para los precios de reinicialización del mercado.
• Validación de remitente ausente en callbacks de hooks. CorkHook.beforeSwap no verificaba que msg.sender fuera el PoolManager, permitiendo la invocación directa con parámetros arbitrarios y permitiendo al atacante suplantar la ruta de ejecución de FlashSwap.
• La interacción entre módulos como punto ciego. El diseño económico (precios basados en HIYA) y la brecha de control de acceso (callback de hook no autenticado) residían en módulos separados. Su interacción creó una ruta explotable que el análisis de módulo único difícilmente detectaría.

Referencias

1. https://www.cork.tech/blog/post-mortem

2. https://docs.cork.tech/core-concepts/cork-pool

Acerca de BlockSec

BlockSec es un proveedor integral de seguridad blockchain y cumplimiento normativo en criptomonedas. Desarrollamos productos y servicios que ayudan a los clientes a realizar auditorías de código (incluyendo contratos inteligentes, blockchain y carteras), interceptar ataques en tiempo real, analizar incidentes, rastrear fondos ilícitos y cumplir con las obligaciones AML/CFT, a lo largo de todo el ciclo de vida de protocolos y plataformas.

BlockSec ha publicado múltiples artículos de seguridad blockchain en conferencias de prestigio, ha reportado varios ataques de día cero en aplicaciones DeFi, ha bloqueado múltiples hackeos rescatando más de 20 millones de dólares y ha asegurado miles de millones en criptomonedas.

• Sitio web oficial: https://blocksec.com/

• Cuenta oficial de Twitter: https://twitter.com/BlockSecTeam

• 🔗 Servicio de Auditoría de BlockSec : Enviar una solicitud

• 🔗 Phalcon Security APP: Reservar una demo

• 🔗 Phalcon Compliance