Exploit de contabilidad de pools de mySwap con token falso

El 19 de junio de 2026, mySwap —un AMM de liquidez concentrada en Starknet— sufrió un exploit por aproximadamente 305.000 dólares después de que un atacante abusara de la lógica contable de los pools con un token sin valor. El drenaje comenzó hacia las 07:15 UTC y vació casi por completo la liquidez restante guardada en la bóveda compartida del protocolo.

Qué ocurrió

El atacante desplegó un token falso llamado EVIL y lo usó para distorsionar la ruta contable que vincula los pools de liquidez concentrada (CL) de mySwap con su bóveda compartida. Como la contabilidad de la bóveda confiaba en los saldos reportados a través de un token controlado por el atacante, una interacción sin permisos le permitió inflar su reclamación y retirar activos reales que otros proveedores de liquidez habían aportado. Los rastreadores on-chain cifraron el botín en aproximadamente 137,96 ETH, 45.000 USDC, 19.900 USDT y 230.000 STRK. Es clave que la interfaz de mySwap llevaba más de seis meses cerrada a nuevos depósitos de liquidez, por lo que los saldos drenados eran en su mayoría posiciones LP residuales repartidas en más de 100.000 posiciones inactivas —una superficie latente que nadie vigilaba activamente—. Luego el atacante transfirió las ganancias fuera de Starknet y las hizo pasar por Railgun para romper el rastro on-chain.

Consecuencias

El exploit retiró casi toda la liquidez restante de los pools afectados. Como los fondos se lavaron rápidamente a través de Railgun, no se había reportado ninguna recuperación al momento de redactar esto, ni hubo devolución white-hat ni acuerdo negociado. El incidente subraya cómo un protocolo prácticamente liquidado —pero cuyos contratos siguen activos y reteniendo fondos residuales de usuarios— sigue siendo un objetivo permanente mucho después de que su equipo haya seguido adelante.

Por qué importa

mySwap recuerda que los contratos DeFi latentes no son contratos muertos: mientras una bóveda retenga valor y acepte interacciones sin permisos, su contabilidad es una superficie de ataque aunque el front-end esté apagado. El vector del token falso refleja a BnbLabubu, donde un parámetro de token manipulado activó la matemática que vació un par de PancakeSwap, y se suma a zkLend como otro protocolo de Starknet derribado por una contabilidad interna explotable en lugar de un primitivo criptográfico roto. Para los AMM, el pool residual más seguro es aquel cuyos contratos han sido vaciados o congelados por completo: la liquidez sobrante en una bóveda obsoleta es un pasivo, no un legado.