No has comprado rsETH pero tu WETH está bloqueado.

Introducción

Puntos clave:

• Entre el 13 y el 19 de abril de 2026, se detectaron cuatro incidentes de ataque que involucraron varias cadenas como Ethereum, Unichain, Arbitrum y NEAR, con una pérdida total estimada de aproximadamente $310M.
• Los vectores de ataque incluyen envenenamiento de infraestructura RPC dirigido a LayerZero DVN, falsificación de pruebas MMR, abuso de enteros con signo en fondos de seguros, y explotación de rutas de intercambio circulares en protocolos de margen.
• El incidente de KelpDAO (con $290M) indica que la seguridad de los puentes entre cadenas ha superado la capa de contratos inteligentes, extendiéndose a la infraestructura de validación fuera de la cadena. La congelación en cascada de WETH en cinco cadenas y la conversión forzada de estado en Arbitrum revelan cómo la composabilidad puede amplificar fallos únicos y dónde realmente se sitúan los límites de confianza en sistemas “descentralizados”.

Durante la semana pasada (13/04/2026 - 19/04/2026), BlockSec detectó y analizó cuatro incidentes, con una pérdida total estimada de aproximadamente $310M. La tabla a continuación resume estos eventos, y las subsecciones ofrecerán un análisis detallado de cada uno.

Tabla 1: Resumen de los cuatro incidentes detectados esta semana

Aspectos destacados de esta semana: KelpDAO

Este incidente ha sido seleccionado como el punto destacado de la semana debido a su novedoso vector de ataque a infraestructura (envenenamiento RPC dirigido a DVN único en lugar de vulnerabilidades en contratos inteligentes), el impacto en cascada a múltiples cadenas a través de la composabilidad DeFi, y los problemas de gobernanza derivados de la ejecución de conversiones forzadas de estado en Arbitrum para recuperar fondos robados.

El 18 de abril de 2026, el puente cross-chain rsETH LayerZero OFT de KelpDAO fue atacado, con una pérdida de aproximadamente $290M. LayerZero Labs atribuyó el ataque a actores estatales, posiblemente del grupo Lazarus de Corea del Norte [1]. La causa raíz fue la configuración de DVN 1-de-1 de KelpDAO, que redujo la validación de mensajes cross-chain a un único punto de fallo. El atacante envenenó la infraestructura RPC confiada por el DVN de LayerZero Labs, forzando la firma de una prueba de mensaje cross-chain falsificado, lo que llevó a la liberación de 116,500 rsETH en Ethereum, aunque en la cadena fuente Unichain no hubo evento de envío correspondiente.

Contexto

LayerZero es un protocolo de mensajería cross-chain basado en una arquitectura modular de seguridad. La integridad de los mensajes cross-chain está garantizada por una red descentralizada de validadores (DVN), que son entidades fuera de la cadena responsables de verificar de forma independiente que los mensajes enviados en la cadena fuente realmente ocurrieron, antes de permitir su ejecución en la cadena destino. Cada aplicación desplegada en LayerZero configura su propio conjunto de DVN, incluyendo qué DVN confiar, cuántos deben participar y el umbral de consenso. Esta modularidad otorga control total sobre el modelo de seguridad, pero también implica responsabilidad total: una configuración débil no puede ser rescatada por el protocolo en sí.

El rsETH de KelpDAO, desplegado como OFT (Token Intercambiable en toda la cadena) en LayerZero, conecta Unichain (cadena fuente) con Ethereum Mainnet (cadena destino). El estándar OFT permite que los tokens se quemen en la cadena fuente y se liberen en la cadena destino desde un estado de bloqueo, siendo la firma de mensajes la única autorización para liberar tokens cross-chain. En el lado de Ethereum, un adaptador (0x85d456…e98ef3) se encarga de liberar rsETH al receptor tras verificar y transmitir el mensaje cross-chain.

El problema clave radica en que KelpDAO configuró esta ruta como un DVN 1-de-1, designando a LayerZero Labs como el único validador. Esto significa que una sola prueba de un DVN puede autorizar la liberación de cualquier token sin confirmación adicional.

Para cumplir con su función, el DVN de LayerZero Labs consulta múltiples nodos RPC, verificando que el evento de envío cross-chain ocurrió en la cadena fuente. Estos nodos incluyen infraestructura operada por LayerZero y proveedores externos, y la integridad del proceso se basa en que la mayoría de los nodos respondan con datos verídicos.

Análisis de vulnerabilidad

Esta vulnerabilidad es un fallo sistémico en infraestructura y configuración, compuesto por tres debilidades superpuestas:

