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 proporcionan 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
Breve Resumen
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 cbETH de 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 causó que el oráculo reportara cbETH en ~$1,12 en lugar de su valor de mercado real de ~$2.200. Los bots de liquidación inmediatamente tomaron 1.096,317 cbETH mientras repagaban una 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 que ejecutó una propuesta llamada MIP-X43 el 16 de febrero de 2026. Esta propuesta tenía como objetivo activar los contratos Wrapper de Chainlink OEV (Valor Extraíble por Oráculo) 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 derivó de un error de configuración en el constructor de ChainlinkOracleConfigs.sol. Para el cbETH de la cadena Base, 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 real de mercado (~$2.200–$2.400), resultando en una subvaluación de ~2.200x del colateral cbETH.
Análisis del Ataque
-
A las 2:01 AM UTC+8 del 16 de febrero de 2026, la ejecución de MIP-X43 se completó, activando el oráculo 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 en las [posiciones de colateral] de cbETH.
- En cuestión de minutos, 1.096,31 cbETH fueron tomados por los liquidadores, 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 MIP-X43 de Moonwell, donde al cbETH de la cadena Base se le asignó erróneamente 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 exhaustivos de validación 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 tales malas configuraciones de alto impacto.
2. Incidente PearlDriver
Breve Resumen
El 19 de febrero de 2026, el contrato de curva de bonos NLAMM de PearlDriver en BSC fue explotado, resultando en aproximadamente $40,3K en pérdidas. 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 venderlos en los pools de liquidez de PearlDEX.
Antecedentes
PearlDriver utiliza una curva de bonos NLAMM (Creador de Mercado Automatizado No Lineal) para la acuñación de tokens. Los usuarios pueden comprar tokens de recursos del juego a través de 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 comprada. La curva de bonos se basa en el supuesto de que las compras más grandes requieren pagos correspondientemente 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 la 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 volcados inmediatamente 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 buy() vulnerable 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 cercano a cero, 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 parte del MINERAL DE HIERRO acuñado en su correspondiente par de liquidez de PearlDEX, recibiendo 7.805,55 USDT (~$7.805,56).
La misma secuencia de desbordamiento y venta se ejecutó contra los otros cuatro activos, drenando la liquidez de cada par activo-USDT y generando más de $40K en beneficio total.
Conclusión
Este incidente fue causado por aritmética sin verificación en la lógica de precios de la función buy() de 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 bonos.
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 tales 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+, particularmente en rutas de código que afectan precios o transferencias.
3. Incidente IoTex
Breve Resumen
El 21 de febrero de 2026, el puente ioTube de IoTeX sufrió una brecha de seguridad tras el compromiso de la clave propietaria 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 cross-chain 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 cross-chain y gestiona los contratos de acuñación descendentes. Estos incluyen TokenSafe, que mantiene los activos de reserva del puente, y MintPool, que posee la 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 multi-firma ni timelock, la posesión de esta clave otorgó control administrativo total. Usando 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 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 a través deMintPool. -
Intercambiar los tokens de reserva robados y transferirlos a otras cadenas.
Conclusión
Este incidente representa un compromiso de clave de punto único de falla 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 multi-firma ni salvaguardas de timelock. Una vez que la clave privada de la EOA fue comprometida, el control sobre los componentes críticos del puente se perdió efectivamente.
El caso destaca 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 cripto. Desarrollamos productos y servicios que ayudan a los clientes a realizar auditorías de código (incluyendo contratos inteligentes, blockchain y wallets), 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, 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
