El 18 de abril de 2026, el protocolo de replanteo de liquidez de Kelp DAO fue atacado, y en pocas horas, los atacantes extrajeron 116,500 rsETH del puente entre cadenas, con un valor aproximado de 293 millones de dólares al precio de ese momento. Todo el proceso fue anormalmente eficiente: desde la falsificación de mensajes entre cadenas hasta la dispersión del botín en tres protocolos de préstamo (Aave V3, Compound V3 y Euler) para obtener activos reales, los atacantes se retiraron el mismo día con 236 millones de dólares en WETH. Aave, SparkLend y Fluid congelaron inmediatamente todos los mercados de rsETH.
Este es el mayor ataque a DeFi en 2026 hasta la fecha.
Pero hay algo que distingue a este ataque de la mayoría de los incidentes de hacking. El código del contrato inteligente de Kelp DAO no tenía ninguna vulnerabilidad. El investigador de seguridad @0xQuit, que participó en la investigación, escribió en X: «Por lo que he visto hasta ahora, esto fue una superposición de dos problemas: la configuración DVN 1-de-1, y el hecho de que el propio nodo DVN fue comprometido». LayerZero, en su declaración oficial, tampoco mencionó el código del contrato, calificando el problema como una «vulnerabilidad de rsETH» y no una «vulnerabilidad de LayerZero».
293 millones de dólares, no estaban en ninguna línea de código. Estaban escondidos en un parámetro de configuración mal ingresado durante la implementación.
La lógica general de la auditoría de seguridad en DeFi es: encontrar contratos, leer código, buscar vulnerabilidades. Esta lógica funciona bastante bien para detectar vulnerabilidades lógicas en el código; herramientas como Slither y Mythril tienen capacidades bastante maduras para detectar patrones conocidos como ataques de reentrada o desbordamientos de enteros. La auditoría de código asistida por LLM, promovida con fuerza en los últimos dos años, también tiene cierta capacidad para detectar vulnerabilidades de lógica de negocio (como rutas de arbitraje con flash loans).
Pero hay dos filas en rojo en esta matriz.
Las vulnerabilidades a nivel de configuración son un punto ciego estructural en las herramientas de auditoría. El problema de Kelp DAO no estaba en un archivo .sol, sino en un parámetro escrito durante la implementación del protocolo: el umbral DVN. Este parámetro determina cuántos nodos de validación deben confirmar un mensaje entre cadenas para que se considere legítimo. No entra en el código, no entra en el alcance de escaneo de Slither, ni en la ruta de ejecución simbólica de Mythril. Según un estudio comparativo de Dreamlab Technologies, Slither y Mythril detectaron 5/10 y 6/10 de las vulnerabilidades en los contratos probados, pero este resultado se basa en la premisa de que «la vulnerabilidad está en el código». Según un estudio de IEEE, incluso a nivel de código, las herramientas existentes solo pueden detectar entre el 8% y el 20% de las vulnerabilidades explotables.
Desde la perspectiva del paradigma de auditoría actual, no existe una herramienta que pueda «detectar si el umbral DVN es razonable». Para detectar este tipo de riesgos de configuración, no se necesita un analizador de código, sino una lista de verificación específica: «¿El número de DVN del protocolo entre cadenas utilizado es ≥ N?», «¿Existe un requisito de umbral mínimo?». Este tipo de preguntas actualmente no están cubiertas por herramientas estandarizadas, ni siquiera existe una norma industrial ampliamente reconocida.
También en la zona roja está la seguridad de claves y nodos. La descripción de @0xQuit menciona que el nodo DVN fue «comprometido», lo cual pertenece al ámbito de la seguridad operativa (OpSec), más allá de los límites de detección de cualquier herramienta de análisis estático. Ninguna de las principales firmas de auditoría, ni las herramientas de escaneo con IA, tienen la capacidad de predecir si la clave privada de un operador de nodos será filtrada.
Este ataque activó simultáneamente las dos zonas rojas de la matriz.
DVN es el mecanismo de verificación de mensajes entre cadenas de LayerZero V2, cuyo nombre completo es Decentralized Verifier Network (Red de Verificadores Descentralizados). Su filosofía de diseño es ceder el poder de decisión sobre la seguridad a la capa de aplicación: cada protocolo que se conecta a LayerZero puede elegir cuántos nodos DVN necesitan confirmar simultáneamente un mensaje entre cadenas para permitir su paso.
Esta «libertad» crea un espectro.
Kelp DAO eligió el extremo más a la izquierda del espectro: 1-de-1, que requiere la confirmación de un solo nodo DVN. Esto significa una tolerancia a fallos de cero; el atacante solo necesita comprometer ese único nodo para falsificar cualquier mensaje entre cadenas. En contraste, Apechain, que también utiliza LayerZero, configuró dos o más DVN obligatorios y no se vio afectado en este incidente. La declaración oficial de LayerZero decía: «Todas las demás aplicaciones siguen seguras», cuya implicación es: la seguridad depende de la configuración que elijas.
La recomendación normal de la industria es al menos 2-de-3, donde el atacante necesitaría comprometer dos nodos DVN independientes simultáneamente para falsificar un mensaje, elevando la tolerancia a fallos al 33%. Configuraciones de alta seguridad como 5-de-9 pueden alcanzar una tolerancia a fallos del 55%.
El problema es que los observadores externos y los usuarios no pueden ver esta configuración. Lo que se llama igualmente «compatible con LayerZero» puede ocultar una tolerancia a fallos del 0% o del 55%. Ambos se llaman DVN en la documentación.
La inversora senior en cripto, Dovey Wan, que vivió el incidente de Anyswap, escribió directamente en X: «El DVN de LayerZero era竟然 1/1 validador...... Todos los puentes entre cadenas deberían hacer inmediatamente una revisión de seguridad completa».
En agosto de 2022, se descubrió una vulnerabilidad en el puente entre cadenas Nomad. Alguien copió la primera transacción de ataque, la modificó ligeramente y descubrió que también funcionaba, por lo que cientos de direcciones comenzaron a copiarla, vaciando 190 millones de dólares en unas horas.
El análisis posterior de Nomad escribió que la vulnerabilidad provenía de «inicializar la raíz trusted (confiable) a 0x00 durante una actualización rutinaria». Este fue un error de configuración, ocurrido durante la fase de implementación. La lógica de verificación de pruebas Merkle no tenía problemas, el código en sí no tenía problemas; el problema fue que se ingresó un valor inicial incorrecto.
Este caso y el de Nomad juntos, las vulnerabilidades de tipo configuración/inicialización han causado pérdidas de aproximadamente 482 millones de dólares. En la historia de robos de puentes entre cadenas, esta categoría ya puede equipararse con la de filtraciones de claves (Ronin 624 millones, Harmony 100 millones, Multichain 126 millones, total approx. 850 millones).
Pero el diseño de productos de la industria de auditoría de código nunca ha estado dirigido a esta categoría.
Lo que más se discute en la industria siguen siendo las vulnerabilidades de lógica de código. Wormhole perdió 326 millones por una omisión en la verificación de firmas, Qubit Finance perdió 80 millones por un evento de depósito falso. Estos casos tienen informes de análisis de vulnerabilidades completos, números CVE análogos, PoC reproducibles, y son adecuados para el entrenamiento y optimización de herramientas de auditoría. Los problemas a nivel de configuración no se escriben en el código y es difícil que entren en este ciclo de producción.
Un detalle digno de mención es que la forma de activación de los dos eventos de configuración fue completamente diferente. Nomad fue un error al ingresar un valor inicial incorrecto durante una actualización rutinaria, un descuido. La configuración 1-de-1 de Kelp DAO fue una elección de configuración activa: el protocolo LayerZero no prohíbe esta opción, y Kelp DAO no violó ninguna regla del protocolo. Una elección de configuración «conforme» y un valor inicial por «error» condujeron finalmente al mismo resultado.
La lógica de ejecución de este ataque fue simple: un mensaje entre cadenas falso le dijo a la red principal de Ethereum que «en otra cadena alguien ya había bloqueado activos equivalentes», lo que desencadenó la acuñación de rsETH en la red principal. Los rsETH acuñados no tenían respaldo real, pero su registro en cadena era «legítimo» y podía ser aceptado como garantía por los protocolos de préstamo.
El atacante dispersó inmediatamente las 116,500 rsETH en Aave V3 (Ethereum y Arbitrum), Compound V3 y Euler, y tomó prestados activos reales por un total de más de 236 millones de dólares. Según múltiples informes, la estimación de deuda incobrable que enfrentaba solo Aave V3 era de aproximadamente 177 millones de dólares. Las reservas de WETH del módulo de seguridad Umbrella de Aave, que pueden usarse para absorber deudas incobrables, son de aproximadamente 50 millones de dólares, con una cobertura de menos del 30%; el resto será asumido por los que apostaban aWETH.
Esta deuda finalmente recayó en aquellos que solo querían ganar un poco de interés con WETH.
LayerZero oficial, al cierre de esta edición, aún investigaba conjuntamente con la organización de respuesta a emergencias de seguridad SEAL Org, indicando que publicaría un informe de análisis posterior junto con Kelp DAO una vez obtenida toda la información. Kelp DAO declaró que está llevando a cabo una «remediación activa».
La vulnerabilidad de 293 millones de dólares no estaba en el código. Las palabras «auditoría aprobada» no cubrían la ubicación de ese parámetro.
