Resumen semanal de incidentes de seguridad en Web3 | 13 – 19 de abril de 2026

Durante la semana pasada (2026/04/13 - 2026/04/19), BlockSec detectó y analizó cuatro incidentes de ataque, con pérdidas totales estimadas de aproximadamente $310M. La tabla a continuación resume estos incidentes, y los análisis detallados de cada caso se presentan en las subsecciones siguientes.

Destacado de la Semana: KelpDAO

Para un informe dedicado que cubra la cascada posterior al exploit, el mecanismo de recuperación on-chain de Arbitrum y las implicaciones más amplias de gobernanza, consulte: El Dilema de la Descentralización: Riesgo en Cascada y Poder de Emergencia en la Crisis de KelpDAO

Este incidente se destaca por su novedoso vector de ataque a nivel de infraestructura (envenenamiento de RPC contra el único DVN en lugar de explotación de contratos inteligentes), su impacto en cascada a través de múltiples cadenas mediante la componibilidad de DeFi, y las preguntas de gobernanza planteadas por la transición de estado forzada de Arbitrum para recuperar los fondos robados.

El 18 de abril de 2026, el puente LayerZero OFT de rsETH de KelpDAO fue explotado por aproximadamente $290M en un ataque atribuido a un actor patrocinado por un Estado, probablemente el Grupo Lazarus de Corea del Norte [1]. La causa raíz fue la configuración DVN 1-de-1 de KelpDAO, que redujo la verificación de mensajes entre cadenas a un único punto de fallo. El atacante envenenó la infraestructura RPC en la que confiaba el DVN de LayerZero Labs, obligándolo a atestiguar un mensaje entre cadenas fabricado que provocó que 116.500 rsETH fueran liberados en Ethereum sin ningún evento correspondiente del lado de la fuente en Unichain.

Antecedentes

LayerZero es un protocolo de mensajería entre cadenas construido sobre una arquitectura de seguridad modular. En su núcleo, la integridad de los mensajes entre cadenas es aplicada por Redes de Verificadores Descentralizados (DVN, por sus siglas en inglés), entidades fuera de la cadena responsables de verificar de forma independiente que un mensaje enviado en una cadena de origen realmente ocurrió antes de que sea ejecutado en la cadena de destino. Cada aplicación desplegada en LayerZero configura su propio esquema de DVN, incluyendo qué DVNs confiar, cuántos son requeridos y qué umbral de consenso debe alcanzarse. Esta modularidad otorga a las aplicaciones control total sobre su modelo de seguridad, pero también plena responsabilidad: una configuración débil no puede ser respaldada por el propio protocolo.

El rsETH de KelpDAO se despliega como un OFT (Token Fungible Omnichain) en LayerZero, con una ruta de puente que conecta Unichain (origen) y la red principal de Ethereum (destino). El estándar OFT permite que los tokens sean quemados en la cadena de origen y liberados desde un bloqueo en la cadena de destino, siendo el mensaje entre cadenas la única autorización para la liberación. El adaptador del lado de Ethereum (0x85d456...e98ef3) es responsable de liberar rsETH a los destinatarios una vez que un mensaje entre cadenas válido ha sido verificado y entregado. De manera crítica, KelpDAO configuró esta vía con una configuración DVN 1-de-1, designando a LayerZero Labs como el único verificador. Esto significa que una sola atestación de DVN era suficiente para autorizar cualquier liberación de tokens, sin necesidad de una segunda opinión.

Para llevar a cabo sus funciones de verificación, el DVN de LayerZero Labs consulta múltiples nodos RPC para confirmar que un evento de envío entre cadenas ocurrió realmente en la cadena de origen. Estos nodos RPC incluyen tanto infraestructura propia como proveedores externos, y el DVN se basa en sus respuestas colectivas antes de firmar una atestación. La integridad de este proceso depende de la suposición de que la mayoría de los nodos consultados devuelven datos verídicos.

Análisis de Vulnerabilidad

La vulnerabilidad es un fallo sistémico a nivel de infraestructura y configuración, compuesto por tres debilidades que se potencian entre sí.

