Resumen Semanal de Incidentes de Seguridad Web3 | 2 – 8 de Feb, 2026

Durante la semana pasada (2 de feb–8 de feb, 2026), BlockSec detectó y analizó seis incidentes de ataque, con pérdidas totales estimadas de aproximadamente $3.8M. La tabla a continuación resume estos incidentes, y los análisis detallados de cada caso se presentan en las subsecciones siguientes.

1. Incidente CrossCurve

Resumen Breve

El 2 de febrero de 2026, el protocolo CrossCurve fue explotado, resultando en una pérdida de aproximadamente $2.8 millones. La causa raíz fue que el contrato ReceiverAxelar expuso una función expressExecute() sin permisos, que eludió el proceso estándar de validación del Axelar Gateway. El receptor solo realizaba verificaciones de dirección de par basadas en datos proporcionados externamente. En consecuencia, el atacante construyó una llamada maliciosa entre cadenas para activar el mecanismo de quema y desbloqueo, lo que llevó a la liberación no autorizada de 999,787,453e18 tokens EYWA al atacante.

Antecedentes

CrossCurve es un protocolo de puente entre cadenas desarrollado por Eywa.Fi, construido sobre el marco de mensajería entre cadenas de Axelar.

En el modelo de seguridad previsto de Axelar, los mensajes entre cadenas son retransmitidos por el Axelar Gateway y deben ser validados explícitamente en la cadena de destino mediante validateContractCall(). Solo los mensajes que han sido aprobados criptográficamente por el Gateway tienen permitido proceder a la ejecución.

Para reducir la latencia, Axelar también proporciona un mecanismo de ejecución exprés, donde un contrato receptor puede ejecutar optimistamente un mensaje antes de que el Gateway finalice la validación. Este diseño requiere un control de acceso estricto para garantizar que solo los ejecutores de confianza puedan invocar rutas de ejecución exprés; de lo contrario, los mensajes entre cadenas no validados pueden procesarse prematuramente.

Análisis de la Vulnerabilidad

La causa raíz fue que ReceiverAxelar expuso una función expressExecute() sin permisos que podía alcanzar directamente la ruta privilegiada _execute() sin autorización del Axelar Gateway.

En el modelo de seguridad correcto de Axelar, los mensajes entre cadenas deben ser primero aprobados por el Gateway mediante ejecución respaldada por prueba y luego validados en la cadena de destino a través de validateContractCall(), que vincula (commandId, sourceChain, sourceAddress, contractAddress, payloadHash) a una única ejecución autorizada.

Sin embargo, la ruta expressExecute() omitió esta validación por completo. Dependía únicamente de una verificación de par usando sourceChain y sourceAddress, ambos controlados por el atacante, y por lo tanto no proporcionaba seguridad real. Esto permitió al atacante suministrar un mensaje falsificado, forzar la rama receiveData y ejecutar un payload arbitrario que finalmente activó unlock() en el Eywa CLP Portal, resultando en la liberación no autorizada de activos entre cadenas.

Análisis del Ataque

• Paso 1: El atacante invocó directamente expressExecute(), falsificando sourceChain, sourceAddress y payload. Dado que expressExecute() omite la validación del Gateway y procede directamente a _execute(), la única medida de seguridad restante era una verificación de lista blanca de dirección de par: require(peers[sourceChain] == sourceAddress.toAddress()). Esta verificación era insuficiente porque tanto sourceChain como sourceAddress eran suministrados externamente. Al proporcionar la dirección de par correcta en la lista blanca, el atacante la eludió.

• Paso 2: El payload falsificado fue luego reenviado a la rama Receiver.receiveData(). La función resume() ejecutó la operación entre cadenas PortalV2.unlock() basándose en el payload malicioso, resultando en el desbloqueo no autorizado de fondos al atacante.

Conclusión

Este incidente fue fundamentalmente causado por un control de acceso insuficiente en una ruta de ejecución acelerada dentro de un contrato receptor entre cadenas. Al exponer expressExecute() como una función sin permisos y confiando únicamente en información de par suministrada externamente, CrossCurve efectivamente permitió a los atacantes eludir las garantías de seguridad del Axelar Gateway y ejecutar payloads arbitrarios entre cadenas.

