Top 3 Incidentos de DeFi en Abril
KelpDAO: ~$290M
El 18 de abril de 2026, el puente rsETH LayerZero OFT de KelpDAO fue explotado por aproximadamente $290M.
La causa raíz fue la configuración insegura 1-de-1 DVN de KelpDAO, que redujo la verificación de mensajes entre cadenas a un único punto de falla. Después de comprometer la infraestructura RPC en la que confiaba el LayerZero Labs DVN, el atacante forzó al único verificador a certificar un mensaje entre cadenas fabricado. Como resultado, se liberaron 116,500 rsETH en Ethereum sin ningún evento correspondiente del lado de origen en Unichain.
Este incidente no fue causado por una falla en el propio protocolo LayerZero, sino por un fallo de seguridad operativa más amplio que abarcó la configuración del puente y las suposiciones de confianza en la infraestructura. Dado que KelpDAO dependía de un solo DVN, no había un verificador independiente que pudiera cuestionar el mensaje falsificado. Al mismo tiempo, el atacante envenenó los nodos RPC utilizados por ese DVN y realizó un DDoS a los nodos restantes que funcionaban correctamente, forzando al verificador a un estado de conmutación por error en el que dependía completamente de datos controlados por el atacante. Una vez que se certificó el mensaje falso, el adaptador rsETH del lado de Ethereum se ejecutó según lo previsto y liberó los fondos, que luego fueron dispersados y lavados rápidamente a través de múltiples billeteras y cadenas.
Este incidente destaca que la seguridad de los puentes no puede depender únicamente de la corrección del protocolo. Los proyectos deben adoptar configuraciones multi-DVN con verificadores independientes, tratar las interrupciones repentinas de los nodos RPC durante la verificación como señales de ataque en lugar de problemas de disponibilidad rutinarios, y fortalecer la infraestructura que alimenta los datos de la cadena de origen a las redes de verificadores.
Para un análisis detallado, lee nuestra publicación en profundidad:
Drift Protocol: ~$285M
El 1 de abril de 2026, Drift Protocol en Solana fue explotado por aproximadamente $285M.
La causa raíz no fue una vulnerabilidad de contrato inteligente, sino un fallo en el proceso de gobernanza y autorización del protocolo. En ese momento, Drift utilizaba una configuración multisig de 2-de-5 para acciones de alto privilegio, lo que significaba que cualquiera de dos de los cinco firmantes autorizados podía aprobar cambios administrativos críticos. Estas acciones tampoco estaban sujetas a ningún timelock. Una vez recopiladas suficientes aprobaciones, podían ejecutarse inmediatamente. Agravando este riesgo estaba el mecanismo de nonce duradero de Solana, que permitía que las transacciones prefirmadas permanecieran válidas durante mucho tiempo en lugar de expirar rápidamente como las transacciones ordinarias. Esto le dio al atacante tiempo para recopilar firmas maliciosas de antemano y esperar el momento adecuado para usarlas. Después de inducir a dos de los cinco firmantes a aprobar transacciones de gobernanza maliciosas, el atacante posteriormente envió esas transacciones para tomar el control administrativo del protocolo. Con ese acceso, el atacante listó un activo de garantía falso llamado CarbonVote Token (CVT), manipuló su precio de Oracle, relajó las restricciones de retiro y utilizó la garantía falsa para vaciar grandes cantidades de activos reales a través del Drift Vault.
Este incidente expuso tres debilidades importantes en el diseño de gobernanza de Drift. Primero, el atacante pudo separar la recopilación de firmas de la ejecución porque las aprobaciones robadas no expiraban rápidamente. Segundo, la falta de un timelock significó que la toma de control administrativa se hizo efectiva inmediatamente, dejando casi ningún tiempo para la detección o intervención. Tercero, el rol de administrador era demasiado poderoso: una vez comprometido, permitió al atacante crear un nuevo mercado de garantías, cambiar la configuración del oráculo y relajar los controles de retiro, todo lo cual habilitó directamente el robo.
Este incidente muestra que la seguridad de la gobernanza no se trata solo de proteger las claves privadas. Los protocolos también necesitan asegurar todo el proceso de firma y aprobación, agregar demoras a las acciones de alto privilegio, limitar el uso de transacciones prefirmadas de larga duración y reducir el alcance de lo que puede lograr una sola toma de control administrativa.
Para un análisis detallado, lee nuestra publicación en profundidad:
Rhea Finance: ~$18.4M
El 16 de abril de 2026, el protocolo Burrowland de Rhea Finance en NEAR fue explotado por aproximadamente $18.4M debido a una falla en la lógica de negocio en su módulo de trading con margen. Cabe destacar que, a partir del 23 de abril de 2026, todos los fondos robados habían sido recuperados.
La causa raíz fue que el protocolo trataba una declaración de salida de swap proporcionada por el usuario como si representara con precisión la cantidad que realmente sería devuelta por el DEX. Sin embargo, un usuario malicioso podía construir una ruta de swap circular que reciclaba las salidas intermedias dentro de la ruta, inflando artificialmente la salida final declarada y manipulando la contabilidad del protocolo. Como resultado, las verificaciones de solvencia y apalancamiento del protocolo dependían de un valor fabricado en lugar de la cantidad real recibida. Esta falla tenía su raíz en la función verify_token_out(), que contaba incorrectamente ciertas salidas intermedias como parte del resultado final, aunque luego se reutilizaban dentro de la ruta del swap.
Después de eludir estas verificaciones, el atacante enrutó activos prestados fuera del protocolo a través de pools falsos controlados por el atacante, mientras que el protocolo recibió a cambio solo una cantidad insignificante de valor. El atacante luego retiró liquidez de estos pools para extraer los fondos. Al repetir este proceso, el atacante finalmente vació aproximadamente $18.4M de Burrowland.
Este incidente muestra que los protocolos de trading con margen no deben tratar las salidas de swap declaradas por el usuario como una entrada confiable. Los protocolos deben asegurarse de que las verificaciones de solvencia se basen en el valor realmente recibido, rechazar rutas de swap que puedan reciclar activos intermedios y evitar que la lógica contable pueda ser manipulada mediante enrutamiento circular.
El Mejor Auditor de Seguridad para Web3
Valida el diseño, el código y la lógica de negocio antes del lanzamiento
La información anterior se basa en datos a partir de las 00:00 UTC del 29 de abril de 2026.
Esto concluye el resumen de incidentes de seguridad de abril.
Puedes aprender más en nuestra Biblioteca de Incidentes de Seguridad.
¡Mantente informado y mantente seguro!