En primer lugar, la configuración DVN 1-de-1 de KelpDAO eliminó toda redundancia en la capa de verificación. La postura de seguridad recomendada por LayerZero requiere explícitamente configuraciones multi-DVN con verificadores independientes, de modo que ningún DVN pueda autorizar unilateralmente un mensaje. Al depender únicamente del DVN de LayerZero Labs, KelpDAO aseguró que cualquier compromiso de ese único verificador sería suficiente para autorizar una liberación arbitraria de tokens.

En segundo lugar, el mecanismo de conmutación por error del DVN redirige las consultas de verificación a los nodos RPC que permanecen accesibles. Este diseño asume que la no disponibilidad de nodos es accidental en lugar de deliberada. Sin embargo, crea una condición en la que un atacante no necesita comprometer todas las fuentes de datos: tomando fuera de línea los nodos sanos mediante DDoS y teniendo nodos envenenados listos como única alternativa accesible, el atacante puede obtener control total sobre los datos que recibe el DVN.

En tercer lugar, reemplazar el ejecutable op-geth en los nodos RPC requirió acceso a nivel de SO a los servidores subyacentes. El vector de acceso inicial exacto no fue divulgado, pero comprometer dos nodos independientes en clústeres separados puede indicar una debilidad compartida en cómo se controlaba el acceso a estos servidores.

Juntas, estas tres condiciones formaron una cadena de ataque completa: la primera garantizó que no hubiera un DVN independiente para verificar el mensaje atestiguado, la segunda garantizó que el atacante pudiera controlar completamente los datos que recibía el único DVN, y la tercera proporcionó el punto de apoyo inicial que hizo posible la manipulación de datos. Ninguna debilidad por sí sola habría sido suficiente. Sin la configuración 1-de-1, un segundo DVN que consultara infraestructura independiente habría rechazado el mensaje falsificado. Sin el comportamiento de conmutación por error, los nodos sanos habrían superado en votos a los envenenados. Sin el compromiso del servidor, el atacante no habría tenido forma de inyectar datos falsificados en primer lugar.

Análisis del Ataque

El siguiente análisis se basa en la transacción 0x1ae232...4222 y el comunicado oficial del incidente de LayerZero Labs.

• Paso 1: El atacante obtuvo la lista de nodos RPC específicos en los que confiaba el DVN de LayerZero Labs. Esta lista constituía un objetivo de inteligencia de alto valor, porque conocer los nodos exactos permitió al atacante planificar una operación quirúrgica en lugar de un ataque de infraestructura amplio.

• Paso 2: El atacante obtuvo acceso de escritura a nivel de SO a dos de los nodos RPC y reemplazó los binarios op-geth en ejecución por versiones maliciosas. Se describió que estos dos nodos se ejecutaban en clústeres independientes sin conexión directa entre sí, lo que sugiere que el vector de acceso inicial involucró una dependencia de upstream compartida (por ejemplo, credenciales de despliegue comprometidas, un pipeline CI/CD o ingeniería social de un operador con acceso a ambos). LayerZero Labs no divulgó el método exacto de acceso inicial. Este paso fue el prerrequisito para toda manipulación de datos posterior.

• Paso 3: El binario op-geth malicioso implementó lógica de respuesta dirigida: devolvía datos de transacciones falsificados exclusivamente a la dirección IP del DVN, mientras servía el estado verdadero de la blockchain a todos los demás solicitantes, incluida la propia infraestructura de monitoreo de LayerZero, los exploradores de bloques y los servicios de escaneo. Este envenenamiento selectivo hizo que el ataque fuera invisible para todos los sistemas de observabilidad existentes; desde toda perspectiva externa, la cadena de origen parecía normal.

• Paso 4: El consenso interno del DVN requería acuerdo entre los nodos RPC envenenados y los no comprometidos. Para resolver este conflicto, el atacante realizó un DDoS a los nodos sanos restantes durante la ventana del ataque (10:20 a 11:40 AM PT), activando la lógica de conmutación por error del DVN y obligándolo a depender exclusivamente de la infraestructura envenenada. Este paso fue necesario porque, de lo contrario, los nodos sanos habrían devuelto datos verídicos que contradecían las respuestas falsificadas.

