Resumen semanal de incidentes de seguridad 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 en 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 cubre la cascada post-exploit, el mecanismo de recuperación en cadena de Arbitrum y las implicaciones de gobernanza más amplias, consulte: El Dilema de la Descentralización: Riesgo en Cascada y Poderes 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 composabilidad 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 OFT de LayerZero 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, forzándolo a atestiguar un mensaje entre cadenas fabricado que causó la liberación de 116,500 rsETH en Ethereum sin ningún evento correspondiente del lado de origen 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 (DVNs), entidades fuera de cadena responsables de verificar de forma independiente que un mensaje enviado en una cadena de origen realmente ocurrió antes de que se ejecute en la cadena de destino. Cada aplicación que se despliega en LayerZero configura su propia configuración de DVN, incluyendo qué DVNs confiar, cuántos se requieren y qué umbral de consenso debe cumplirse. Esta modularidad otorga a las aplicaciones control total sobre su modelo de seguridad, pero también plena responsabilidad: el propio protocolo no puede compensar una configuración débil.

El rsETH de KelpDAO está desplegado como un OFT (Token Fungible Omnicadena) 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, con el mensaje entre cadenas como ú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. Fundamentalmente, 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 requerir una segunda opinión.

Para realizar sus tareas de verificación, el DVN de LayerZero Labs consulta múltiples nodos RPC para confirmar que un evento de envío entre cadenas realmente ocurrió en la cadena de origen. Estos nodos RPC incluyen tanto infraestructura propia como proveedores externos, y el DVN depende de 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 componen 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 individual pueda autorizar unilateralmente un mensaje. Al depender únicamente del DVN de LayerZero Labs, KelpDAO garantizó 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 enruta las consultas de verificación a los nodos RPC que permanecen accesibles. Este diseño asume que la indisponibilidad de los 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: al desconectar los nodos saludables mediante DDoS y tener 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 sistema operativo en los servidores subyacentes. El vector de acceso inicial exacto no fue revelado, pero comprometer dos nodos independientes en clústeres separados puede indicar una debilidad compartida en la forma en que se controló el acceso a estos servidores.

Juntas, estas tres condiciones formaron una cadena de ataque completa: la primera aseguró que no hubiera un DVN independiente para verificar el mensaje atestiguado, la segunda aseguró 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 individual 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 saludables habrían superado en votos a los envenenados. Sin el compromiso del servidor, el atacante no habría tenido manera de inyectar datos falsificados en primer lugar.

Análisis del Ataque

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

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

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

• Paso 3: El binario malicioso op-geth 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, incluyendo la propia infraestructura de monitoreo de LayerZero, exploradores de bloques y servicios de análisis. Este envenenamiento selectivo hizo que el ataque fuera invisible para todos los sistemas de observabilidad existentes; desde cualquier perspectiva externa, la cadena de origen parecía normal.

• Paso 4: El consenso interno del DVN requería acuerdo entre todos los nodos RPC envenenados y no comprometidos. Para resolver este conflicto, el atacante realizó un DDoS sobre los nodos saludables 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 forzándolo a depender exclusivamente de la infraestructura envenenada. Este paso fue necesario porque de lo contrario los nodos saludables habrían devuelto datos verídicos que contradecían las respuestas falsificadas.

• Paso 5: Con el DVN recibiendo ahora solo datos controlados por el atacante, un mensaje entre cadenas de LayerZero fabricado fue presentado como válido. 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 por el endpoint de origen que 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 a través de 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 recolector correspondiente en Arbitrum.

