~$15.9M Perdidos: Trusted Volumes, Wasabi y Más | BlockSec Semanal

Durante las últimas dos semanas (2026/04/27 - 2026/05/10), BlockSec identificó múltiples incidentes de ataque en varios ecosistemas blockchain. La siguiente tabla lista 11 incidentes notables con pérdidas totales estimadas de aproximadamente $15.9M.

Se seleccionaron tres incidentes para un análisis en profundidad basado en la novedad del ataque, el impacto financiero y las implicaciones de seguridad:

• Aftermath Finance: una explotación en el mundo real sobre un DEX de futuros perpetuos, donde una sutil discrepancia semántica con/sin signo en la validación de comisiones condujo al drenaje completo de los fondos del protocolo.
• Trusted Volumes: impacto financiero significativo (~$5.87M) y una demostración clara de la discrepancia de autorización en la lógica de liquidación RFQ.
• Wasabi Protocol: un compromiso de infraestructura hacia el control del contrato, una clase de ataque cada vez más común pero infrarepresentada en los alcances de auditoría.

Destacado de la Semana: Aftermath Finance

Este incidente se destaca porque la discrepancia semántica con/sin signo es una clase de vulnerabilidad sutil que va más allá de cualquier protocolo individual. Cualquier protocolo DeFi que utilice una biblioteca de punto fijo con signo para validar valores de comisiones o precios sin signo es susceptible al mismo patrón de ataque, lo que hace que este exploit sea ampliamente instructivo tanto para desarrolladores como para auditores.

El 29 de abril de 2026, Aftermath Perpetuals, un exchange de futuros perpetuos on-chain en Sui, fue explotado por aproximadamente $1.14M en USDC [1]. La causa raíz fue una discrepancia semántica con/sin signo en la validación de la comisión del builder del protocolo: la función de comparación de comisiones realizaba aritmética con signo sobre valores sin signo, lo que permitía a un atacante enviar un valor de comisión que parecía negativo bajo interpretación con signo. Durante la liquidación, la comisión negativa se convertía en un crédito de garantía positivo, lo que permitía al atacante retirar fondos inflados de la bóveda del protocolo.

Antecedentes

Aftermath Perpetuals es un exchange de futuros perpetuos on-chain en Sui [2]. El protocolo permite a los integradores externos ganar comisiones de trading construyendo interfaces de front-end. Cada integrador establece una tasa de comisión (taker_fee) que se cobra a los traders que usan su interfaz [3]. Como medida de seguridad, los traders pueden aprobar a los integradores configurando un límite máximo de tasa de comisión preestablecido (maxTakerFee) que limita cuánta comisión puede cobrar un integrador.

Al ejecutar una orden de mercado, el protocolo primero compara taker_fee con maxTakerFee para asegurarse de que la comisión se mantenga dentro del límite aprobado por el trader, luego deduce la comisión calculada de la garantía del tomador y la acredita en los registros del integrador.

La aritmética del protocolo está construida sobre una biblioteca de punto fijo con signo (ifixed), que representa los valores como enteros u256 pero los interpreta bajo semántica de complemento a dos para las operaciones de comparación y aritmética.

Análisis de la Vulnerabilidad

Los contratos con errores incluyen el módulo de interfaz (0x9e2080...25d136) y el módulo de la cámara de compensación (0x21d001...7c5068).

La vulnerabilidad reside en la función calculate_taker_fees(), que utiliza ifixed::less_than_eq() para comparar el taker_fee del integrador contra el maxTakerFee del trader:

assert!(
    ifixed::less_than_eq(
        v5.taker_fee,
        account::get_integrator_max_taker_fee(
            account::get_integrator_config(arg1, v5.integrator_address)
        )
    ),
    errors::invalid_integrator_taker_fee()
);

Tanto taker_fee como maxTakerFee son semánticamente tasas de comisión no negativas. Sin embargo, ifixed::less_than_eq() realiza una comparación con signo sobre u256. Cuando maxTakerFee se establece en 0, un valor como 2^256 - 10^16 se interpreta bajo semántica con signo como -10^16. Dado que -10^16 <= 0 se cumple, la verificación pasa.