• Paso 5: Con el DVN recibiendo ahora únicamente datos controlados por el atacante, se presentó como válido un mensaje falsificado de LayerZero entre cadenas. El DVN atestiguó el nonce 308 en el endpoint de destino de Ethereum, un nonce que no tenía ningún evento de salida correspondiente en Unichain (confirmado porque el endpoint de origen seguía reportando un nonce de salida máximo de 307).

• Paso 6: El adaptador de rsETH del lado de Ethereum, al recibir un mensaje válidamente atestiguado, liberó 116.500 rsETH a la dirección destinataria del atacante (0x8b1b6c...0d3b), que había sido pre-financiada a través de Tornado Cash horas antes. Los tokens robados fueron inmediatamente dispersados en siete billeteras derivadas y liquidados a través de posiciones de colateral en Aave, intercambios directos de ETH y re-puenteo a Arbitrum, con los ingresos finales consolidándose en 0x5d3919...7ccc en Ethereum y un colector correspondiente en Arbitrum.

• Paso 7: El binario malicioso ejecutó una rutina de autodestrucción al finalizar, eliminándose a sí mismo junto con todos los registros locales y archivos de configuración. Esto obstaculizó significativamente la recuperación forense posterior al incidente e ilustra la sofisticación operativa del atacante.

• Paso 8: Un intento posterior del atacante de explotar la misma vía para obtener 40.000 rsETH adicionales (~$95M) fue bloqueado después de que KelpDAO detectó la anomalía y pausó todos los contratos relevantes en la red principal de Ethereum y en las L2 [2].

Impacto Más Amplio

El daño se extendió mucho más allá del exploit inicial del puente de $290M. El atacante depositó aproximadamente 89.567 rsETH (~$221M) en Aave en múltiples mercados, tomando prestado WETH con el LTV del 93% del modo-E [4]. Dado que Aave no podía distinguir rsETH legítimamente puenteado de tokens liberados mediante un mensaje falsificado, el colateral "envenenado" fue tratado como completamente válido. La congelación resultante de la reserva de WETH se propagó por Ethereum, Arbitrum, Base, Mantle y Linea, afectando a usuarios que no tenían ninguna exposición a rsETH en absoluto. Esta propagación en cascada, desde un único fallo de configuración de puente hasta la disrupción de mercados de préstamos en múltiples cadenas, ilustra cómo la componibilidad de DeFi amplifica tanto el alcance como el coste de un único punto de fallo.

Las secuelas plantearon preguntas igualmente importantes sobre la realidad operativa de la descentralización. LayerZero Labs anunció que su DVN ya no firmará mensajes para aplicaciones que utilicen configuraciones 1-de-1 [1], lo que implica que la descentralización a nivel de protocolo por sí sola no puede compensar las debilidades de configuración a nivel de aplicación.

A nivel de cadena, el Consejo de Seguridad de Arbitrum ejecutó una acción de emergencia para congelar 30.766 ETH en poder del atacante en Arbitrum One. Tal como analizó BlockSec [5], esto se logró mediante una transición de estado forzada a nivel de cadena: el Consejo de Seguridad actualizó temporalmente el contrato de bandeja de entrada de Ethereum, inyectó un mensaje L1-a-L2 sin firma que suplantaba la dirección del atacante y restauró la implementación original, todo sin requerir la firma del titular [3].

Esta acción fue un ejercicio legítimo de poderes de emergencia definidos por la gobernanza, realizado de forma transparente y en coordinación con las fuerzas del orden. Sin embargo, también demuestra que las cadenas L2 conservan capacidades de intervención centralizadas por diseño: cualquier activo en Arbitrum One puede, en principio, ser movido por el Consejo de Seguridad a través del mismo mecanismo. La brecha entre el modelo de confianza teórico de un sistema y su límite de confianza real es, como muestra este incidente en cada capa, donde residen los riesgos más significativos.

