Resumen semanal de incidentes de seguridad Web3 | 6 – 12 de abril de 2026

Durante la semana pasada (2026/04/06 - 2026/04/12), BlockSec detectó y analizó cuatro incidentes de ataque, con pérdidas totales estimadas de aproximadamente $928.6K. La siguiente tabla resume estos incidentes, y los análisis detallados de cada caso se proporcionan en las subsecciones siguientes.

*El incidente de Denaria no fue cubierto en el informe de la semana pasada y se incluye aquí por completitud.

A partir de esta semana, destacamos un incidente al comienzo de cada informe. La selección no se basa necesariamente en el monto de las pérdidas — puede elegirse por su diseño de protocolo novedoso, técnica de ataque ingeniosa o lecciones más amplias para la comunidad.

Destacado de la Semana: Incidente Denaria

El DEX perpetuo Denaria introdujo mecanismos de contabilidad novedosos respaldados por una lógica de código compleja. Sin embargo, una refactorización posterior a la auditoría introdujo una asimetría de redondeo que podía producir un caso límite sutil, un valor negativo, que finalmente alcanzó una conversión insegura y permitió una extracción de valor astronómica.

El 5 de abril de 2026, el DEX perpetuo de Denaria en Linea fue explotado por aproximadamente $165.6K en pérdidas. La causa raíz fue dos fallas combinadas en getLpLiquidityBalance(): una refactorización posterior a la auditoría en la contabilidad de saldo LP introdujo una asimetría de redondeo que podía producir un valor intermedio ligeramente negativo, y una conversión insegura de int256 a uint256 envolvió silenciosamente ese valor negativo en un entero sin signo casi máximo en lugar de revertir. El atacante explotó esto mediante un depósito LP unilateral y una operación larga, luego retiró PnL artificialmente inflado del vault.

Contexto

Denaria es un DEX perpetuo en Linea construido alrededor de un AMM virtual dinámico. Separa el trading y la liquidación en dos componentes. El mercado PerpPair gestiona las posiciones de los usuarios y la contabilidad de LP, mientras que el Vault mantiene el colateral y liquida el PnL realizado.

La propiedad de LP en PerpPair no está representada por un saldo de tokens explícito. En cambio, el protocolo reconstruye el estado de cada LP a partir de una matriz de contabilidad interna compuesta por dos componentes de registro, denominados aquí como el lado del activo y el lado estable. El lado del activo rastrea la participación del LP en la exposición del pool a los movimientos de precio, mientras que el lado estable rastrea su participación en el valor denominado en estable del pool. Juntos, estos dos componentes determinan conjuntamente cómo se rastrea y liquida el valor de un LP.

Crucialmente, estos componentes no se almacenan como instantáneas estáticas. Cada vez que ocurre una operación, PerpPair actualiza su estado de liquidez global, y el saldo reconstruido de cada LP se deriva de la diferencia entre los valores globales acumulativos y la instantánea del punto de entrada del LP. Este mecanismo de contabilidad fue introducido en una refactorización posterior a la auditoría que reemplazó el acumulador original basado en participaciones con un seguimiento directo del saldo. Sin embargo, la ruta sustractiva refactorizada introdujo una asimetría de redondeo que podía causar que los componentes de LP reconstruidos se volvieran ligeramente negativos bajo ciertas secuencias de operaciones.

Análisis de Vulnerabilidad

El contrato vulnerable PerpPair (0xb683...36ae17) contiene dos fallas combinadas.

1. Asimetría de redondeo en la contabilidad refactorizada. La refactorización posterior a la auditoría que introdujo el seguimiento directo del saldo creó una asimetría de redondeo en la ruta de reconstrucción sustractiva. Bajo ciertas secuencias de operaciones, el valor acumulativo global después del redondeo podía volverse marginalmente menor que la instantánea del punto de entrada del LP, causando que la sustracción produjera un pequeño resultado negativo en lugar de cero. En teoría, este valor debería haber sido cero o cercano a cero; la asimetría era una falla específica de esta implementación refactorizada, no una propiedad inherente de la contabilidad sustractiva en general.

2. Conversión insegura de signed a unsigned. En getLpLiquidityBalance(), un componente de saldo LP reconstruido se convirtió de int256 a uint256 sin validación. En Solidity, convertir un int256 negativo a uint256 no revierte; envuelve el valor módulo 2^256, convirtiendo un número negativo pequeño como -1 en un entero sin signo casi máximo (2^256 - 1). Debido a que este saldo reconstruido alimentaba a calcPnL() para la liquidación, cualquier entrada negativa sería interpretada como una posición LP enorme, permitiendo a un atacante realizar una ganancia artificialmente inflada y drenar fondos del vault.