Para mitigar riesgos similares en el futuro, los protocolos entre cadenas que integran mecanismos de ejecución exprés u optimista deberían:

• Aplicar autenticación estricta del llamador en funciones de ejecución de ruta rápida, asegurando que solo los relayers o gateways de confianza puedan invocarlas.

• Evitar depender de metadatos controlados por el atacante (como la cadena de origen o la dirección) como única base para la autorización.

• Tratar la ejecución exprés como una operación privilegiada y aplicar verificaciones de defensa en profundidad equivalentes a las rutas de ejecución validadas estándar.

La adherencia cuidadosa a estos principios es crítica al diseñar sistemas entre cadenas, donde un solo bypass de validación puede resultar en pérdida sistémica de activos en múltiples redes.

2. Incidente GYD

Resumen Breve

El 3 de febrero de 2026, el Protocolo GYD fue explotado, resultando en pérdidas de aproximadamente $700K. La causa raíz fue que su receptor CCIP confiaba en datos de mensaje controlados por el atacante como contexto de ejecución. El exploit fue desencadenado por un mensaje CCIP enviado desde Arbitrum, que fue correctamente autenticado en la capa de mensajería, pero cuyo payload decodificado fue luego utilizado para realizar llamadas externas arbitrarias en _ccipReceive(). Al establecer el destinatario decodificado en el contrato de token GYD y suministrar calldata para approve(attacker, type(uint256).max), el depósito en garantía otorgó involuntariamente una asignación ilimitada sobre su saldo de GYD. El atacante posteriormente drenó los fondos mediante transferFrom().

Antecedentes

El contrato GydL1CCipEscrow es un contrato de depósito en garantía de activos entre cadenas construido sobre el estándar Chainlink CCIP. Los usuarios bloquean tokens GYD en este contrato en L1, que luego envía un mensaje entre cadenas a través de CCIP a la cadena de destino. A la inversa, cuando un mensaje entre cadenas llega al depósito en garantía, CCIP valida su autenticidad y activa _ccipReceive(). Esta función analiza los calldata entrantes para extraer tx.recipient y data, ejecuta la lógica de transferencia o desbloqueo de GYD basándose en los parámetros analizados (cantidad y destinatario) y, si data no está vacío, realiza una llamada externa arbitraria mediante recipient.functionCall(data).

Análisis de la Vulnerabilidad

La vulnerabilidad principal es que GydL1CCipEscrow no valida la dirección tx.recipient decodificada de los mensajes entre cadenas. Un atacante puede establecer tx.recipient en la dirección del contrato de token GYD y elaborar data como approve(attacker, type(uint256).max). Dado que el contrato de depósito en garantía mantiene una gran cantidad de tokens GYD bloqueados, esta llamada externa sin restricciones hace que el depósito en garantía otorgue al atacante asignación total de sus tokens GYD, quien luego puede drenar todos los fondos mediante transferFrom().

Análisis del Ataque

• Paso 1: El atacante inició un mensaje CCIP malicioso en Arbitrum, especificando tx.recipient como la dirección del contrato de token GYD en Ethereum y tx.data como el calldata codificado para approve(attacker, type(uint256).max).

• Paso 2: Cuando el mensaje fue procesado en Ethereum, la función _ccipReceive() del contrato GydL1CCipEscrow ejecutó la aprobación en el contrato de token GYD sin validar tx.recipient. El atacante luego llamó a transferFrom() en el token GYD para drenar todos los fondos depositados en garantía.

Conclusión

La causa raíz de este incidente es que el contrato GydL1CCipEscrow no logró validar el payload decodificado al procesar mensajes entre cadenas, permitiendo a un atacante construir una llamada maliciosa entre cadenas. Para la mensajería de puentes entre cadenas, los desarrolladores deberían:

• Prohibir llamadas directas a contratos de token desde el depósito en garantía: Asegurarse de que los payloads de mensajes entre cadenas no puedan activar llamadas al contrato de token depositado en garantía.

• Implementar una lista blanca de destinos de ejecución: Restringir tx.recipient (o tx.target) a un conjunto bien definido de direcciones de confianza.

3. Incidente Token SOFI

Resumen Breve

El 5 de febrero de 2026, el token SOFI en BNB Chain fue explotado, resultando en pérdidas de aproximadamente $29.6K.

La causa raíz fue un mecanismo de quema defectuoso implementado dentro de la función _transfer() sobrescrita del token. Al abusar de la lógica de quema retrasada que eliminaba tokens directamente del pool de liquidez de PancakeSwap y activaba una sync() posterior, el atacante pudo inflar artificialmente el precio de SOFI. Mediante transferencias e intercambios repetidos, el atacante extrajo el exceso de liquidez de USDT del pool y repagó el préstamo flash con ganancia.

Antecedentes

SOFI es un token ERC-20 personalizado desplegado en BNB Chain. A diferencia de una implementación ERC-20 estándar, el token SOFI sobrescribe la función interna _transfer() para incorporar lógica adicional relacionada con la quema de tokens durante las operaciones de venta.

El token se negocia en un pool AMM de producto constante al estilo PancakeSwap (SOFI–USDT). En dichos pools, el precio del token se deriva de la razón de las reservas de tokens. Cualquier cambio inesperado en los balances del pool, especialmente los no causados por intercambios, puede manipular directamente el precio.

En este diseño, el propio contrato de token interactúa con el pool de liquidez durante las transferencias, haciendo que la contabilidad de reservas del pool dependa de la lógica del lado del token en lugar de la mecánica puramente AMM.

Análisis de la Vulnerabilidad

La vulnerabilidad reside en el mecanismo de quema de SOFI combinado con la interacción del pool dentro de _transfer().

Cuando los tokens SOFI son transferidos a la dirección del pool de liquidez, el contrato interpreta la transferencia como una venta e incrementa una variable acumuladora interna waitBurnTokenAmount. Sin embargo, la cantidad acumulada no se quema inmediatamente. En cambio, se quema del saldo del pool en una transferencia posterior al pool, después de lo cual se llama a la función sync() del pool.

Este diseño introduce dos problemas críticos:

1. Manipulación directa del balance del pool Quemar tokens directamente del pool reduce la reserva de SOFI sin una salida correspondiente de USDT, violando el invariante del AMM e incrementando artificialmente el precio de SOFI.

2. Ejecución retrasada y controlable por el atacante Debido a que la quema solo ocurre en una transferencia futura, un atacante puede controlar con precisión cuándo ocurren la quema y la sync(), permitiéndole posicionarse para obtener ganancias de la distorsión del precio.

Como resultado, el precio del pool ya no refleja la dinámica genuina de oferta y demanda, permitiendo un arbitraje extraíble.

Análisis del Ataque

• Paso 1: Tomar prestado USDT mediante un préstamo flash.

• Paso 2: Intercambiar USDT por SOFI en el pool SOFI–USDT.

• Paso 3: Transferir SOFI al pool e invocar skim() para incrementar waitBurnTokenAmount con pérdida mínima.

• Paso 4: Transferir SOFI al pool nuevamente para activar la quema + sync(), subiendo el precio de SOFI, luego intercambiar SOFI por USDT.

• Paso 5: Repetir el Paso 4. El waitBurnTokenAmount recién acumulado solo se quema en la siguiente transferencia, por lo que se requieren múltiples iteraciones.

• Paso 6: Drenar USDT del pool, luego repagar el préstamo flash.

Conclusión

Este incidente fue finalmente causado por un mecanismo de quema del lado del token inseguro que manipuló directamente los balances del pool AMM. Al incorporar lógica de quema retrasada dentro de _transfer() y ejecutar quemas desde el propio pool de liquidez, el token SOFI rompió los supuestos fundamentales de los AMM de producto constante y habilitó la manipulación determinista de precios.