Conclusión

Este incidente demuestra que la seguridad de los puentes no puede reducirse únicamente a la corrección del protocolo. El propio protocolo LayerZero funcionó según lo diseñado; la vulnerabilidad existía enteramente en la capa operativa por encima de él. La lección principal es que la infraestructura de verificación fuera de la cadena forma parte del límite de confianza, y su postura de seguridad debe estar a la altura del valor que protege.

Tres medidas de mitigación habrían prevenido individualmente este resultado:

• Configuración multi-DVN: Requerir consenso entre múltiples DVNs independientes habría hecho que el compromiso de un solo DVN fuera insuficiente para autorizar un mensaje, independientemente de cuán completamente hubiera sido engañado ese DVN.

• Selección de RPC consciente de la conmutación por error: Una caída repentina en los nodos accesibles durante una ventana de verificación activa debería tratarse como una posible señal de ataque en lugar de un evento de disponibilidad rutinario. Las implementaciones de DVN deberían detenerse o emitir alertas en lugar de continuar con un conjunto reducido de nodos.

• Fortalecimiento de la infraestructura RPC: La capacidad de reemplazar un ejecutable en ejecución en un nodo RPC de producción indica controles de acceso insuficientes en los servidores subyacentes. La infraestructura de la que dependen los DVNs para obtener la verdad fundamental de la cadena de origen debería estar sujeta al mismo límite de seguridad que las propias instancias de firma de DVN.

De manera más amplia, cualquier puente o protocolo entre cadenas que dependa de atestaciones fuera de la cadena debería auditar no solo la capa de contratos inteligentes, sino la tubería de datos completa desde el evento en la cadena de origen hasta la ejecución en la cadena de destino. La suposición de que la infraestructura RPC es confiable por defecto ya no es sostenible cuando cientos de millones de dólares dependen de ella.

Referencias

[1] LayerZero Labs, "Comunicado del Incidente de KelpDAO", 20 de abril de 2026. https://x.com/LayerZero_Core/status/2046081551574983137

[2] KelpDAO, "Incidente del 18 de abril: Contexto Adicional", 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

[4] LlamaRisk, "Informe del Incidente de rsETH", 20 de abril de 2026. https://governance.aave.com/t/rseth-incident-report-april-20-2026/24580

[5] BlockSec, "Análisis del Mecanismo de Congelación del Consejo de Seguridad de Arbitrum", 21 de abril de 2026. https://x.com/Phalcon_xyz/status/2046467830498173088

Más Incidentes Esta Semana

Rhea Finance

El 16 de abril de 2026, Burrowland, un protocolo de préstamos y trading con margen en NEAR bajo Rhea Finance, fue explotado por aproximadamente $18.4M debido a un fallo en la lógica de negocio en su módulo de trading con margen. Al abrir una posición apalancada, el protocolo depende de verify_token_out() para validar la producción esperada del intercambio antes de aceptar la posición. Sin embargo, esta función acumulaba incorrectamente cantidades de token_out de pasos intermedios del intercambio cuando el token coincidía con el token de salida final, sin tener en cuenta el hecho de que estas cantidades intermedias eran posteriormente reutilizadas como token_in. El atacante desplegó tokens y pools falsos, luego construyó una ruta de intercambio circular que infló la cantidad de salida percibida y superó las verificaciones de solvencia, drenando aproximadamente $18.4M del protocolo.

Antecedentes

Burrowland es un protocolo de código abierto de préstamos y trading con margen en NEAR. Además de la funcionalidad estándar de suministro y préstamo, admite trading con margen e introduce tres variables clave para representar la posición apalancada de un usuario: token_c (colateral), token_d (activo de deuda) y token_p (activo de posición).

Para una posición larga, el usuario deposita token_c como colateral y toma prestado token_d con un apalancamiento elegido (por ejemplo, 5x). El token_d prestado luego se intercambia en un DEX por token_p, el activo al que el usuario desea exposición. En condiciones normales, el valor del token_p recibido es aproximadamente igual al valor del token_d gastado. El protocolo custodia token_p en nombre del usuario, mientras registra el token_d prestado como deuda.

