Autor: ZeroDrift
Puntos clave
- DxSale fue el caso con las mayores pérdidas, donde el atacante robó aproximadamente 7.3 millones de dólares.
- El problema no radica en un tipo específico de vulnerabilidad, sino en el retiro incompleto de contratos antiguos, que aún conservan valor económico y permisos operativos.
Según un análisis publicado por ZeroDrift el 22 de junio de 2026, en los últimos 40 días, atacantes han robado aproximadamente 16.9 millones de dólares de cinco contratos inteligentes que, aunque habían sido abandonados, seguían ejecutándose en la cadena de bloques.
Lo que se denomina "contrato abandonado" no equivale a "contrato inactivo". Muchos contratos, aunque ya no son desarrollados ni mantenidos activamente por el equipo, siguen desplegados en la cadena y pueden recibir fondos, ejecutar transacciones o mover activos. Mientras conserven fondos, autorizaciones o puntos de entrada invocables, seguirán siendo objetivos para los atacantes.
Estos incidentes ocurrieron de forma concentrada entre el 7 de mayo y el 15 de junio de 2026. TrustedVolumes perdió aproximadamente 5.87 millones de dólares, el pool V1 de Huma Finance perdió unos 101,000 dólares, DxSale V1 Locker perdió unos 7.3 millones de dólares, el pool AMM Legacy de Raydium perdió aproximadamente 1.34 millones de dólares, y Aztec Connect perdió unos 2.28 millones de dólares en dos ataques consecutivos.
Gráfico: Pérdidas acumuladas en cinco incidentes relacionados con contratos abandonados en 40 días. Fuente: ZeroDrift / X.
Los contratos que nadie supervisa aún pueden controlar fondos
El caso de DxSale es especialmente representativo. Su antiguo contrato "locker" se utilizaba originalmente para bloquear liquidez a largo plazo, garantizando que los fondos no se pudieran retirar antes del plazo establecido. Sin embargo, el riesgo de este tipo de sistemas proviene precisamente de su propósito de diseño: están diseñados para custodiar valor a largo plazo.
Con el tiempo, la atención del equipo se desplaza hacia nuevos productos, las reglas de monitoreo se debilitan, el personal de mantenimiento cambia, y las viejas rutas de permisos y suposiciones históricas caen gradualmente en el olvido. ZeroDrift señala que, en el incidente de DxSale, una ruta de control antigua volvió a estar disponible, lo que permitió que se retirara liquidez que debería haber estado bloqueada.
Los cinco incidentes no son una reutilización de la misma vulnerabilidad. Ocurrieron en sistemas, arquitecturas y cadenas de bloques diferentes, involucrando componentes como liquidación RFQ, pools de crédito, LP locker, AMM y salidas de rollup.
Lo que realmente tienen en común es el estado subyacente: estos contratos ya no son el foco de desarrollo activo de los equipos, pero aún conservan valor económico en la cadena.
El análisis automatizado está amplificando el riesgo de los contratos antiguos
Los contratos antiguos son naturalmente adecuados para ser rastreados por herramientas automatizadas: su código es público, su historial en cadena está completo, su monitoreo es débil y a menudo conservan suposiciones de seguridad obsoletas. En el pasado, buscar sistemáticamente estos objetivos de larga cola requería un coste manual considerable; ahora, la búsqueda por similitud de código, la simulación de transacciones, el análisis de datos en cadena y la revisión asistida por IA están reduciendo el coste de este tipo de búsquedas.
ZeroDrift también enfatiza que actualmente no hay evidencia pública de que la IA haya participado en estos cinco ataques específicos. Lo que realmente merece atención es el cambio en la estructura de costes: cada vez es más fácil para los atacantes escanear sistemáticamente "los productos de ayer", mientras que la parte defensora aún no gestiona de manera igualmente sistemática "las responsabilidades de ayer".
La industria de la seguridad DeFi ha desarrollado procesos de auditoría previos al lanzamiento relativamente maduros, pero la salida, migración y retiro de contratos aún carece de una disciplina igualmente estricta. Un contrato no se vuelve seguro automáticamente porque el equipo deje de mantenerlo. Solo cuando se eliminan los fondos, permisos, autorizaciones, puntos de entrada y suposiciones de confianza, puede considerarse realmente retirado.