Ninguna falla por sí sola habría sido explotable. La asimetría de redondeo solo producía un valor ligeramente negativo, que bajo aritmética normal de int256 simplemente representaría un error insignificante. Pero una vez que ese valor negativo alcanzaba la conversión sin protección, se envolvía en un entero sin signo casi máximo. Una verificación de límites posterior luego limitaba el valor envuelto a la liquidez total del lado del activo del pool, convirtiendo efectivamente el desbordamiento en un reclamo sobre todo el lado del activo del mercado.

Análisis del Ataque

El siguiente análisis está basado en la transacción de ataque 0xcb0744...0c606447.

• Paso 1: El atacante tomó prestados 60,000 USDC a través de un préstamo flash de Aave.

• Paso 2: Una dirección auxiliar depositó 30,000 USDC como colateral y agregó una posición LP solo del lado estable de 19,980 tokens estables. Al depositar solo en el lado estable, el auxiliar aseguró que su componente LP del lado del activo comenzara cerca de cero, haciéndolo más susceptible a cruzar al territorio negativo por redondeo.

• Paso 3: Una segunda dirección auxiliar depositó 15,000 USDC y abrió una posición larga nocional de 100,000, causando una actualización de liquidityM que introdujo el error de redondeo clave. El gran tamaño nocional relativo a la liquidez del pool amplificó el impacto del redondeo por operación, empujando el saldo reconstruido del lado del activo del primer auxiliar ligeramente por debajo de cero.

• Paso 4: El primer auxiliar luego invocó realizePnL(). Durante la reconstrucción del saldo LP, el lpAssetBalance negativo se envolvió a un uint256 casi máximo. Este gran valor fue luego limitado a la liquidez completa del lado del activo del mercado y generó una ganancia muy inflada. En efecto, el protocolo creía que el LP poseía todo el lado del activo del mercado.

• Paso 5: El atacante retiró el PnL inflado del vault.

El mismo patrón se repitió hasta que se drenó la liquidez restante del vault. Después de repagar el préstamo flash, el atacante obtuvo una ganancia de aproximadamente $165.6K.

Conclusión

Este exploit fue causado en última instancia por la falta de validación de límites en una conversión de signed a unsigned. La corrección inmediata es sencilla: reemplazar la conversión directa con SafeCast.toUint256(), que revierte en entrada negativa en lugar de envolverla.

De manera más amplia, este incidente ilustra el riesgo de las refactorizaciones posteriores a la auditoría que evitan la revisión externa. Según el post-mortem oficial, la asimetría de redondeo fue introducida después de la auditoría externa final cuando el equipo reemplazó el acumulador original con seguimiento directo del saldo. Si bien la refactorización resolvió una preocupación de desbordamiento, creó un nuevo caso límite que las pruebas internas no detectaron. Cuando los protocolos refactorizan la lógica de contabilidad central, la nueva ruta de código debe tratarse como crítica para la seguridad y ser re-auditada, especialmente cuando los valores reconstruidos alimentan directamente la liquidación de PnL o la lógica de retiro.

Incidente HB Token

El 7 de abril de 2026, HB, un token ERC-20 personalizado con hooks de compra/venta integrados en BNB Chain, fue explotado por aproximadamente $193K. La causa raíz fue una lógica de liquidación de recompensas defectuosa: cuando se activaba, llamaba a swapBack(), que eliminaba reservas de HB directamente del par de PancakeSwap y luego llamaba a sync() para recalcular el precio del pool. Después de que el atacante comprara la mayor parte del HB del par, la ejecución posterior de swapBack() redujo aún más la liquidez restante e infló drásticamente el precio spot. El atacante luego vendía cantidades mínimas de HB en el pool distorsionado a cambio de cantidades desproporcionadamente grandes de USDT, repitiendo el ciclo hasta que el par fue drenado.

Contexto

HB es un token ERC-20 personalizado en BNB Chain con hooks de compra y venta integrados en _transfer(). Cuando los usuarios compran desde el par AMM, _handleBuy() registra información del costo base. Cuando los usuarios venden, _handleSell() se ramifica en diferentes rutas de impuesto y liquidación dependiendo del estado del par.

El token también incluye un mecanismo de liquidación de recompensas que puede activar swapBack(). En lugar de realizar un swap normal mediado por el router, swapBack() transfiere HB directamente desde el par de PancakeSwap a la dirección PROOF, luego fuerza al par a resincronizarse mediante sync(). Esto permite al contrato reducir las reservas de HB del par fuera de los flujos normales de trading del AMM e inmediatamente reprecia el pool al alza.

Análisis de Vulnerabilidad