Para una posición corta, el usuario deposita igualmente token_c y toma prestado token_d (el activo que desea ponerse corto) con apalancamiento. El token_d prestado se intercambia por otro activo (token_p), tomando efectivamente una exposición corta al token_d. Nuevamente, se espera que el intercambio preserve el valor bajo condiciones normales de mercado.

A lo largo del ciclo de vida de la posición, token_p permanece bajo custodia dentro del protocolo y el usuario no puede retirarlo directamente. La posición debe cerrarse para realizar ganancias o pérdidas, momento en el que token_p se intercambia nuevamente por token_d para pagar la deuda.

La apertura de una posición de margen es manejada por internal_margin_open_position(), que configura los parámetros de la posición y despacha el préstamo al DEX.

Antes de que el protocolo acepte una nueva posición, evalúa cuatro protecciones en secuencia: is_min_amount_out_reasonable() verifica el min_token_p_amount declarado por el usuario con respecto a la producción de intercambio implícita por el oráculo de Pyth para limitar el deslizamiento, is_open_position_liquidatable() verifica que el valor esperado de la posición y el colateral supere la línea de liquidación, is_open_position_forcecloseable() verifica que la cuenta no esté ya insolvente sobre el papel, y get_open_position_lr() hace cumplir que el valor de token_d / token_c no exceda la tasa de apalancamiento máxima.

Las cuatro verificaciones usan min_token_p_amount como el valor del activo de posición, porque el intercambio aún no se ha ejecutado y no hay una cantidad realizada para usar. La corrección de cada compuerta depende, por tanto, de que min_token_p_amount esté vinculado a lo que el DEX entregará realmente. Ese vínculo es exactamente lo que verify_token_out(), implementado a través de RefV1TokenReceiverMessage::get_token_out(), se supone que debe hacer cumplir en el mensaje de intercambio que envía el usuario.

Análisis de Vulnerabilidad

El fallo está dentro de verify_token_out(). La función selecciona el token_out del último paso de intercambio como el token de salida final, luego suma el min_amount_out declarado de cada paso de intercambio que produce el mismo token, bajo la suposición de que cada producción de ese tipo contribuye a la salida final. Esto es correcto para un intercambio genuino de múltiples rutas (ruta dividida), pero no excluye los pasos cuyo token_out es consumido inmediatamente como el token_in del siguiente paso. Una ruta de ida y vuelta como A->B->A->B hace que cada paso ->B sea contado en la suma aunque su salida se gaste en el siguiente paso B->A y nunca llegue a Burrowland. El min_amount_out sumado que aprueba verify_token_out() ya no representa lo que el DEX devolverá realmente.

Una vez que se elude verify_token_out(), el min_token_p_amount inflado es tratado como verdad absoluta en todo internal_margin_open_position(). Cada compuerta de solvencia que debía detener una apertura insegura calcula contra un número fabricado, por lo que la posición es aceptada y el protocolo despacha el token_d prestado al DEX con el mensaje de intercambio circular adjunto.

Análisis del Ataque

El siguiente análisis se basa en la transacción GcXEKm...fnFT.

Fase 1: Despliegue de Tokens y Pools Falsos

El atacante desplegó tres tokens falsos y creó cinco pools falsos.

1. IDs de Tokens Falsos:

   1. Falso1: 31623e1d98275d2b0db4f50e102f6bf40877c1345e06e4ca6727f58c89564bb2

   2. Falso2: 6a28e3d3c7af1415ec22c6264013e1138bab00f85b8b6055d882d7d46afdf49b

   3. Falso3: e081e03daf58f5bb04cf95a03017e58449b76e704f1974771d7e3bd52835b6e5

2. IDs de Pools Falsos:

   1. Zec-Falso1: 7509

   2. Falso1-Falso2: 7510

   3. USDC-Falso2: 7511

   4. Falso2-Falso3: 7512

   5. Falso3-USDC: 7513

Fase 2: Apertura de Posición de Margen