La ruta de explotación queda aún más expuesta porque create_integrator_info() es públicamente invocable y no aplica ninguna validación de permisos ni de límite de comisión sobre el taker_fee proporcionado:

public fun create_integrator_info(arg0: address, arg1: u256): Option<IntegratorInfo> {
    let v0 = IntegratorInfo {
        integrator_address : arg0,
        taker_fee          : arg1,
    };
    option::some<IntegratorInfo>(v0)
}

La comisión negativa no solo es aceptada; se transforma en un crédito de garantía positivo directo durante la liquidación. En la ruta de liquidación, la garantía se actualiza como collateral += pnl - taker_fee - builder_fee. Cuando builder_fee es negativo, restarla se convierte en una suma:

position::add_to_collateral_usd(
    arg0,
    ifixed::sub(v6, ifixed::add(v7, v8)),
    arg2
);

Ni la validación de comisiones ni la aritmética de liquidación exigen que los valores de comisión sean no negativos, por lo que las dos verificaciones faltantes se combinan: la comparación con signo permite que el valor negativo entre, y la aritmética con signo lo convierte en un crédito de garantía.

Análisis del Ataque

El siguiente análisis se basa en la transacción 4pGQdf...wVD8.

• Paso 1: El atacante dividió 100e6 USDC en dos cuentas perpetuas nuevas, 1227 y 1228. Esto creó contextos aislados para que el atacante pudiera actuar como maker (cuenta 1227) y taker (cuenta 1228).

• Paso 2: El atacante depositó 100e6 USDC como garantía en la cuenta 1227 y abrió una posición de mercado, estableciendo una contraparte para la próxima orden de taker.

• Paso 3: El atacante creó una bóveda de integrador, luego añadió una configuración a la cuenta 1228 con maxTakerFee = 0. Establecer el límite en cero fue esencial: hizo que la comparación con signo taker_fee <= 0 aceptara cualquier valor que apareciera negativo bajo el complemento a dos.

• Paso 4: El atacante inició una sesión desde la cuenta 1227 y publicó una orden limitada con order_size = 100e6, proporcionando la liquidez contra la que operaría la cuenta 1228.

• Paso 5: El atacante invocó create_integrator_info() con taker_fee = 2^256 - 100e6, un valor que representa -100e6 bajo la semántica ifixed con signo. Dado que la función es pública y no realiza ninguna validación, la llamada tuvo éxito.

• Paso 6: El atacante ejecutó una orden de mercado desde la cuenta 1228 usando la información de integrador maliciosa. La comparación de comisión con signo pasó (-100e6 <= 0), y durante la liquidación la comisión negativa se restó de la garantía, efectivamente añadiendo 100e6 en garantía gratuita a la cuenta 1228.

• Paso 7: El atacante desasignó y retiró la garantía inflada de la cuenta 1228, obteniendo 79,610 USDC. El atacante repitió este patrón en múltiples transacciones para acumular aproximadamente $1.14M en total.

Conclusión

Este incidente fue causado por una discrepancia semántica con/sin signo en la validación de la comisión del builder de Aftermath Perpetuals. El problema central es que la función de comparación de comisiones (ifixed::less_than_eq) interpreta los valores de comisión sin signo bajo semántica con signo. Cuando se combina con una función de configuración de comisiones públicamente invocable que no realiza ninguna validación de límites, un atacante puede inyectar un valor que pasa la comparación con signo como "negativo" y luego se convierte en un crédito de garantía durante la liquidación.

El patrón más amplio merece atención: cualquier protocolo que utilice una biblioteca de punto fijo con signo para validar valores inherentemente no negativos (comisiones, precios, cantidades) es vulnerable a la misma clase de ataque. Las mitigaciones deben incluir: (1) asegurar que los valores de comisión sean no negativos antes de cualquier comparación (assert!(taker_fee >= 0)), (2) restringir create_integrator_info() a llamantes autorizados, y (3) usar funciones de comparación sin signo para valores que son semánticamente sin signo.

Referencias

• [1] Declaración Post-Incidente de Aftermath Finance
• [2] Documentación de Aftermath Perpetuals
• [3] Códigos de Builder / Comisión de Front-End