1. La configuración DVN 1-de-1 de KelpDAO elimina redundancia en la capa de validación. La recomendación de LayerZero es usar múltiples DVN independientes para evitar que un solo DVN comprometido pueda autorizar mensajes. La dependencia en un único DVN de LayerZero Labs hace que una brecha en ese validador sea suficiente para autorizar cualquier liberación.

2. El mecanismo de conmutación por fallo del DVN permite redirigir consultas a cualquier nodo RPC accesible. Esto asume que la indisponibilidad de nodos es ocasional, no intencional. Sin embargo, un atacante puede DDoS a nodos sanos y preparar nodos envenenados como únicos accesibles, controlando así toda la información que recibe el DVN.

3. Reemplazar el ejecutable op-geth en los nodos RPC requiere acceso OS a los servidores subyacentes. Aunque no se ha divulgado el vector de acceso inicial, comprometer dos nodos en clústeres independientes sugiere vulnerabilidades compartidas en el control de acceso a estos servidores.

Estos tres factores conforman la cadena de ataque: la primera debilidad impide que un DVN independiente valide mensajes falsificados, la segunda permite controlar la información recibida por el DVN, y la tercera proporciona el punto de entrada para manipular datos. Ninguna por sí sola sería suficiente; sin la configuración 1-de-1, la consulta a infraestructura independiente sería rechazada. Sin conmutación por fallo, los nodos sanos rechazarían datos envenenados. Sin comprometer servidores, sería imposible inyectar datos falsos.

Análisis del ataque

Este análisis se basa en la transacción 0x1ae232…4222 y en la declaración oficial de LayerZero Labs.

Paso 1: El atacante obtiene la lista de nodos RPC confiables del DVN de LayerZero Labs, que es un objetivo valioso, pues conocer los nodos permite planear ataques precisos en lugar de ataques masivos a infraestructura.

Paso 2: El atacante obtiene permisos de escritura OS en dos nodos RPC y reemplaza el binario op-geth en ejecución por una versión maliciosa. Estos nodos están en clústeres independientes, lo que sugiere que el vector inicial de acceso involucra dependencias compartidas (credenciales, pipelines CI/CD, ingeniería social). LayerZero Labs no ha divulgado cómo se logró el acceso inicial. Este paso es previo a la manipulación de datos.

Paso 3: El binario malicioso implementa lógica selectiva: responde con datos falsos solo a las IPs del DVN, mientras que a otros solicita la información real de la cadena, incluyendo infraestructura de monitoreo y exploradores. Esto envenena selectivamente la información, haciendo que la manipulación sea invisible para los sistemas de observabilidad. Desde fuera, la cadena fuente parece normal.

Paso 4: El DVN requiere consenso entre nodos envenenados y no comprometidos. Para resolver el conflicto, el atacante realiza un DDoS a los nodos sanos durante la ventana de ataque (10:20-11:40 PST), provocando la conmutación por fallo del DVN, que pasa a depender completamente de la infraestructura envenenada. Esto es crucial, pues los nodos sanos rechazarían respuestas contradictorias.

Paso 5: Con solo datos controlados por el atacante, se presenta un mensaje falsificado de LayerZero en Ethereum, con nonce 308, que no tiene evento de envío correspondiente en Unichain (que aún reporta nonce máximo 307).

Paso 6: El adaptador en Ethereum, tras verificar el mensaje, libera 116,500 rsETH a la dirección del atacante, que previamente había inyectado fondos vía Tornado Cash. Los tokens robados se dispersan en varias wallets, se usan en Aave, se intercambian por ETH y se cruzan a Arbitrum, consolidándose en direcciones controladas en Ethereum y Arbitrum.

Paso 7: El binario malicioso se autodestruye tras completar la operación, eliminando logs y archivos, dificultando la investigación posterior.

Paso 8: El atacante intenta repetir el proceso para robar otros 40,000 rsETH, pero es detenido cuando KelpDAO detecta anomalías y pausa los contratos en Ethereum y L2 [2].

Impacto más amplio

El daño va más allá del fallo inicial en el puente cross-chain $290M : el atacante depositó unos 89,567 rsETH (~$221M) en Aave en varias cadenas, con un LTV del 93% en WETH, aprovechando que Aave no distingue entre rsETH legítimo y envenenado, considerándolos completamente válidos. Esto provocó el congelamiento de reservas de WETH en Ethereum, Arbitrum, Base, Mantle y Linea, afectando a usuarios sin contacto con rsETH. La cascada de efectos muestra cómo un fallo en un puente puede amplificar a múltiples cadenas y mercados DeFi, evidenciando la fragilidad de la composabilidad.