• Paso 1: Usando la función de trading con margen de Burrowland, el atacante abrió una posición apalancada con un activo legítimamente valioso como token_c y un activo de reserva real como token_d, adjuntando un mensaje de intercambio cuya lista de acciones es una ruta de ida y vuelta A->B->A->B enrutada completamente a través de los pools controlados por el atacante de la Fase 1.

• Paso 2: Dado que verify_token_out() suma min_amount_out en todos los pasos cuyo token_out coincide con la salida terminal, la ruta de ida y vuelta permitió al atacante inflar el min_token_p_amount declarado a un valor arbitrario.

• Paso 3: El min_token_p_amount inflado superó todas las verificaciones de salud al momento de apertura en internal_margin_open_position(), por lo que la posición fue aceptada y el protocolo despachó token_d a Ref-Finance.

• Paso 4: El intercambio circular devolvió solo una cantidad mínima de token_p; on_open_trade_return() lo registró sin ninguna re-verificación, dejando la posición insolvente desde su creación.

• Paso 5: El token_d prestado se depositó en los pools controlados por el atacante a lo largo de la ruta; el atacante lo extrajo mediante remove_liquidity().

• Paso 6: Dado que el préstamo está apalancado, el token_d retirado vale más que el token_c depositado. La diferencia es ganancia neta por ciclo, y la deuda incobrable se fuerza al cierre en protocol_debts. El atacante repitió la construcción hasta drenar aproximadamente $18.4M.

Conclusión

Este incidente fue causado por un fallo en la lógica de negocio en la ruta de apertura de margen de Burrowland. La función RefV1TokenReceiverMessage::get_token_out() agregó incorrectamente salidas intermedias cuando coincidían con el token final, asumiendo que estas cantidades permanecerían como salida final. Sin embargo, las rutas de intercambio circulares rompen esta suposición, ya que estos tokens pueden ser reutilizados y consumidos dentro de la ruta. Como resultado, el min_token_p_amount calculado puede ser inflado artificialmente, haciendo que todas las verificaciones de solvencia posteriores dependan de un valor incorrecto y permitiendo que las posiciones se abran contra un estado de salud fabricado sin validar la cantidad realmente recibida.

Para contratos de trading con margen en producción, los desarrolladores deberían:

• Tratar el min_amount_out declarado por el usuario como entrada no verificada, y tomar solo el min_amount_out del último salto o rechazar explícitamente las rutas de intercambio que reutilicen un token_out producido previamente (sin ciclos a través del objetivo).

• Limitar el deslizamiento declarado con un límite inferior y superior contra la producción de intercambio implícita por el oráculo, de modo que un atacante no pueda inflar unilateralmente el valor declarado para eludir los predicados de solvencia.

Hyperbridge

El 13 de abril de 2026, Hyperbridge, un puente de mensajería entre cadenas en Ethereum, fue explotado por aproximadamente $242K debido a la ausencia de validación de entrada en la lógica de verificación de pruebas MMR (Merkle Mountain Range). La función MerkleMountainRange.VerifyProof() no hacía cumplir que leaf_index < leafCount, lo que permitió al atacante falsificar una prueba entre cadenas y realizar acciones privilegiadas, incluida la acuñación de 1.000.000.000 tokens DOT.

Antecedentes

Hyperbridge utiliza un modelo de verificador y despachador del lado de Ethereum para mensajes entre cadenas. En Ethereum, el contrato HandlerV1 valida las pruebas proporcionadas contra el overlayRoot almacenado, y si la prueba es aceptada, despacha el mensaje a módulos de destino como el contrato TokenGateway.

El contrato TokenGateway es un módulo privilegiado de gestión de activos. Además del puenteo normal de activos, también admite acciones de estilo de gobernanza como la creación de activos, la eliminación del registro y la gestión de administradores. Para los activos puenteados implementados como ERC6160Ext20, el administrador puede transferir directamente la autoridad de acuñación llamando a la función changeAdmin(), y el nuevo administrador puede entonces acuñar suministro arbitrario mediante la función mint().

