Durante la semana pasada (16 de feb – 22 de feb de 2026), BlockSec detectó y analizó tres incidentes de ataque, con pérdidas totales estimadas de ~$6,22M. La tabla a continuación resume estos incidentes, y los análisis detallados de cada caso se presentan en las subsecciones siguientes.
| Fecha | Incidente | Tipo | Pérdida Estimada |
|---|---|---|---|
| 2026/02/16 | Incidente Moonwell | Mala configuración | ~$1,78M |
| 2026/02/19 | Incidente PearlDriver | Desbordamiento Aritmético | ~$40,3K |
| 2026/02/21 | Incidente IoTex | Compromiso de Clave | ~$4,4M |
1. Incidente Moonwell
Resumen Breve
El 16 de febrero de 2026, el protocolo Moonwell en Base fue explotado debido a una mala configuración del oráculo, lo que resultó en aproximadamente $1,78 millones en deuda incobrable. El problema ocurrió durante la ejecución de la propuesta MIP-X43, donde el oráculo de cbETH en Base fue asignado incorrectamente a un feed de tasa de cambio cbETH/ETH en lugar del oráculo compuesto que incorpora el precio ETH/USD. Esto provocó que el oráculo reportara cbETH a ~$1,12 en lugar de su valor de mercado real de ~$2.200. Los bots de liquidación capturaron inmediatamente 1.096,317 cbETH mientras repagaban deuda mínima antes de que los límites fueran reducidos para detener el exploit.
Antecedentes
Moonwell es un protocolo de préstamos en múltiples cadenas y ejecutó una propuesta llamada MIP-X43 el 16 de febrero de 2026. Esta propuesta tenía como objetivo activar los contratos OEV (Oracle Extractable Value) Wrapper de Chainlink en todos los mercados principales e isolados restantes en Base y Optimism, extendiendo la cobertura más allá de los tres feeds iniciales habilitados en MIP-X38. Los wrappers OEV están diseñados para permitir que el protocolo capture valor durante las liquidaciones que dependen de los precios del oráculo, mientras se asegura que los liquidadores permanezcan debidamente incentivados.
Análisis de Vulnerabilidad
La vulnerabilidad se originó en un error de configuración en el constructor de ChainlinkOracleConfigs.sol. Para la cadena Base con cbETH, la propuesta configuró el oráculo como "cbETHETH_ORACLE" (un feed de tasa de cambio cbETH/ETH) en lugar del oráculo compuesto adecuado que combina esta tasa con el precio ETH/USD. Cuando el wrapper OEV fue desplegado y conectado como feed mediante setFeed() en el ChainlinkOracle, el protocolo comenzó a usar una tasa de cambio bruta (cbETH/ETH ≈ 1,12) como precio en USD para cbETH. Esto creó una discrepancia masiva entre el precio reportado (~$1,12) y el valor de mercado real (～$2.200–$2.400), resultando en una subvaloración de ~2.200x del colateral cbETH.
Análisis del Ataque
-
A las 2:01 AM UTC+8 del 16 de febrero de 2026, se completó la ejecución de MIP-X43, activando el oráculo de cbETH mal configurado en la cadena Base.
-
Los bots de liquidación que monitorean el protocolo detectaron inmediatamente la discrepancia de precios y ejecutaron liquidaciones sobre las [posiciones de colateral] de cbETH.
- En cuestión de minutos, los liquidadores se apoderaron de 1.096,31 cbETH, generando ~$1,78M en deuda incobrable en los mercados afectados.
Conclusión
Este incidente fue causado en última instancia por un error de configuración en el despliegue de MIP-X43 de Moonwell, donde a cbETH de la cadena Base se le asignó por error un feed de tasa de cambio cbETH/ETH en lugar del oráculo compuesto correcto. Esta mala configuración permitió el agotamiento rápido de una cantidad sustancial de colateral cbETH.
Para los protocolos que gestionan múltiples feeds de oráculos, es fundamental implementar procedimientos de validación exhaustivos previos al despliegue para garantizar que cada activo esté vinculado a su fuente de precios prevista. Una verificación rigurosa puede reducir significativamente el riesgo de este tipo de malas configuraciones de alto impacto.
2. Incidente PearlDriver
Resumen Breve
El 19 de febrero de 2026, el contrato de curva de vinculación NLAMM de PearlDriver en BSC fue explotado, resultando en pérdidas de aproximadamente $40,3K. La causa raíz fue un desbordamiento aritmético sin verificación en la función buy(), lo que permitió al atacante acuñar cantidades extremadamente grandes de tokens del juego a un costo casi nulo, para luego deshacerse de ellos en los pools de liquidez de PearlDEX.
Antecedentes
PearlDriver utiliza una curva de vinculación NLAMM (Market Maker Automatizado No Lineal) para la acuñación de tokens. Los usuarios pueden adquirir tokens de recursos del juego mediante la función buy(), donde el costo en stablecoin de la compra se calcula como: costo = cantidad * precioActual.
En condiciones normales, esta fórmula garantiza que el pago requerido sea directamente proporcional a la cantidad adquirida. La curva de vinculación se basa en el supuesto de que las compras más grandes requieren pagos proporcionalmente mayores, manteniendo la integridad de los precios y evitando la emisión desproporcionada de tokens.
Análisis de Vulnerabilidad
La causa raíz fue un desbordamiento aritmético en el cálculo del pago en stablecoin. Toda la función buy() estaba envuelta en un bloque unchecked, deshabilitando la protección de desbordamiento integrada de Solidity. Como resultado, la multiplicación utilizada para calcular el costo de compra no revertía al superar el límite máximo de enteros. En cambio, el valor desbordó y se envolvió a un número mucho menor, reduciendo drásticamente el pago requerido.
En consecuencia, el atacante pudo pagar casi nada mientras acuñaba una enorme cantidad de tokens, que luego fueron inmediatamente volcados en los pares de liquidez del DEX para drenar USDT.
Análisis del Ataque
En una única transacción, el atacante explotó la función vulnerable buy() en cinco activos (MINERAL DE HIERRO, CARBÓN, MADERA, ARENA y ARCILLA) utilizando el mismo patrón de ataque. Tomando el primer activo como ejemplo:
-
El atacante especificó una cantidad de compra extremadamente grande al invocar
buy(). Debido a la aritmética sin verificación, el cálculo cantidad * precioActual desbordó y se envolvió a un valor casi nulo, requiriendo solo 0,0053 USDT (menos de ~$0,01) como pago. A pesar del costo insignificante, el contrato acuñó una enorme cantidad de MINERAL DE HIERRO para el atacante, específicamente 7,03 × 10⁵⁸ tokens. -
El atacante intercambió inmediatamente una porción del MINERAL DE HIERRO acuñado en su par de liquidez correspondiente de PearlDEX, recibiendo 7.805,55 USDT (~$7.805,56).
La misma secuencia de desbordamiento y volcado fue ejecutada contra los otros cuatro activos, drenando la liquidez de cada par activo-USDT y generando más de $40K en ganancias totales.
Conclusión
Este incidente fue causado por aritmética sin verificación en la lógica de precios de la función buy() del NLAMM. Al deshabilitar las verificaciones de desbordamiento, la función permitió que valores de entrada extremos distorsionaran el cálculo del pago, rompiendo los supuestos económicos del modelo de curva de vinculación.
Si bien la aritmética sin verificación puede ser apropiada en escenarios estrictamente controlados, su uso en lógica financiera que determina directamente los montos de pago puede introducir riesgos significativos. Para mitigar dichos riesgos, los desarrolladores deben revisar cuidadosamente todas las operaciones aritméticas y ser cautelosos al considerar deshabilitar las verificaciones de desbordamiento integradas de Solidity 0.8+, especialmente en rutas de código que afectan precios o transferencias.
3. Incidente IoTex
Resumen Breve
El 21 de febrero de 2026, el puente ioTube de IoTeX sufrió una brecha de seguridad tras el compromiso de la clave del propietario del Validador de Ethereum. El atacante obtuvo la propiedad del contrato Validador, luego tomó el control de los contratos TokenSafe y MintPool para drenar ~$4,4M en reservas del puente y acuñar más de 400M de tokens CIOTX. Las reservas robadas fueron intercambiadas y parcialmente transferidas a Bitcoin. Según el proyecto, aproximadamente 355M de los tokens CIOTX acuñados han sido bloqueados o congelados permanentemente.
Antecedentes
El ioTube comprometido es la infraestructura de puente entre cadenas de IoTeX que conecta la Capa 1 de IoTeX con otras redes como Ethereum. En Ethereum, la arquitectura del puente se centra en el contrato Validador (es decir, TransferValidatorWithPayload), que verifica los mensajes de liquidación entre cadenas y gestiona los contratos de acuñación subordinados. Estos incluyen TokenSafe, que mantiene los activos de reserva del puente, y MintPool, que tiene autoridad de acuñación para ciertos tokens como CIOTX.
Análisis de Vulnerabilidad
La causa raíz fue el compromiso de la clave privada del propietario del contrato Validador. Dado que el puente dependía de una única EOA sin controles de múltiples firmas ni bloqueo temporal, la posesión de esta clave otorgaba control administrativo total. Utilizando la función upgrade() del contrato, el atacante transfirió la propiedad de los contratos TokenSafe y MintPool a una dirección controlada por el atacante. Esto permitió el retiro directo de los activos de reserva del puente y la acuñación no autorizada de grandes cantidades de CIOTX.
Análisis del Ataque
-
Comprometer la clave del propietario del contrato Validador en Ethereum, obteniendo control administrativo.
-
Usar el contrato Validador para transferir la propiedad de los contratos
TokenSafeyMintPool.
-
Drenar ~$4,4M en activos de reserva (USDC, USDT, WBTC, WETH, BUSD, etc.) de
TokenSafey acuñar más de 400M de CIOTX medianteMintPool. -
Intercambiar los tokens de reserva robados y transferirlos a otras cadenas.
Conclusión
Este incidente representa un compromiso de clave de punto único de fallo de manual. Toda la seguridad del puente del lado de Ethereum dependía de una única EOA con plena autoridad administrativa y sin protección de múltiples firmas ni salvaguardas de bloqueo temporal. Una vez comprometida la clave privada de la EOA, el control sobre los componentes críticos del puente se perdió efectivamente.
El caso pone de relieve el riesgo del control administrativo centralizado y subraya la importancia de distribuir la autoridad de actualización y custodia a través de mecanismos de gobernanza más sólidos.
Acerca de BlockSec
BlockSec es un proveedor integral de seguridad blockchain y cumplimiento de criptomonedas. Construimos productos y servicios que ayudan a los clientes a realizar auditorías de código (incluidos contratos inteligentes, blockchain y carteras), 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 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