La falla central en el contrato del token HB (0x62ce...87a4b0) fue que swapBack() obtenía recompensas extrayendo tokens directamente del par AMM en lugar de desde una tesorería o mediante un swap mediado por el router. Dado que swapBack() era accesible a través de la ruta de liquidación de recompensas, una ruta de código que no era de trading podía mutar directamente las reservas del par y alterar el precio spot.

Cuando las reservas de HB del par son bajas, una invocación de swapBack() reduce aún más el HB restante y amplifica la distorsión del precio, haciendo posible vender cantidades mínimas de HB a precios extremadamente inflados.

Análisis del Ataque

El siguiente análisis está basado en la transacción de ataque 0x19671f...d71594ed.

• Paso 1: El atacante tomó prestadas grandes cantidades de fondos de Venus.

• Paso 2: El atacante transfirió aproximadamente 1,496 HB al contrato del token, aumentando el saldo de HB del contrato para que el posterior swapBack() pudiera extraer una mayor cantidad del par.

• Paso 3: Al transferir una cantidad mínima de HB al par de PancakeSwap, el atacante activó _swapAndLiquify(), que intercambió aproximadamente 4,163 HB en posesión del contrato del token por 10 USDT y aumentó las recompensas de HB reclamables del atacante.

• Paso 4: El atacante luego gastó 72,117,360 USDT para comprar 73,608,753 HB, dejando al par con muy poca liquidez de HB restante.

• Paso 5: A continuación, el atacante activó la ruta de déficit de recompensas. Para satisfacer las recompensas, el token invocó swapBack(), que extrajo HB adicional del par de PancakeSwap y forzó sync(), aumentando drásticamente el precio de HB.

• Paso 6: El atacante transfirió directamente USDT al par para reponer sus reservas de USDT, luego vendió solo 0.000582 HB por 37,582,322 USDT al precio distorsionado.

Al repetir el Paso 6 para vender tokens HB a un precio distorsionado, el atacante extrajo casi todo el USDT del pool.

Conclusión

El incidente del token HB ilustra lo peligroso que es permitir que la lógica de recompensas mute directamente las reservas del AMM. Las funciones que afectan las reservas nunca deben ser accesibles desde las rutas de liquidación de recompensas, y los protocolos deben evitar confundir los saldos de tokens internos con la contabilidad de reservas del AMM en el flujo de control sensible a la seguridad. Cualquier diseño que dependa del precio spot del AMM después de perturbar internamente el pool es inherentemente vulnerable a la manipulación de precios.

Incidente Squid Multicall

El 7 de abril de 2026, un usuario de Squid perdió aproximadamente $517K en múltiples cadenas en un incidente relacionado con aprobaciones. El usuario aprobó por error un contrato SquidMulticall en lugar del Squid Router previsto. Esto permitió al atacante invocar una función permisionless SquidMulticall.run() para ejecutar llamadas externas arbitrarias. El atacante podía por tanto usar cualquier autorización aprobada al contrato para ejecutar llamadas transferFrom() de tokens contra usuarios que lo habían aprobado.

Contexto

En el flujo normal de Squid, los usuarios deben aprobar el Squid Router, mientras que SquidMulticall actúa solo como un auxiliar de ejecución. El contrato auxiliar está diseñado para ejecutar llamadas por lotes como parte de la lógica de enrutamiento, pero no debería ser el destinatario que los usuarios aprueban directamente para transferencias de tokens.

Debido a que las verificaciones de autorización ERC-20 se realizan solo contra la dirección del destinatario, cualquier contrato que combine aprobaciones de usuarios con capacidad de llamadas arbitrarias sin restricciones crea un sumidero de aprobaciones peligroso: una vez aprobado, ese contrato puede convertirse en un vector genérico de retiro de tokens si cualquiera puede controlar las llamadas que realiza.

Análisis de Vulnerabilidad

Este incidente no fue causado por una vulnerabilidad en el contrato inteligente. La pérdida resultó de dos condiciones que ocurrieron juntas: una aprobación errónea dirigida a SquidMulticall en lugar del Router, y el diseño permisionless de run() que acepta objetivos arbitrarios y calldata de cualquier llamador.

SquidMulticall está destinado a ejecutar llamadas por lotes como un paso posterior en el flujo del Router, donde las entradas son construidas por la lógica de enrutamiento de confianza. Usado como se pretende, el diseño permisionless no representa ningún riesgo. Pero una aprobación mal dirigida cambia eso completamente: un bot MEV detectó la autorización activa, llamó a run() con calldata manipulado para invocar transferFrom(víctima, atacante, monto), y drenó los tokens aprobados en cada cadena sin ninguna acción adicional de la víctima.

Análisis del Ataque