Esto significa que la seguridad de todo el puente de activos depende de la corrección de la ruta de verificación de pruebas en HandlerV1. Si un mensaje falsificado puede pasar la verificación, los módulos posteriores tratarán las cargas útiles controladas por el atacante como instrucciones auténticas entre cadenas.

Análisis de Vulnerabilidad

El problema central reside en el flujo de verificación de pruebas MMR en el contrato HandlerV1 (0x6c84ed...6d64). La función de entrada handlePostRequests() primero construye MmrLeaf(leaf.kIndex, leaf.index, commitment) basándose en las entradas proporcionadas por el atacante. Luego, se invoca MerkleMountainRange.VerifyProof() para realizar la validación de la prueba.

MerkleMountainRange.VerifyProof(root, request.proof.multiproof, leaves, request.proof.leafCount)

Sin embargo, VerifyProof() solo verifica si root == CalculateRoot(proof, leaves, mmrSize) y no valida que cada leaf.index esté dentro del rango (es decir, leaf.index < leafCount). Al elegir leafCount = 1 y leaf_index = 1, el atacante hace que CalculateRoot() omita el plegado del compromiso de la solicitud falsificada en la raíz calculada, devolviendo la raíz del pico directamente. Esto rompe el vínculo mensaje-prueba y permite que cargas útiles arbitrarias pasen como válidas contra un overlayRoot histórico.

Análisis del Ataque

El siguiente análisis se basa en la transacción 0x240aeb...1109 [1].

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

• Paso 2: El contrato auxiliar 0x31a1...ca9AB envió una solicitud falsificada a través de la ruta de verificación vulnerable en HandlerV1. Dado que VerifyProof() no rechazó el leaf_index fuera de rango, el compromiso de la solicitud falsificada fue omitido del cálculo de la raíz, pero la prueba igualmente coincidió con un overlayRoot histórico.

• Paso 3: Después de que el mensaje falsificado fue aceptado, HandlerV1 lo despachó a TokenGateway, ejecutando la acción ChangeAssetAdmin. Esto cambió el administrador del token DOT al contrato auxiliar controlado por el atacante 0x31a1...ca9AB.

• Paso 4: El contrato auxiliar acuñó 1.000.000.000e18 tokens DOT.

• Paso 5: El contrato auxiliar intercambió los tokens DOT recién acuñados por 108.2 ETH a través de Odos Router V3.

• Paso 6: El atacante transfirió 108.2 ETH a su cuenta EOA.

Conclusión

Este incidente fue causado por una validación de prueba incorrecta en la lógica de verificación MMR de Hyperbridge. Dado que no se hacía cumplir leaf_index < leafCount, el atacante podía falsificar un mensaje cuyo compromiso nunca fue incluido realmente en la raíz calculada, pero aun así pasaba la verificación contra una raíz de estado histórica. Las medidas de mitigación deben hacer cumplir verificaciones estrictas de límites como leaf_index < leafCount antes de la verificación de pruebas.

Referencias

[1] BlockSec, "Análisis del Ataque a Hyperbridge", 13 de abril de 2026. https://x.com/Phalcon_xyz/status/2043601549893738970

Dango

El 13 de abril de 2026, Dango, un DEX de futuros perpetuos construido como una AppChain de Cosmos, fue explotado por aproximadamente $1.5M debido a una verificación de signo faltante. La función replenish_insurance_fund() usaba is_non_zero() en lugar de is_positive() para validar el monto de entrada, lo que permitió al atacante proporcionar un UsdValue negativo y drenar el fondo de seguro hacia su posición de margen.

Antecedentes

Dango es un DEX de futuros perpetuos construido como una AppChain de Cosmos. Los usuarios depositan USDC como colateral en el contrato de perpetuos y abren posiciones largas o cortas apalancadas en activos como BTC, ETH y SOL a través de un Libro de Órdenes de Límite Central (CLOB) on-chain. El saldo de colateral de cada usuario se rastrea como una cuenta de margen dentro del contrato de perpetuos.