El evento también plantea cuestiones sobre la operación descentralizada: LayerZero anunció que su DVN no firmará más aplicaciones configuradas como 1-de-1, señalando que la descentralización en la capa de protocolo no puede compensar configuraciones débiles en la capa de aplicación.

En la capa de cadena, el Consejo de Seguridad de Arbitrum realizó una acción de emergencia, congelando 30,766 ETH en Arbitrum One. Según BlockSec, esto se logró mediante una conversión forzada de estado en la cadena: el Consejo elevó temporalmente el contrato de inbox de Ethereum, inyectó un mensaje L1 sin firma simulando la presencia del atacante, y restauró el contrato original, sin necesidad de firma [4].

Este acto, aunque legal y coordinado con las autoridades, revela que las cadenas L2 mantienen un poder centralizado de intervención en emergencias: en teoría, cualquier activo en Arbitrum One puede ser movido por el Consejo mediante este mecanismo. La diferencia entre el modelo teórico y la confianza real es la principal fuente de riesgo.

Conclusión

Este incidente demuestra que la seguridad de los puentes entre cadenas no puede reducirse solo a la corrección del protocolo. La vulnerabilidad radica en la capa operativa, en infraestructura de validación fuera de la cadena, que debe ser tan segura como los valores que protege.

Tres medidas de mitigación, incluso por separado, habrían prevenido este ataque:

• Configuración con múltiples DVN independientes, que requiere consenso de varios validadores, haciendo que un solo DVN comprometido no sea suficiente para autorizar una transferencia.
• Selección de nodos RPC con capacidad de detección de fallos: si durante la ventana activa la cantidad de nodos disponibles cae abruptamente, esto debe activar alertas o detener operaciones, en lugar de continuar con menos nodos.
• Fortalecimiento de infraestructura RPC: la capacidad de reemplazar ejecutables en servidores RPC indica deficiencias en control de acceso. La infraestructura que obtiene el estado real de la cadena debe tener un nivel de seguridad comparable al de las firmas de los DVN.

En general, cualquier puente o protocolo cross-chain que dependa de pruebas fuera de la cadena debe auditar no solo los contratos inteligentes, sino toda la cadena de datos desde el evento en la fuente hasta la ejecución en destino. Cuando miles de millones dependen de infraestructura RPC, la confianza predeterminada en su fiabilidad ya no es válida.

Referencias

[1] LayerZero Labs, “Declaración sobre el incidente KelpDAO”, 20 de abril de 2026. https://x.com/LayerZero_Core/status/2046081551574983137

[5] KelpDAO, “Contexto adicional del 18 de abril”, 21 de abril de 2026. https://x.com/KelpDAO/status/2046332070277091807

[3] Arbitrum, “Acción de emergencia del Consejo de Seguridad”, 21 de abril de 2026. https://x.com/arbitrum/status/2046435443680346189

[1] LlamaRisk, “Informe del incidente rsETH”, 20 de abril de 2026. https://governance.aave.com/t/rseth-incident-report-april-20-2026/24580

[2] BlockSec, “Análisis del mecanismo de congelación del Consejo de Arbitrum”, 21 de abril de 2026. https://x.com/Phalcon_xyz/status/2046467830498173088

Otros incidentes de esta semana

Hyperbridge
El 13 de abril de 2026, Hyperbridge, un puente de mensajería cross-chain basado en Ethereum, fue atacado por falta de validación de entrada en la lógica de prueba MMR (Merkle Mountain Range), con una pérdida de aproximadamente $242K. La función MerkleMountainRange.VerifyProof[3][4] no fuerza la verificación de que leaf_index < leafCount, permitiendo al atacante falsificar pruebas cross-chain y ejecutar operaciones privilegiadas, incluyendo la acuñación de 1,000,000,000 de DOT.

[5] Contexto

Hyperbridge en Ethereum usa un modelo de validadores y planificadores para gestionar mensajes cross-chain. En Ethereum, el contrato HandlerV1 verifica la prueba contra un root almacenado; si la prueba es aceptada, distribuye el mensaje a un módulo destino, como TokenGateway.

TokenGateway es un módulo de gestión de activos privilegiados, que además soporta operaciones de gobernanza como creación, eliminación y gestión de administradores. Para activos puenteados con ERC6160Ext20, los administradores pueden transferir permisos de acuñación mediante changeAdmin(), y luego acuñar tokens con mint###(.

Esto hace que la seguridad del puente dependa de la correcta validación en HandlerV1. Si un mensaje falsificado pasa, el módulo receptor considerará la orden como legítima y actuará en consecuencia.

) Análisis de vulnerabilidad

