El 15 de octubre de 2026, un atacante logró extraer aproximadamente 2.31 ETH de KolanHook, un hook de Uniswap v4 en la red principal de Ethereum, y retuvo cerca de 1.28 ETH (alrededor de $3,000) como ganancia después de pagar un préstamo flash. Aunque el monto en dólares es pequeño, el patrón de ataque es preocupante: un contrato que gasta sus propias reservas en un swap, al precio de mercado que sea, y que puede ser activado por cualquiera, es una vulnerabilidad esperando ser explotada. Este incidente, reportado por Panda Security y analizado por Defimon y ChainBounty, revela fallas críticas en el diseño de hooks que operan con fondos propios.
¿Qué es KolanHook y cómo funcionaba?
Según la documentación de Kolan, el sistema consta de dos contratos: KolanHook, que custodia la liquidez del pool y las llamadas “ventanas”, y KolanToken, un ERC-20 de suministro fijo (1,000,000 KLN) acuñado una sola vez para el hook. No hay propietario, ni proxy, ni función de pausa, y el hook rechaza liquidez externa. La documentación también indica claramente que los contratos están probados pero no auditados.
Una “ventana” se adjunta a una compra. El comprador paga una prima sobre el ETH que gasta y, durante un período, puede deshacer la compra. Una vez que la ventana expira, ya no se puede deshacer, solo mantener, y la documentación describe que cerrarla es algo que cualquiera puede hacer después del vencimiento. Cuando se cierra una ventana, el hook utiliza el ETH que posee para recomprar KLN y quemarlo. Este diseño le da al hook dos funciones simultáneas: es el mercado de liquidez y también un trader que periódicamente compra en ese mercado.
La vulnerabilidad: recompra sin control de precio
El problema radica en la combinación de dos propiedades que, por separado, podrían ser defendibles. Por un lado, hacer que la función accept() sea permissionless después del vencimiento es una decisión razonable para mantener la vitalidad del sistema: nadie quiere ventanas atascadas porque el comprador se desconectó. Pero esto también significa que el momento de la recompra lo elige quien llame a la función, incluso alguien que acaba de mover el precio.
Según el análisis de Defimon, la cadena de llamadas es accept → _closeWindow → _buyBack(), y la recompra intercambia el ETH del hook en el pool con sqrtPriceLimitX96 = MIN_SQRT_PRICE + 1. En Uniswap v4, ese límite es el precio más lejano al que el swap puede moverse. Establecerlo en el extremo le dice al PoolManager “lléname a cualquier precio”. En esta ruta no hay nada que compare el precio spot actual con un precio de referencia, un TWAP o una salida mínima. La cantidad de KLN que recibe el hook es la que el pool le dé en ese momento.
Secuencia del ataque y cifras
Los datos provienen de la alerta de Defimon y del desglose de la transacción publicado por ChainBounty; las cifras están redondeadas. El atacante tomó un préstamo flash, manipuló el precio del pool y luego llamó a la función de cierre de ventana para ejecutar la recompra a un precio desfavorable para el hook. La diferencia entre la salida de 2.31 ETH del hook y la ganancia de 1.28 ETH del atacante se explica por las comisiones del swap, el impuesto del 1% del token y el impacto en el precio. Reportar “2.31 ETH robados” o “1.28 ETH perdidos” por separado sería engañoso.
Este es el clásico sándwich de una operación propiedad del protocolo. Normalmente, los bots de MEV hacen sándwich a los usuarios; aquí la víctima fue la lógica de tesorería del propio protocolo, y el atacante ni siquiera tuvo que esperar a que operara. Pudo hacer que operara a demanda.
Lecciones para desarrolladores de hooks
Ya hemos cubierto cómo funcionan los hooks en Uniswap v4 y dos incidentes recientes en este blog, el drenaje de rebalanceo de GoldPesa GPXHooks y el exploit de la bóveda de acciones de un wei, que apuntan al mismo tema: una vez que un hook posee valor y actúa por su cuenta, hereda todos los riesgos de un trader en cadena. Los hooks facilitan equivocarse por tres razones:
- La lógica de trading automatizado a menudo se implementa sin protecciones de precio.
- Las funciones permissionless permiten que cualquiera active operaciones en momentos manipulados.
- La falta de auditorías deja vulnerabilidades sin detectar.
Una versión endurecida de la recompra podría incluir verificaciones de deslizamiento y fuentes de precio confiables. Nuestra lista de verificación de seguridad de contratos inteligentes incluye estas comprobaciones para cualquier contrato que realice swaps.
KolanHook perdió unos pocos miles de dólares, pero su diseño no es inusual. Muchos hooks nuevos recompran, rebalancean o capitalizan con sus propios fondos, y muchos permiten que cualquiera lo active. Si tu hook opera, el precio que acepta es parte de tu modelo de seguridad, no una optimización de gas que puedas omitir.
¿Estás construyendo un hook de Uniswap v4 o un token con recompras automatizadas? Contacta a Panda Security para una revisión antes del lanzamiento.