Para proteger a los proveedores de liquidez (LP) de pérdidas por deudas incobrables, el protocolo mantiene un fondo de seguro: una reserva de USDC mantenida dentro del contrato de perpetuos que cubre cualquier déficit cuando el colateral de una posición liquidada es insuficiente para pagar completamente su deuda. Sin él, tales déficits serían socializados directamente entre los LP. Cualquier usuario podía contribuir margen de su cuenta de perpetuos al fondo de seguro.

Análisis de Vulnerabilidad

La causa raíz reside en la función replenish_insurance_fund() del contrato 0x90bc84...bea4f, que no rechaza montos de entrada negativos. La función tiene dos guardas, pero ninguna detiene un amount negativo:

1. ensure!(amount.is_non_zero()) verifica que el monto no sea cero, pero no verifica que sea positivo.
2. ensure!(user_state.margin >= amount) verifica que el usuario tenga margen suficiente, pero cualquier margen positivo satisface >= número_negativo.

Con ambas guardas superadas, la función ejecuta user_state.margin.checked_sub_assign(amount) y state.insurance_fund.checked_add_assign(amount). Cuando amount es negativo, restarlo aumenta el margen del usuario, y sumarlo disminuye el fondo de seguro, revirtiendo completamente el flujo de fondos previsto.

Análisis del Ataque

Transacciones:

Fase 1:

En Tx 1, el atacante realizó los siguientes pasos para drenar activos del fondo de seguro de Dango:

• Paso 1: El atacante abrió una posición de margen depositando 1e6 USDC. Este fue un requisito previo para invocar replenish_insurance_fund().

• Paso 2: El atacante invocó replenish_insurance_fund() con un amount negativo (es decir, -1500000). Debido a la validación incorrecta, el amount negativo fue aceptado, drenando activos del fondo de seguro hacia la posición de margen del atacante.

• Paso 3: El atacante retiró todos los activos de la posición de margen, obteniendo $1.500.000 de USDC.

Fase 2:

En Tx 2-8, el atacante invocó transfer_remote() para puentear los activos robados a Ethereum. Como resultado, $410.000 de USDC fueron puenteados a Ethereum.

Conclusión

La esencia de este ataque es un tipo de entero con signo usado en un contexto sin signo sin una guarda de signo. El tipo UsdValue es con signo por diseño (el PnL de perpetuos puede ser negativo), pero la vía de donación al fondo de seguro solo tiene sentido para contribuciones positivas. Usar is_non_zero() en lugar de is_positive() dejó una brecha de una palabra que permitió a cualquier llamante invertir la dirección del flujo de fondos, drenando USDC del fondo de seguro hacia su propio margen. El atacante ejecutó todo el ataque en una sola transacción (depositar $1, drenar $1.5M, retirar $1.500.001) y luego puenteó los fondos lentamente. El límite de tasa del puente fue el único mecanismo que limitó el daño: sin él, el total de ~$1.5M habría sido puenteado irrecuperablemente a Ethereum.

Sobre BlockSec

BlockSec es un proveedor integral de seguridad blockchain y cumplimiento normativo en criptomonedas. Desarrollamos productos y servicios que ayudan a los clientes a realizar auditorías de código (incluyendo contratos inteligentes, blockchain y billeteras), interceptar ataques en tiempo real, analizar incidentes, rastrear fondos ilícitos y cumplir con las obligaciones AML/CFT, a lo largo de todo el ciclo de vida de los protocolos y plataformas.

BlockSec ha publicado múltiples artículos de seguridad blockchain en conferencias de prestigio, ha reportado varios ataques de día cero en aplicaciones DeFi, ha bloqueado múltiples hackeos para rescatar más de 20 millones de dólares y ha asegurado miles de millones en criptomonedas.

• Sitio web oficial: https://blocksec.com/

• Cuenta oficial de Twitter: https://twitter.com/BlockSecTeam

• 🔗 Servicio de Auditoría de BlockSec : Enviar una solicitud

• 🔗 Phalcon Security APP: Reservar una demo

• 🔗 Phalcon Compliance