Más Incidentes de Este Período

Trusted Volumes

El 7 de mayo de 2026, un contrato proxy RFQ (Solicitud de Cotización) personalizado en Ethereum fue explotado, drenando aproximadamente $5.87M del creador de mercado TrustedVolumes. La causa raíz fue una discrepancia de autorización en la función de llenado de órdenes del contrato de implementación RFQ: la búsqueda de permisos del firmante y la operación de transferencia de tokens referenciaban diferentes campos de la orden, por lo que la verificación de autorización pasó en una dirección mientras los fondos se debitaban de otra. El atacante drenó aproximadamente 1,291 WETH, 206K USDT, 16.94 WBTC y 1.27M USDC.

Antecedentes

TrustedVolumes opera como creador de mercado en el protocolo RFQ desplegado en Ethereum. Los creadores de mercado generan continuamente cotizaciones de precios firmadas fuera de la cadena; los tomadores (típicamente traders o routers de agregadores) envían una cotización elegida en cadena, y el contrato del protocolo verifica la firma y liquida atómicamente el trade moviendo tokens entre el maker y el taker mediante transferFrom. El protocolo sigue un diseño sin bóveda: nunca custodia fondos. Cada maker pre-otorga al contrato del protocolo una aprobación ERC-20 para cada token en el que pretende cotizar, y el protocolo extrae los tokens directamente de la billetera del maker en el momento del llenado.

Para permitir a los makers delegar la operación de firma a una billetera caliente, el contrato del protocolo mantiene un registro de firmantes por maker. Un maker puede llamar a registerAllowedOrderSigner(signer, allowed) para incluir en la lista blanca una clave caliente, y cualquier orden posterior firmada por esa clave se acepta como si hubiera sido firmada por el maker.

Análisis de la Vulnerabilidad

El contrato proxy RFQ está desplegado en 0xeEeEEe...051756, y el contrato de implementación está en 0x88eb28...2760d8.

La función de llenado de órdenes 0x4112e1c2() en el contrato de implementación RFQ recupera el firmante mediante ecrecover() y verifica el mapeo allowedOrderSigner para decidir si acepta la firma. La clave de búsqueda para esta verificación es varg4, la dirección del lado del taker de la orden. Sin embargo, el subsiguiente transferFrom que debita fondos usa varg5, el campo maker de la orden. Dado que varg4 y varg5 son campos independientes del struct de la orden, la verificación de autorización y la operación de flujo de fondos referencian diferentes partes. Ninguna verificación exige que el dominio del firmante autorizado coincida con la dirección de la que realmente se extraen los tokens.

La función registerAllowedOrderSigner escribe la lista blanca bajo msg.sender como clave externa, mientras que la ruta de llenado lee bajo varg4 como clave externa. Siempre que el llamante en varg4 se haya registrado previamente mediante registerAllowedOrderSigner, la verificación de autorización tiene éxito independientemente de qué dirección de maker de terceros aparezca en varg5.

Análisis del Ataque

El siguiente análisis se basa en la transacción 0xc5c61b...990513.

• Paso 1: El atacante desplegó un contrato de ataque y llamó a registerAllowedOrderSigner a través de él, registrando la EOA del atacante en la lista blanca de firmantes permitidos. Esto aseguró que las órdenes firmadas por el atacante pasaran la verificación de autorización del firmante del protocolo.

• Paso 2: El contrato de ataque extrajo 4 wei de USDC de la EOA del atacante y aprobó 4 wei al protocolo RFQ, equipando al contrato de ataque con la consideración mínima necesaria para actuar como taker.

• Paso 3: El atacante falsificó cuatro órdenes, cada una firmada por la EOA del atacante y nombrando a TrustedVolumes como maker. Dado que la verificación del firmante consultaba varg4 (el contrato del atacante) mientras que transferFrom debitaba de varg5 (TrustedVolumes), cada orden drenaba fondos de TrustedVolumes. Las cuatro órdenes intercambiaron 1 wei de USDC por 1,291 WETH, 206,282 USDT, 16.939 WBTC y 1,268,771 USDC respectivamente, con un beneficio total de aproximadamente $5.87M.

Conclusión