Para los tokens ERC-20 que sobrescriben _transfer(), los desarrolladores deben tener especial cuidado en evitar:

• Quemar tokens directamente de pools de liquidez

• Introducir mecanismos retrasados o con estado que afecten las reservas del pool

• Acoplar demasiado estrechamente la lógica del token con los internos del AMM

En general, la lógica relacionada con la tokenómica nunca debe poder alterar arbitrariamente los balances del pool, ya que incluso pequeñas desviaciones pueden ser explotadas repetidamente para drenar liquidez.

4. Incidente de Protocolo de Staking Desconocido (5 de feb, 2026)

Resumen Breve

El 5 de febrero de 2026, el Protocolo de Staking Desconocido en Ethereum fue explotado, resultando en pérdidas de aproximadamente $71.6K.

La causa raíz fue la dependencia del protocolo en datos de entrada no verificados suministrados por el usuario durante los retiros. Específicamente, el protocolo reenvió routerCalldata y cantidades de LP controlados por el atacante al Pendle Router sin validación. Al elaborar calldata que eliminaba toda la posición LP del protocolo y estableciéndose a sí mismos como receptor, el atacante pudo drenar todos los activos mantenidos por el vault.

Antecedentes

El Protocolo de Staking Desconocido es un vault de rendimiento simple construido sobre Pendle Finance. Los usuarios depositan activos en el vault, que luego enruta esos activos a través del Pendle Router para acuñar posiciones generadoras de rendimiento. Internamente, los depósitos se convierten en SY, se dividen en PT e YT, y se combinan para formar tokens LP de Pendle.

El protocolo custodia todos los tokens LP y mantiene una contabilidad interna de la cantidad subyacente depositada de cada usuario. Cuando los usuarios retiran, el vault canjea los tokens LP a través del Pendle Router y devuelve los activos correspondientes al usuario.

Análisis de la Vulnerabilidad

La causa raíz son los datos de entrada no validados. La función withdrawWithCalldataMultiToken() toma cuatro parámetros: el token subyacente, la cantidad subyacente, la cantidad de LP y routerCalldata. Solo verifica si el saldo subyacente registrado del usuario es suficiente, pero no valida la cantidad de LP ni el contenido de routerCalldata. Al eliminar liquidez a través del Pendle Router, el contrato depende completamente de los parámetros incorporados en routerCalldata. Como resultado, un atacante podría pasar el saldo LP completo del protocolo y establecerse a sí mismo como receptor, drenando todos los activos mantenidos por el protocolo.

Análisis del Ataque

• Paso 1: Tomar un préstamo flash de USDC.

• Paso 2: Depositar una pequeña cantidad de USDC en el protocolo, que enruta los fondos a través del Pendle Router para añadir liquidez y acuñar LP.

• Paso 3: Invocar withdrawWithCalldataMultiToken() con un routerCalldata elaborado que establece el receiver como el atacante y el lpAmount como el saldo LP completo del protocolo.

• Paso 4: El protocolo elimina liquidez a través del Pendle Router usando los parámetros controlados por el atacante y envía todos los activos al atacante.

• Paso 5: Intercambiar los activos recibidos de vuelta a USDC, repagar el préstamo flash y quedarse con el resto como ganancia.

Conclusión

Este incidente fue finalmente causado por la confianza ciega en la entrada externa controlada por el atacante dentro de una ruta de retiro crítica. Al reenviar calldata arbitrario y cantidades de LP a un router externo sin validación, el protocolo permitió a los usuarios ejecutar retiros que superaban con creces su parte legítima, llevando al drenaje completo de la posición Pendle del vault.

Para vaults de producción y estrategias de rendimiento, especialmente aquellas que integran routers externos complejos, los desarrolladores deberían:

• Tratar toda la entrada suministrada por el usuario, incluido el calldata, como no confiable y validarla rigurosamente.

• Derivar parámetros sensibles (como cantidades de LP y receptores) internamente, en lugar de aceptarlos de los usuarios.