El problema radica en el proceso de verificación en HandlerV1 (0x6c84ed…6d64). La función handlePostRequests() construye un leaf de MMR con los datos del atacante y llama a MerkleMountainRange.VerifyProof###(.

La función VerifyProof) solo comprueba si root == CalculateRoot( con los datos proporcionados, sin verificar que leaf.index < leafCount. Al establecer leafCount=1 y leaf_index=1, el atacante hace que CalculateRoot)( pase sin detectar la falsificación, ya que la prueba se valida contra un root que no incluye la orden falsa. Esto rompe la vinculación entre mensaje y prueba, permitiendo que cualquier carga útil pase como válida.

![])https://img-cdn.gateio.im/social/moments-b2403df3c2-75af16b47f-8b7abd-badf29(

Figura: fragmento de código de VerifyProof que omite la verificación de leaf_index

) Análisis del ataque

Este análisis se basa en la transacción 0x240aeb…1109 (.

Paso 1: El atacante, EOA 0xC513…F8E7, despliega en la misma transacción los contratos auxiliares 0x518A…8f26 y 0x31a1…ca9AB.

Paso 2: El contrato auxiliar 0x31a1…ca9AB envía una orden falsificada a través de HandlerV1, aprovechando que VerifyProof)( no verifica que leaf.index < leafCount. La orden falsa se excluye del cálculo del root, pero aún así coincide con el root histórico, por lo que se acepta.

Paso 3: La orden falsificada se distribuye a TokenGateway, que ejecuta changeAdmin, transfiriendo la administración de DOT al contrato auxiliar controlado por el atacante.

Paso 4: El contrato auxiliar acuña 1,000,000,000 de DOT.

Paso 5: El contrato intercambia los DOT en Odos Router V3 por 108.2 ETH.

Paso 6: El atacante transfiere los ETH a su cuenta EOA.

) Conclusión

Este incidente se debe a una verificación incorrecta en la lógica de prueba MMR, que no comprueba que leaf.index < leafCount. La omisión permite falsificar órdenes que no están incluidas en el root, pero que aún así pasan la validación por coincidencia histórica. La mitigación consiste en agregar una verificación explícita de que leaf.index < leafCount antes de validar la prueba.

Referencias

( BlockSec, “Análisis del ataque Hyperbridge”, 13 de abril de 2026. https://x.com/Phalcon_xyz/status/2043601549893738970

Dango
El 13 de abril de 2026, Dango, un DEX perpetuo construido sobre Cosmos AppChain, fue atacado por falta de verificación de símbolos, con una pérdida de aproximadamente $1.5M. La función replenish_insurance_fund)( usa is_non_zero)### en lugar de is_positive[1]( para verificar la entrada, permitiendo que un atacante proporcione un valor negativo de USD y transfiera fondos del fondo de seguros a su posición de garantía.

) Contexto

Dango es un DEX perpetuo en Cosmos AppChain, donde los usuarios depositan USDC como colateral y abren posiciones apalancadas en BTC, ETH y SOL mediante un libro de órdenes centralizado en cadena. Cada usuario tiene un saldo de garantía que se rastrea en la posición perpetua.

El fondo de seguros, que almacena USDC en la posición, cubre pérdidas en liquidaciones cuando el colateral no es suficiente para pagar la deuda. Sin un fondo de seguros, esas pérdidas se distribuyen entre los LP. Cualquier usuario puede donar a este fondo desde su cuenta.

Análisis de vulnerabilidad

El problema radica en que la función replenish_insurance_fund[1]( (0x90bc84…bea4f) no rechaza valores negativos. Tiene dos verificaciones:

• ensure!)amount.is_non_zero()(, que solo comprueba que el valor no sea cero, no que sea positivo.
• ensure!)user_state.margin >= amount###, que permite valores negativos si la garantía del usuario es mayor o igual a ese valor.

Tras estas verificaciones, la función realiza checked_sub_assign### y checked_add_assign(, que en el caso de amount negativo, incrementan la garantía del usuario y reducen el fondo de seguros, invirtiendo la lógica esperada.

![])https://img-cdn.gateio.im/social/moments-bfbc4f9ac0-5d013c5828-8b7abd-badf29(

Figura: función replenish_insurance_fund que no verifica signos

( Análisis del ataque

El atacante realiza las siguientes acciones:

Paso 1: Deposita 1 millón USDC para abrir una posición de garantía.

Paso 2: Llama a replenish_insurance_fund)) con amount = -1,500,000. La función acepta el valor negativo, transfiriendo fondos del fondo de seguros a su garantía.