El incidente afectó a un usuario en BNB Chain, Arbitrum, Optimism, Avalanche y Base. El siguiente análisis está basado en la transacción de ataque 0x81d0c4...9b1301e9.

• Paso 1: La víctima (0xacc0...f40e98) aprobó erróneamente SquidMulticall en lugar del Squid Router previsto.

• Paso 2: Un bot MEV detectó esta autorización e invocó SquidMulticall.run() con calldata manipulado.

• Paso 3: A través de la llamada arbitraria, SquidMulticall invocó transferFrom(víctima, atacante, monto) y transfirió los activos aprobados fuera de la billetera de la víctima.

Conclusión

Este incidente ilustra el riesgo de que los contratos de llamadas arbitrarias permisionless coexistan con flujos de aprobación orientados al usuario. La causa inmediata fue una aprobación errónea, y debido a que SquidMulticall aceptaba llamadores sin restricciones, objetivos arbitrarios y calldata arbitrario, cualquier aprobación dirigida erróneamente a él era inmediata y totalmente explotable. Los protocolos que usan contratos auxiliares de ejecución deberían considerar agregar restricciones al llamador o limitar los objetivos de llamada permitidos por dichas funciones, para que una aprobación mal dirigida no pueda ser trivialmente weaponizada.

Incidente XBIT

El 11 de abril de 2026, el token XBIT en BNB Chain fue explotado por aproximadamente $53K. La causa raíz fue una falla de control de acceso fail-open en XBITVault: la verificación de autorización de la función transfer() era condicional — solo aplicaba msg.sender == xbitContract cuando xbitContract era distinto de cero, y pasaba silenciosamente en caso contrario. Debido a que bindXBIT() nunca había sido llamado para inicializar el contrato, esta falla estaba permanentemente expuesta, permitiendo a llamadores arbitrarios mover saldos de XBIT desde cualquier dirección, incluido el par XBIT/USDT de PancakeSwap. El atacante usó esto para drenar XBIT del par, luego vendió repetidamente cantidades mínimas de XBIT de vuelta al pool a cambio de cantidades desproporcionadamente grandes de USDT.

Contexto

XBITVault no es un contrato de tesorería pasivo. Es el backend de saldo y autorización para el sistema de tokens XBIT, exponiendo funciones similares a tokens como transfer(), approve() y mintForXBIT(). Bajo el diseño previsto, el propietario primero debe llamar a bindXBIT() para inicializar el vault estableciendo xbitContract, pancakePair, pairContract y xbitDecimals. Después de la inicialización, se supone que las funciones sensibles de cambio de estado solo son invocables por el contrato XBIT vinculado. En otras palabras, el modelo de seguridad del vault depende de una inicialización exitosa antes del uso público.

Análisis de Vulnerabilidad

La falla crítica es que el control de acceso es condicional en el contrato vulnerable XBITVault (0xc879...42391a). La función transfer() solo verifica msg.sender == xbitContract cuando xbitContract != address(0). Esto significa que la función no revierte cuando xbitContract no está configurado, y en cambio se vuelve públicamente invocable por cualquiera. Debido a que los saldos se almacenan en _balances, cualquier llamador externo puede mover XBIT desde cualquier dirección a cualquier otra dirección siempre que la dirección de origen tenga saldo suficiente.

La ruta de inicialización prevista era bindXBIT(), pero como nunca fue llamada, el vault permaneció en un estado no inicializado y fail-open. El resultado fue efectivamente una primitiva de transferencia de saldo arbitraria sin restricciones.

Análisis del Ataque

El siguiente análisis está basado en la transacción de ataque 0xbc877f...4df1b694.

• Paso 1: A través de la función transfer() sin restricciones, el atacante movió 1,526,216.569 XBIT fuera del par XBIT/USDT sin proporcionar ningún USDT correspondiente.

• Paso 2: El atacante invocó sync() para colapsar las reservas de XBIT del par a solo 1-2 unidades.

• Paso 3: Después de que el par quedara con liquidez de XBIT cercana a cero, el atacante vendió repetidamente XBIT, drenando aproximadamente 53,112 USDT del par.

Conclusión

Este incidente fue causado por una verificación de control de acceso dependiente de la inicialización que falló de forma abierta. transfer() no tenía restricciones siempre que xbitContract no estuviera configurado, y como bindXBIT() nunca fue llamado, el vault expuso permanentemente una primitiva pública de transferencia de saldo arbitraria. Las funciones privilegiadas deben revertir hasta que la inicialización esté completa, y los pasos de vinculación en el momento del despliegue deben ser prerrequisitos aplicados en cadena en lugar de supuestos operacionales.

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 (incluidos 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 BlockSec : Enviar una solicitud

• 🔗 Phalcon Security APP: Reservar una demo

• 🔗 Phalcon Compliance