Desaparecieron 293 millones de dólares, código sin vulnerabilidades: el mayor ciberataque de 2026 deja al descubierto puntos ciegos de seguridad en la configuración de DVN.

El 18 de abril de 2026, el protocolo de re-apuesta de liquidez de Kelp DAO fue comprometido por un atacante que sustrajo 116.500 rsETH del puente entre cadenas en cuestión de horas, lo que equivalía a aproximadamente 293 millones de dólares en ese momento. Todo el proceso fue inusualmente eficiente, desde la falsificación de mensajes entre cadenas hasta la distribución de los fondos robados a través de tres protocolos de préstamos (Aave V3, Compound V3 y Euler) para obtener préstamos de activos reales. Los atacantes retiraron 236 millones de dólares en WETH ese mismo día. Posteriormente, Aave, SparkLend y Fluid congelaron el mercado de rsETH.

Este es el mayor ataque a DeFi registrado hasta ahora en 2026.

Pero hay algo que distingue este ataque de la mayoría de los incidentes de piratería informática: el código del contrato inteligente de Kelp DAO no contenía vulnerabilidades. El investigador de seguridad @0xQuit, que participó en la investigación, escribió en X: "Por lo que entiendo, se trata de una combinación de dos problemas: una configuración DVN única y la vulneración del propio nodo DVN". La declaración oficial de LayerZero tampoco mencionó el código del contrato, calificando el problema como una "vulnerabilidad de rsETH" en lugar de una "vulnerabilidad de LayerZero".

Los 293 millones de dólares no aparecen en ninguna línea de código. Están ocultos en un parámetro de configuración que se introdujo incorrectamente durante la implementación.

La lógica general de la auditoría de seguridad en DeFi es: encontrar el contrato, leer el código y detectar vulnerabilidades. Esta lógica funciona bastante bien al tratar con vulnerabilidades en la lógica del código. Herramientas como Slither y Mythril cuentan con capacidades relativamente maduras para detectar patrones conocidos, como ataques de reentrada y desbordamientos de enteros. La auditoría de código asistida por LLM, que se ha promovido intensamente en los últimos dos años, también tiene cierta capacidad para detectar vulnerabilidades en la lógica de negocio (como rutas de arbitraje de préstamos flash).

Sin embargo, hay dos filas rojas en esta matriz.

Las vulnerabilidades en la capa de configuración representan un punto ciego estructural en la auditoría de herramientas. El problema con Kelp DAO no reside en el archivo .sol, sino en un parámetro escrito durante el despliegue del protocolo: el umbral DVN. Este parámetro determina cuántos nodos de verificación debe confirmar un mensaje entre cadenas para considerarse legítimo. No forma parte del código, no está dentro del alcance de escaneo de Slither ni entra 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 vulnerabilidades respectivamente en los contratos probados, pero este logro se basa en la premisa de que "las vulnerabilidades están en el código". Según una investigación del 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 de los paradigmas de auditoría existentes, no existe ninguna herramienta que pueda detectar si el umbral de DVN es razonable. Para detectar este tipo de riesgo de configuración, no se necesita un analizador de código, sino una lista de verificación de configuración específica: "¿El número de DVN utilizados en el protocolo entre cadenas es ≥ N?", "¿Existe un requisito de umbral mínimo?". Actualmente no existen herramientas estandarizadas para abordar este tipo de cuestiones, ni siquiera estándares ampliamente reconocidos en la industria.

Dentro del área roja también se encuentran las claves y la seguridad de los nodos. La descripción de @0xQuit menciona que un nodo DVN fue "vulnerado", lo cual se enmarca dentro de la seguridad operativa (OpSec) y escapa a la capacidad de detección de cualquier herramienta de análisis estático. Ni las principales firmas de auditoría ni las herramientas de escaneo de IA pueden predecir si la clave privada de un operador de nodo se filtrará.

Este ataque activó simultáneamente dos zonas rojas en la matriz.

DVN es el mecanismo de verificación de mensajes entre cadenas para LayerZero V2, abreviatura de Red de Verificadores Descentralizados. Su filosofía de diseño consiste en delegar el poder de decisión en materia de seguridad a la capa de aplicación: cada protocolo conectado a LayerZero puede elegir cuántos nodos DVN deben confirmar simultáneamente antes de permitir el paso de un mensaje entre cadenas.

Este "grado de libertad" produce un espectro.

Kelp DAO optó por la configuración 1 de 1 más a la izquierda del espectro, que requiere solo un nodo DVN para la confirmación. Esto implica tolerancia cero a fallos; un atacante solo necesita comprometer ese nodo para falsificar mensajes arbitrarios entre cadenas. En contraste, Apechain, que también se integra con LayerZero pero configura más de dos DVN necesarios, no se vio afectado por este incidente. El comunicado oficial de LayerZero afirmó que "todas las demás aplicaciones permanecen seguras", lo que implica que la seguridad depende de la configuración elegida.

