Exploit Kelp — $293.0M drenados · post-mortem · GuardLabs

Análisis técnico del exploit Kelp (2026-04-18). Clasificado como Infrastructure. $293.0M drenados en Ethereum, Arbitrum.

Análisis técnico

El exploit del protocolo Kelp, que resultó en una pérdida de aproximadamente 293.000.000 $, se originó por un fallo crítico en su integración con el protocolo de mensajería LayerZero, específicamente dentro de su implementación de Omnichain Fungible Token (OFT). El estándar OFT está diseñado para permitir que los tokens existan de forma nativa en múltiples blockchains, utilizando la capa de transporte de LayerZero para enviar mensajes (p. ej., 'quemar en la Cadena A, acuñar en la Cadena B') que mantienen la oferta total consistente. La vulnerabilidad no estaba en la infraestructura central de LayerZero en sí, sino en los contratos a nivel de aplicación de Kelp que la utilizaban. La causa raíz fue un error de lógica en el contrato de la cadena de destino (p. ej., Ethereum) que procesaba los mensajes entrantes de una cadena de origen (p. ej., Arbitrum). Este contrato no validó correctamente el contenido o el origen de la carga útil del mensaje entre cadenas. Este descuido permitió a un atacante crear un mensaje malicioso en la cadena de origen que, al ser recibido y ejecutado por el contrato de destino, desencadenó una acuñación grande y no autorizada del token de Kelp.

El flujo de la explotación, aunque no se detalla en los post-mórtems públicos, se puede inferir de la naturaleza de la vulnerabilidad. Las precondiciones para el ataque incluían que el protocolo tuviera una liquidez significativa, operara en múltiples cadenas utilizando el estándar OFT y poseyera el fallo de validación específico en su manejador de mensajes entre cadenas. El atacante probablemente inició el proceso llamando a una función en el contrato Kelp OFT Adapter en la cadena de origen (p. ej., Arbitrum) con una carga útil especialmente diseñada. Esta carga útil fue diseñada para pasar las verificaciones a nivel de transporte de LayerZero pero explotar el fallo de lógica en el contrato receptor de Kelp en la cadena de destino (Ethereum). Cuando el retransmisor de LayerZero entregó este mensaje, el contrato vulnerable de Kelp en Ethereum malinterpretó la carga útil maliciosa, eludiendo las verificaciones que deberían haber asegurado que una cantidad correspondiente de tokens fuera quemada o bloqueada en la cadena de origen. Esto permitió al atacante llamar a la función interna _mint() con una cantidad arbitraria y grande, creando cientos de millones de dólares en tokens sin respaldo. Estos tokens recién acuñados fueron luego intercambiados por otros activos en los pools de liquidez, drenando su valor antes de que la discrepancia pudiera ser detectada y pausada.

Quién más está en riesgo

Cualquier protocolo que implemente funcionalidad entre cadenas utilizando capas de mensajería como LayerZero, Axelar, Wormhole o Chainlink CCIP está potencialmente en riesgo si su integración no se implementa con extremo cuidado. El exploit de Kelp sirve como un duro recordatorio de que la seguridad de la infraestructura subyacente no garantiza automáticamente la seguridad de la aplicación construida sobre ella. El riesgo principal reside en las 'costuras' entre la lógica propia del protocolo y la capa de mensajería de terceros. Los desarrolladores a menudo se centran en auditar su lógica de negocio principal, pero pueden pasar por alto los matices y los posibles vectores de ataque introducidos por estas complejas integraciones. Los errores comunes de implementación incluyen una validación insuficiente de la dirección y el contrato de origen de la cadena remota, confiar en la carga útil del mensaje sin analizar y verificar su contenido contra las restricciones esperadas, y tener funciones demasiado permisivas que pueden ser activadas por un mensaje entre cadenas.

Los protocolos deben ser particularmente cautelosos con cualquier función que altere el estado de manera significativa (p. ej., mint, burn, cambiar parámetros críticos) y que sea invocable a través de un mensaje entre cadenas. Una señal clave de riesgo a buscar durante una auditoría o revisión de código es la ausencia de una validación estricta basada en rutas. Por ejemplo, un mensaje del contrato X en la cadena A solo debería poder desencadenar una acción específica y estrictamente definida en el contrato Y en la cadena B. Si el contrato receptor permite llamadas a funciones arbitrarias o no controla estrictamente los parámetros pasados desde el mensaje entre cadenas, crea una vulnerabilidad significativa.

Lecciones para desarrolladores y usuarios

Este incidente proporciona varias lecciones críticas para el ecosistema DeFi. Para los desarrolladores de smart-contract, la principal conclusión es tratar todos los datos de otra cadena como no confiables. Aquí hay pasos específicos y accionables:

• Validación Estricta de la Carga Útil: Nunca asuma la integridad de la carga útil de un mensaje entre cadenas. El contrato receptor debe analizar y validar rigurosamente cada parámetro. Para un OFT, esto significa verificar que un mensaje de acuñación corresponde a un evento de quema legítimo en un contrato de origen de confianza.
• Control de Acceso Basado en Rutas: Utilice las características de LayerZero (o equivalentes en otros protocolos) para hacer cumplir que solo un contrato específico y en lista blanca en una cadena de origen pueda llamar a una función específica en la cadena de destino. Esto evita que un atacante use un contrato no relacionado para enviar mensajes maliciosos.
• Pruebas de Invariante de Suministro: Un invariante crucial para cualquier token entre cadenas es que el suministro total en todas las cadenas permanezca constante (o cambie solo a través de mecanismos designados). Esto debe ser una parte central del conjunto de pruebas. Las pruebas automatizadas deben simular transferencias entre cadenas y afirmar que totalSupply_chainA + totalSupply_chainB permanece sin cambios.
• Monitorización en Tiempo Real: Si se hubiera implementado un servicio como Web-Audit Guardian de GuardLabs, podría haber generado una alerta inmediata sobre el anómalo evento de acuñación de varios millones de dólares, permitiendo potencialmente al equipo pausar los contratos y mitigar el daño mucho antes.

Para los usuarios y proveedores de liquidez, este exploit subraya la mayor superficie de ataque de los protocolos multicadena. Antes de depositar fondos, evalúe la documentación del proyecto sobre su modelo de seguridad entre cadenas. Busque auditorías que nombren y analicen específicamente los contratos adaptadores OFT/entre cadenas, no solo la lógica central del protocolo. Comprenda que, si bien las capacidades entre cadenas ofrecen una gran utilidad, también introducen riesgos nuevos y complejos que no están presentes en las aplicaciones de una sola cadena.

Para los traders algorítmicos, el incidente demuestra una forma de riesgo de mercado única de DeFi. Una inflación repentina y masiva del suministro de un token en una cadena puede hacer que los modelos de arbitraje sean ineficaces y provocar pérdidas extremas. Los sistemas de gestión de riesgos deben incorporar fuentes de datos en cadena que monitoreen cambios anómalos en el suministro, especialmente para tokens con presencia entre cadenas. Un exploit como este puede causar una desvinculación completa del valor del token de su respaldo previsto, haciéndolo inútil en un instante.

Preguntas frecuentes

Metadatos del exploit