• Paso 7: El binario malicioso ejecutó una rutina de autodestrucción al completarse, eliminándose a sí mismo junto con todos los registros locales y archivos de configuración. Esto dificultó 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 detectara la anomalía y pausara todos los contratos relevantes en la red principal de Ethereum y en las L2s [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 a través de múltiples mercados, tomando prestado WETH con el LTV del 93% del modo E [4]. Dado que Aave no podía distinguir el rsETH legítimamente puenteado de los 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. Esta propagación en cascada, desde un único fallo de configuración de puente hasta la disrupción de mercados de préstamos multicadena, ilustra cómo la composabilidad de DeFi amplifica tanto el alcance como el costo 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 usen 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 que el atacante tenía en Arbitrum One. Según el análisis de BlockSec [5], esto se logró mediante una transición de estado forzada a nivel de cadena: el Consejo de Seguridad actualizó temporalmente el contrato inbox de Ethereum, inyectó un mensaje L1-a-L2 sin firmar 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 los 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 retienen capacidades de intervención centralizada 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 demuestra este incidente en cada capa, donde residen los riesgos más trascendentes.

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 completamente en la capa operativa por encima de él. La lección fundamental es que la infraestructura de verificación fuera de cadena es parte del límite de confianza, y su postura de seguridad debe estar a la altura del valor que protege.

Tres mitigaciones 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 único 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 señal de posible ataque en lugar de un evento de disponibilidad rutinario. Las implementaciones de DVN deberían detenerse o alertar en lugar de continuar con un conjunto reducido de nodos.

• Hardening 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 la verdad fundamental de la cadena de origen debería estar sujeta al mismo límite de seguridad que las propias instancias de firma del DVN.

De manera más amplia, cualquier puente o protocolo entre cadenas que dependa de atestaciones fuera de cadena debería auditar no solo la capa de contratos inteligentes, sino toda la cadena de datos 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, "Declaración sobre el 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 el resultado esperado del intercambio antes de aceptar la posición. Sin embargo, esta función acumulaba incorrectamente los montos de token_out de los pasos intermedios del intercambio cada vez que el token coincidía con el token de salida final, sin tener en cuenta el hecho de que estos montos intermedios se reutilizaban posteriormente como token_in. El atacante desplegó tokens y pools falsos, luego construyó una ruta de intercambio circular que infló el monto de salida percibido 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 se intercambia entonces en un DEX por token_p, el activo al que el usuario quiere exposición. En condiciones normales, el valor del token_p recibido es aproximadamente igual al valor del token_d gastado. El protocolo mantiene 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 quiere ponerse en corto) con apalancamiento. El token_d prestado se intercambia por otro activo (token_p), tomando efectivamente una exposición corta a 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 de vuelta 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 de forma cruzada el min_token_p_amount declarado por el usuario con la salida 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 en papel, y get_open_position_lr() aplica que el valor de token_d / token_c no exceda la tasa de apalancamiento máxima.

Todas 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 un monto realizado para usar. La corrección de cada compuerta depende por lo tanto de que min_token_p_amount esté vinculado a lo que el DEX realmente entregará. Ese vínculo es exactamente lo que se supone que verify_token_out(), implementado mediante RefV1TokenReceiverMessage::get_token_out(), debe aplicar en el mensaje de intercambio que el usuario envía.

Análisis de Vulnerabilidad

El fallo está dentro de verify_token_out(). La función toma el token_out del último paso del intercambio como el token de salida final, luego suma el min_amount_out declarado de cada paso del intercambio que produce el mismo token, bajo la suposición de que cada una de estas producciones 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 se consume 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 hacia 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 realmente devolverá.

Una vez que se omite verify_token_out(), el min_token_p_amount inflado se trata como verdad fundamental en todo internal_margin_open_position(). Cada compuerta de solvencia que debía detener una apertura insegura computa 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 en el momento de la 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 reverificación, dejando la posición insolvente desde su creación.

• Paso 5: El token_d prestado se depositó dentro de 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 irrecuperable se cierra forzosamente 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() agregaba incorrectamente las salidas intermedias cada vez que coincidían con el token final, asumiendo que estos montos permanecerían como salida final. Sin embargo, las rutas de intercambio circulares rompen esta suposición, ya que estos tokens pueden reutilizarse y consumirse dentro de la ruta. Como resultado, el min_token_p_amount calculado puede inflarse 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 el monto realmente recibido.

Para los 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 re-consumen un token_out producido previamente (sin ciclos a través del objetivo).

• Delimitar el deslizamiento declarado tanto con un límite inferior como con un límite superior frente a la salida 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 falta de validación de entrada en la lógica de verificación de pruebas MMR (Merkle Mountain Range). La función MerkleMountainRange.VerifyProof() no aplicaba que leaf_index < leafCount, lo que permitió al atacante falsificar una prueba entre cadenas y realizar acciones privilegiadas, incluyendo 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 los 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 cancelació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 luego acuñar un 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 superar 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 se encuentra 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 suministradas 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 EOA atacante 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 aún coincidía 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 leaf_index < leafCount no fue aplicado, el atacante pudo falsificar un mensaje cuyo compromiso nunca fue realmente incluido en la raíz calculada, pero aún así superó la verificación contra una raíz de estado histórica. Las mitigaciones deben aplicar verificaciones estrictas de límites como leaf_index < leafCount antes de la verificación de la prueba.

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() usó 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 perps 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) en cadena. El saldo de colateral de cada usuario se rastrea como una cuenta de margen dentro del contrato de perps.

Para proteger a los proveedores de liquidez (LPs) de las pérdidas por deudas incobrables, el protocolo mantiene un fondo de seguro: una reserva de USDC mantenida dentro del contrato de perps que cubre cualquier déficit cuando el colateral de una posición liquidada es insuficiente para pagar completamente su deuda. Sin él, dichos déficits se socializarían directamente sobre los LPs. Cualquier usuario podía contribuir margen de su cuenta de perps 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 guardias, 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 guardias 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, invirtiendo 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. Esto fue un prerrequisito 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 fue puenteado a Ethereum.

Conclusión

La esencia de este ataque es un tipo de entero con signo usado en un contexto sin signo sin una guardia de signo. El tipo UsdValue es con signo por diseño (el PnL de perps 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 sola 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ó el ataque completo 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 ~$1.5M completo habría sido puenteado irreversiblemente a Ethereum.

Acerca de BlockSec

BlockSec es un proveedor integral de seguridad blockchain y cumplimiento cripto. 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 protocolos y plataformas.

BlockSec ha publicado múltiples artículos de seguridad blockchain en conferencias de prestigio, reportado varios ataques de día cero en aplicaciones DeFi, bloqueado múltiples hackeos para rescatar más de 20 millones de dólares y 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

• 🔗 Aplicación Phalcon Security: Reservar una demo

• 🔗 Phalcon Compliance