Paso 3: Extrae toda la garantía, obteniendo $1.5M.

Figura: transacción de extracción de fondos robados

Fase 2:

En transacciones 2-8, el atacante usa transfer_remote() para cruzar los fondos a Ethereum, logrando transferir en total $410,000.

( Conclusión

El ataque se debe a que la función permite valores negativos sin verificar signos, invirtiendo la lógica de transferencia. La solución es usar una verificación estricta que solo acepte valores positivos, por ejemplo, reemplazando is_non_zero)( por is_positive)###.

Rhea Finance
El 16 de abril de 2026, Rhea Finance, en NEAR, sufrió un ataque a su protocolo de préstamos y margen, Burrowland, con una pérdida de aproximadamente $18.4M. La causa fue un fallo en la lógica de verificación en verify_token_out###(, que en medio de una operación de intercambio, sumaba incorrectamente los tokens de salida, permitiendo a un atacante construir rutas circulares y manipular los valores de salida percibidos, extrayendo fondos en exceso.

) Contexto

Burrowland en NEAR es un protocolo de préstamos y margen de código abierto. Permite abrir posiciones apalancadas en diferentes activos, usando token_c (colateral), token_d (deuda) y token_p (posición).

Para posiciones largas, los usuarios depositan token_c y toman prestado token_d, que luego intercambian por token_p en un DEX. La cantidad recibida de token_p debe reflejar aproximadamente el valor de token_d invertido.

Para posiciones cortas, hacen lo mismo pero en sentido inverso, creando exposición en corto.

Durante toda la vida de la posición, token_p está en custodia del protocolo y solo se puede cerrar para realizar ganancias o pérdidas, intercambiando token_p por token_d para pagar la deuda.

La apertura de posición se realiza mediante internal_margin_open_position(), que configura los parámetros y distribuye el préstamo a través del DEX.

Figura: función internal_margin_open_position

Antes de aceptar la posición, el protocolo evalúa varias condiciones:

• is_min_amount_out_reasonable() compara min_token_p_amount con la salida implícita de un oráculo Pyth para limitar el slippage.
• is_open_position_liquidatable() verifica que el valor de la posición y colateral no esté en riesgo de liquidación.
• is_open_position_forcecloseable###( comprueba que la cuenta no esté en quiebra.
• get_open_position_lr)( asegura que la relación token_d / token_c no supere el apalancamiento máximo.

Estas verificaciones usan min_token_p_amount, que aún no refleja cantidades reales, sino una estimación previa a la ejecución del intercambio. La precisión de estas verificaciones depende de que min_token_p_amount esté correctamente vinculada a los valores reales del DEX, lo cual debe hacerse en verify_token_out)(.

![])https://img-cdn.gateio.im/social/moments-5d0de6737a-27b31cb2f8-8b7abd-badf29###

Figura: verify_token_out y verificaciones de solvencia

( Análisis de vulnerabilidad

El problema está en verify_token_out)(. La función selecciona el último paso de intercambio y suma min_amount_out de todos los pasos que producen el mismo token_out, asumiendo que cada uno contribuye al total final. Esto es correcto en rutas simples, pero en rutas con ciclos (como A->B->A->B), los pasos intermedios se suman varias veces, incluso si su output se consume en pasos posteriores y nunca llega a la posición.

Por tanto, la suma de min_amount_out no refleja la cantidad real que el DEX devolverá, permitiendo que valores inflados pasen las verificaciones de solvencia y que la posición se abra con valores falsos.

![])https://img-cdn.gateio.im/social/moments-2cf6bed575-bf31deedff-8b7abd-badf29(

Figura: código de verify_token_out que omite la verificación de límites en los pasos intermedios

![])https://img-cdn.gateio.im/social/moments-1c4737e761-6f8a15577b-8b7abd-badf29(

Figura: lógica defectuosa en get_token_out que suma múltiples veces los outputs en rutas cíclicas

Al saltarse esta verificación, los valores inflados en min_token_p_amount se consideran reales en internal_margin_open_position)(, permitiendo que las verificaciones de solvencia se basen en datos falsos. Como resultado, se abren posiciones que parecen seguras pero en realidad no lo son, y se distribuyen fondos en el DEX en cantidades infladas.

Para evitar esto, los desarrolladores deben:

• Tratar min_amount_out como un valor no verificado, solo considerando la última etapa del intercambio o rechazando rutas cíclicas que reutilizan outputs anteriores.
• Establecer límites de slippage basados en oráculos, para que los valores declarados no puedan ser inflados unilateralmente.