• Aplicar defensa en profundidad haciendo cumplir la consistencia entre la contabilidad interna y los resultados de ejecución externos.

No hacerlo puede permitir que incluso una sola llamada de retiro comprometa todos los activos mantenidos por el protocolo.

5. Incidente del Protocolo LZMultiCall

Resumen Breve

El 7 de febrero de 2026, el incidente LZMultiCall resultó en pérdidas de aproximadamente $142K en Ethereum.

El incidente no fue causado por una vulnerabilidad en el propio contrato LZMultiCall, sino por el mal uso de los usuarios. LZMultiCall es un contrato de ejecución por lotes sin estado que no está diseñado para custodiar activos ni mantener asignaciones de ERC-20. Sin embargo, algunos usuarios aprobaron erróneamente asignaciones de token al contrato. Un atacante posteriormente explotó estas aprobaciones pendientes invocando execute() con calldata elaborado para llamar a transferFrom(), drenando tokens de los usuarios afectados.

Antecedentes

LZMultiCall es un contrato utilitario genérico de ejecución por lotes. Su propósito previsto es permitir a los usuarios agrupar múltiples llamadas en una sola transacción, reenviando calldata suministrado por el usuario a contratos objetivo.

Fundamentalmente, LZMultiCall está diseñado para ser sin estado y no custodial. No está destinado a mantener activos, ni los usuarios deben nunca otorgarle asignaciones de ERC-20. Cualquier aprobación de token otorgada a LZMultiCall viola sus supuestos de uso explícitos y expone a los usuarios a riesgo, ya que el contrato puede reenviar llamadas arbitrarias en nombre del llamador.

Análisis de la Vulnerabilidad

Aunque LZMultiCall funcionó según lo diseñado, su función execute() sin permisos se volvió explotable una vez que los usuarios le otorgaron erróneamente asignaciones de ERC-20. Debido a que el contrato reenvía calldata arbitrario a cualquier objetivo, un atacante podría invocar execute() con calldata que codifica transferFrom(victim, attacker, amount) en contratos de token, drenando efectivamente cualquier asignación pendiente.

Análisis del Ataque

• El atacante invocó execute() con calldata elaborado dirigido al contrato de token, usando transferFrom() para transferir tokens de usuarios que habían aprobado erróneamente asignaciones a LZMultiCall.

Conclusión

Este incidente fue finalmente causado por violar los supuestos de uso explícitos de un contrato de ejecución por lotes sin estado. LZMultiCall nunca fue destinado a custodiar fondos ni mantener asignaciones de ERC-20. Una vez que los usuarios otorgaron erróneamente aprobaciones, el modelo de ejecución sin permisos del contrato permitió a cualquier llamador drenar esas asignaciones a través de llamadas reenviadas arbitrarias.

Para usuarios e integradores que interactúan con contratos de ejecución por lotes o de estilo multicall:

• Nunca otorgue asignaciones de ERC-20 a contratos que no están explícitamente diseñados para custodiar activos.

• Trate los contratos genéricos de reenvío de llamadas como superficies de ejecución no confiables.

• Prefiera aprobaciones por transacción o diseños sin asignación (p. ej., permit) donde sea posible.

Incluso en ausencia de una vulnerabilidad del protocolo, malentender el modelo de confianza de un contrato puede resultar en pérdidas significativas e irreversibles.

6. Incidente de Protocolo Desconocido (8 de feb, 2026)

Resumen Breve

El 8 de febrero de 2026, el Protocolo Desconocido en Ethereum fue explotado, resultando en pérdidas de aproximadamente $63K.

La causa raíz fueron los datos de entrada controlados por el atacante no verificados en una ruta de ejecución de módulo de Gnosis Safe. Un contrato utilitario (0xF5E4) registrado como SafeModule expuso un callback de préstamo flash que decodificaba datos arbitrarios suministrados por el usuario e invocaba directamente GnosisSafe.execTransactionFromModule(). Debido a que las llamadas originadas desde el módulo eluden la verificación de firmas por diseño, el atacante pudo ejecutar transacciones arbitrarias autorizadas por Safe, repagar la deuda de Aave V3 del Safe y retirar todo el colateral a direcciones controladas por el atacante.