El defecto central es una discrepancia de autorización en la función de llenado de órdenes: la dirección utilizada para la verificación de permisos del firmante difiere de la dirección que realmente paga. Específicamente, registerAllowedOrderSigner escribe la lista blanca bajo msg.sender, la ruta de llenado lee bajo el campo del taker (varg4), y transferFrom debita del campo del maker (varg5). Dado que estas tres operaciones referencian diferentes partes, cualquier atacante que registre su propio firmante puede falsificar órdenes que drenen a un maker de terceros. Las verificaciones de autorización que controlan el movimiento de activos deben estar vinculadas a la dirección que realmente va a pagar, y la ruta de escritura y la ruta de lectura deben usar la misma clave.

Wasabi Protocol

El 30 de abril de 2026, Wasabi Protocol, un protocolo de opciones y futuros perpetuos desplegado en múltiples cadenas EVM, sufrió un incidente de seguridad que resultó en aproximadamente $5.7M en pérdidas ($4.8M en fondos de usuarios, $900K del tesoro de Wasabi) [1][2]. El ataque se originó en un compromiso de infraestructura: un endpoint de análisis expuesto en un servidor público filtró credenciales que finalmente llevaron al robo de claves privadas que controlaban los contratos inteligentes EVM del protocolo. Usando esas claves, el atacante ejecutó retiros no autorizados de múltiples bóvedas de Wasabi en Ethereum, Base, Blast y Berachain.

Antecedentes

Wasabi Protocol opera despliegues en cadenas EVM (Ethereum, Base, Blast, Berachain) y Solana. Este incidente se limitó al lado EVM del protocolo; los despliegues en Solana y el Prop AMM no se vieron afectados.

Los contratos EVM de Wasabi (WasabiLongPool, WasabiShortPool, WasabiVault) son administrados mediante claves privilegiadas. El protocolo también ejecuta infraestructura off-chain que incluye servicios de análisis y monitoreo construidos sobre Spring Boot.

Análisis del Ataque

El incidente siguió una cadena de compromiso de infraestructura hacia el control del contrato:

• Paso 1: El atacante descubrió que Spring Boot Actuator estaba instalado en un servidor de Wasabi orientado al público. Los volcados de memoria de Actuator normalmente están protegidos con contraseña, pero este servidor usaba una variante diferente del framework Spring que era incompatible con el mecanismo estándar de protección por contraseña, dejando el endpoint de volcado de memoria expuesto.

• Paso 2: El atacante recuperó el volcado de memoria, que contenía credenciales para un servidor interno separado.

• Paso 3: Usando las credenciales filtradas, el atacante pivotó al servidor interno y obtuvo las claves privadas que controlan los contratos inteligentes EVM de Wasabi.

• Paso 4: Con las claves privilegiadas en mano, el atacante ejecutó flujos de retiro no autorizados contra los contratos WasabiLongPool, WasabiShortPool y WasabiVault en Ethereum, Base, Blast y Berachain, drenando aproximadamente $5.7M en total.

Conclusión

Este incidente demuestra que la seguridad de los contratos inteligentes no termina en el nivel del código. El exploit no requirió ninguna vulnerabilidad on-chain; el atacante obtuvo el control puramente a través de la exposición de la infraestructura. Las lecciones clave son: (1) las superficies de depuración y análisis (volcados de memoria, endpoints de perfilado, exportadores de registros) nunca deben ser accesibles en infraestructura pública, (2) las credenciales para sistemas de producción deben estar estrictamente segmentadas de los entornos de análisis y monitoreo, y (3) las claves de administración de contratos inteligentes deben protegerse con controles de defensa en profundidad que incluyan custodia multifirma, firma respaldada por hardware, separación de roles, monitoreo en tiempo real y procedimientos de pausa de emergencia.

Referencias

• [1] Alerta de BlockSec Phalcon
• [2] Declaración Post-Incidente de Wasabi Protocol

Acerca de BlockSec

BlockSec es un proveedor integral de seguridad blockchain y cumplimiento cripto. Construimos 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 del ciclo de vida completo de los 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

• 🔗 Phalcon Security APP: Reservar una demo

• 🔗 Phalcon Compliance