Los 3 principales incidentes DeFi de 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 DVN 1-de-1 insegura de KelpDAO, que redujo la verificación de mensajes entre cadenas a un único punto de fallo. Tras comprometer la infraestructura RPC de confianza del DVN de LayerZero Labs, el atacante obligó al único verificador a atestiguar un mensaje entre cadenas fabricado. Como resultado, se liberaron 116.500 rsETH en Ethereum sin ningún evento correspondiente del lado origen en Unichain.
Este incidente no fue causado por una falla en el protocolo LayerZero en sí, sino por un fallo más amplio de seguridad operacional que abarcó la configuración del puente y las suposiciones de confianza en la infraestructura. Debido a que KelpDAO dependía de un único DVN, no había ningún verificador independiente que pudiera cuestionar el mensaje falsificado. Al mismo tiempo, el atacante envenenó los nodos RPC utilizados por ese DVN y realizó un ataque DDoS contra los nodos sanos restantes, forzando al verificador a un estado de conmutación por error donde dependía completamente de datos controlados por el atacante. Una vez que se atestiguó el mensaje falso, el adaptador rsETH del lado de Ethereum ejecutó según lo diseñado y liberó los fondos, que luego fueron dispersados y blanqueados rápidamente a través de múltiples billeteras y cadenas.
Este incidente pone de relieve 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 nodos RPC durante la verificación como señales de ataque en lugar de problemas rutinarios de disponibilidad, y reforzar la infraestructura que proporciona datos de la cadena origen a las redes de verificadores.
Para un análisis detallado, lea 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 en el contrato inteligente, sino un fallo en el proceso de gobernanza y autorización del protocolo. En ese momento, Drift utilizaba una configuración multifirma 2-de-5 para acciones de alto privilegio, lo que significaba que cualquiera de los dos de los cinco firmantes autorizados podía aprobar cambios administrativos críticos. Estas acciones tampoco estaban sujetas a ningún bloqueo temporal. Una vez recopiladas las aprobaciones suficientes, podían ejecutarse de inmediato. Este riesgo se agravaba por el mecanismo de nonce duradero de Solana, que permitía que las transacciones prefirmadas permanecieran válidas durante mucho tiempo en lugar de caducar rápidamente como las transacciones ordinarias. Esto le dio al atacante tiempo para recopilar firmas maliciosas con antelación y esperar el momento adecuado para utilizarlas. Tras inducir a dos de los cinco firmantes a aprobar transacciones de gobernanza maliciosas, el atacante las envió posteriormente para tomar el control administrativo del protocolo. Con ese acceso, el atacante registró 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 drenar grandes cantidades de activos reales a través del Drift Vault.
Este incidente expuso tres debilidades principales en el diseño de gobernanza de Drift. En primer lugar, el atacante pudo separar la recopilación de firmas de la ejecución porque las aprobaciones robadas no caducaban rápidamente. En segundo lugar, la falta de un bloqueo temporal significó que la toma de control administrativo tuvo efecto inmediato, dejando casi ningún tiempo para la detección o intervención. En tercer lugar, 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 demuestra que la seguridad de la gobernanza no se trata únicamente de proteger las claves privadas. Los protocolos también necesitan asegurar el proceso completo de firma y aprobación, añadir retrasos a las acciones de alto privilegio, limitar el uso de transacciones prefirmadas de larga duración y reducir el alcance de lo que una única toma de control administrativo puede lograr.
Para un análisis detallado, lea 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 negociación 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 la declaración de salida de intercambio proporcionada por el usuario como si representara con precisión la cantidad que realmente devolvería el DEX. Sin embargo, un usuario malicioso podía construir una ruta de intercambio 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 del importe real recibido. Esta falla tenía su origen en la función verify_token_out(), que contabilizaba incorrectamente ciertas salidas intermedias como parte del resultado final, aunque luego fueran reutilizadas dentro de la ruta de intercambio.
Tras eludir estas verificaciones, el atacante canalizó los activos prestados fuera del protocolo a través de grupos falsos controlados por él, mientras que el protocolo recibía únicamente una cantidad insignificante de valor a cambio. El atacante luego retiró liquidez de estos grupos para extraer los fondos. Al repetir este proceso, el atacante finalmente drenó aproximadamente $18.4M de Burrowland.
Este incidente demuestra que los protocolos de negociación con margen no deben tratar las salidas de intercambio declaradas por el usuario como entradas de confianza. Los protocolos deben garantizar que las verificaciones de solvencia se basen en el valor realmente recibido, rechazar rutas de intercambio que puedan reciclar activos intermedios y evitar que la lógica contable sea manipulada mediante enrutamiento circular.
La información anterior se basa en datos a las 00:00 UTC del 29 de abril de 2026.
Con esto concluye el resumen de incidentes de seguridad de abril. Para un análisis más detallado de los incidentes de seguridad en blockchain y las tendencias de seguridad en Web3, puede explorar nuestros recursos.
Puede obtener más información en nuestra Biblioteca de Incidentes de Seguridad.
¡Manténgase informado y seguro!