Antecedentes

La arquitectura del protocolo se centra en un Gnosis Safe que gestiona una posición apalancada en Aave V3. Gnosis Safe admite un modelo de ejecución modular, donde los SafeModules designados pueden ejecutar transacciones en nombre del Safe sin requerir firmas del propietario. Este diseño está destinado a admitir automatización, integraciones y estrategias avanzadas.

En esta configuración, el contrato 0xF5E4 fue configurado como SafeModule del Gnosis Safe. El contrato parece ser un utilitario auxiliar diseñado para admitir la gestión de posiciones basada en préstamos flash. Implementa un callback de préstamo flash, receiveFlashLoan(), que es invocado por proveedores de liquidez externos durante la ejecución del préstamo flash.

Debido a que las llamadas de módulo eluden la verificación de firmas, la corrección y seguridad de la lógica del módulo es crítica: cualquier fallo otorga efectivamente control irrestricto sobre el Safe.

Análisis de la Vulnerabilidad

El SafeModule 0xF5E4 expone un callback de préstamo flash receiveFlashLoan() que decodifica userData suministrado externamente y lo usa directamente para llamar a GnosisSafe.execTransactionFromModule(). Debido a que 0xF5E4 está registrado como SafeModule, las llamadas originadas desde él eluden la verificación de firmas. Sin embargo, receiveFlashLoan() no autentica al llamador ni valida los parámetros decodificados (p. ej., dirección objetivo, valor, calldata o tipo de operación). Como resultado, un atacante puede suministrar userData elaborado para hacer que el módulo ejecute transacciones arbitrarias a través del Safe, permitiéndole repagar la deuda de Aave V3 del Safe, retirar todo el colateral y drenar la posición para obtener ganancias.

Análisis del Ataque

• Paso 1: El atacante tomó un préstamo flash a través de Uniswap V4 y transfirió los fondos al GnosisSafe.

• Paso 2: El atacante llamó a flashLoan() de Balancer con userData elaborado, sin tomar prestados activos reales, y estableciendo el recipient en 0xF5E4.

• Paso 3: En 0xF5E4.receiveFlashLoan(), el contrato decodificó el userData suministrado por el atacante. Dado que 0xF5E4 está registrado como módulo Safe, eludió las verificaciones de firma e invocó execTransactionFromModule() para ejecutar llamadas arbitrarias según los parámetros incorporados en userData.

• Paso 4: Usando esta capacidad, el atacante repagó la deuda del GnosisSafe en Aave V3 y retiró todo el colateral, realizando así ganancias.

Conclusión

Este incidente fue finalmente causado por el uso inseguro de la ejecución basada en módulos combinada con entrada externa no validada. Al reenviar userData arbitrario suministrado por el atacante a execTransactionFromModule(), el SafeModule 0xF5E4 expuso efectivamente control irrestricto sobre el Gnosis Safe. Dado que los módulos Safe eluden las verificaciones de firma por diseño, este fallo habilitó un compromiso completo de la posición Aave V3 del Safe.

Para sistemas que dependen de módulos Gnosis Safe o marcos de ejecución privilegiada similares, los desarrolladores deberían:

• Tratar toda entrada externa, incluido el userData de préstamos flash, como no confiable y validarla rigurosamente.

• Restringir la ejecución del módulo a un conjunto bien definido de acciones, objetivos y selectores.

• Evitar módulos "utilitarios" genéricos que reenvíen calldata arbitrario a funciones de ejecución privilegiadas.

No aplicar estas salvaguardas puede transformar un único contrato auxiliar en una puerta trasera administrativa completa.

Acerca de BlockSec

BlockSec es un proveedor integral de seguridad blockchain y cumplimiento de criptomonedas. 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 del ciclo de vida completo de protocolos y plataformas.

BlockSec ha publicado múltiples artículos de seguridad blockchain en conferencias prestigiosas, 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