La recomendación estándar de la industria es de al menos 2 de 3, lo que requiere que los atacantes comprometan dos nodos DVN independientes simultáneamente para falsificar mensajes, aumentando la tolerancia a fallos al 33 %. Las configuraciones de alta seguridad, como 5 de 9, pueden alcanzar una tolerancia a fallos de hasta el 55 %.

El problema es que los observadores y usuarios externos no pueden ver esta configuración. Ambas están etiquetadas como "Powered by LayerZero", pero la tolerancia a fallos subyacente podría ser del 0% o del 55%. En la documentación, ambas se denominan DVN.

Dovey Wan, una inversora veterana en criptomonedas que vivió el incidente de Anyswap, escribió directamente en X: "El DVN de LayerZero es un validador 1/1... Todos los puentes entre cadenas deberían someterse a una revisión de seguridad completa de inmediato".

En agosto de 2022, se descubrió una vulnerabilidad en el puente entre cadenas de Nomad. Alguien copió la primera transacción de ataque, le hizo pequeñas modificaciones y comprobó que tenía éxito; entonces, varios cientos de direcciones comenzaron a copiarla, robando 190 millones de dólares en pocas horas.

El análisis posterior al incidente realizado por Nomad indicó que la vulnerabilidad se originó al "inicializar la raíz de confianza a 0x00 durante una actualización rutinaria". Se trató de un error de configuración ocurrido durante la fase de implementación. Merkle demostró que la lógica de verificación era correcta, que el código en sí no presentaba fallos y que el problema radicaba en un valor inicial incorrecto.

Junto con Nomad, las vulnerabilidades de configuración/inicialización han causado pérdidas de aproximadamente 482 millones de dólares. En toda la historia de los robos de puentes entre cadenas, esta categoría es comparable en magnitud a las filtraciones de claves (624 millones de dólares para Ronin, 100 millones para Harmony y 126 millones para Multichain, lo que suma un total aproximado de 850 millones de dólares).

Sin embargo, el diseño de productos en la industria de la auditoría de código nunca se ha orientado hacia esta categoría.

El tema más debatido en el sector sigue siendo la vulnerabilidad de la lógica del código. Ejemplos de ello son la pérdida de 326 millones de dólares de Wormhole debido a la omisión de la verificación de firmas y el robo de 80 millones de dólares de Qubit Finance por depósitos fraudulentos. Estos casos cuentan con informes completos de análisis de vulnerabilidades, comparaciones de números CVE y pruebas de concepto reproducibles, lo que los hace idóneos para la formación y la optimización de herramientas de auditoría. Es improbable que los problemas de configuración, si no se abordan en el código, se implementen en el ciclo de producción.

Un detalle importante es que los dos eventos de configuración se activaron de maneras radicalmente diferentes. Nomad introdujo accidentalmente un valor inicial incorrecto durante una actualización rutinaria, lo cual fue un error. Por otro lado, la configuración 1 de 1 de Kelp DAO fue una decisión proactiva: el protocolo LayerZero no prohíbe esta opción y Kelp DAO no infringió ninguna regla del protocolo. Una configuración "conforme" y un valor inicial "erróneo" conducen, en última instancia, a la misma consecuencia.

La lógica de ejecución de este ataque es simple: un mensaje falsificado entre cadenas le indica a la red principal de Ethereum que "alguien en otra cadena ha bloqueado activos de valor equivalente", lo que activa la creación de rsETH en la red principal. El rsETH creado no tiene respaldo real, pero su registro en la cadena es "legítimo" y puede ser aceptado como garantía por los protocolos de préstamos.

Los atacantes distribuyeron 116.500 rsETH entre Aave V3 (Ethereum y Arbitrum), Compound V3 y Euler, prestando un total de más de 236 millones de dólares en activos reales. Según varios informes, Aave V3, por sí solo, enfrenta una deuda incobrable estimada en 177 millones de dólares. El módulo de seguridad de Aave, Umbrella, cuenta con aproximadamente 50 millones de dólares en reservas de WETH disponibles para absorber la deuda incobrable, lo que cubre menos del 30% del total; el resto será cubierto por los participantes de aWETH.

En última instancia, esta carga recae sobre aquellos que simplemente querían obtener un pequeño interés en WETH.

Al cierre de esta edición, LayerZero continúa realizando una investigación conjunta con la organización de respuesta a incidentes de seguridad SEAL Org, y ha declarado que publicará un informe de análisis posterior al incidente con Kelp DAO una vez que obtenga toda la información. Kelp DAO ha indicado que está llevando a cabo medidas correctivas proactivas.

La vulnerabilidad de 293 millones de dólares no estaba en el código. La frase "Auditoría superada" no ocultaba la ubicación de ese parámetro.