Escrito por: Gino Matos
Compilado por: Luffy, Foresight News
TL;DR:
- Un hacker explotó un grupo de liquidez V3 del creador de mercado automático de Raydium, que había estado fuera de servicio durante mucho tiempo, robando activos por valor de aproximadamente 1,34 millones de dólares.
- Este incidente expone un problema general: los contratos antiguos que los proyectos DeFi han dado de baja siguen funcionando en la cadena. Esta infraestructura olvidada se ha convertido en un objetivo de ataque fácil de pasar por alto.
- Informes públicos muestran que desde marzo de 2025, ha habido al menos 8 incidentes similares de robo en contratos antiguos y obsoletos en la industria, lo que significa que aún existe una gran cantidad de código antiguo sin mantenimiento que puede ser invocado externamente.
Recientemente, una vulnerabilidad en el creador de mercado automático (AMM) V3 de Raydium resultó en una pérdida de 1,34 millones de dólares. Este incidente estuvo relacionado con cinco grupos de liquidez fuera del sistema de productos actual del proyecto, que no son compatibles con la interfaz de usuario (UI) o el SDK de Raydium y a los que los usuarios normales no pueden acceder, pero que finalmente fueron explotados por un hacker.
Este ataque apuntó a contratos e infraestructura antigua y descuidada en la industria, revelando una importante brecha en la gestión del ciclo de vida completo de los contratos inteligentes. Este tipo de problema no es exclusivo de este intercambio descentralizado del ecosistema Solana.
Una Categoría de Riesgo Pasada por Alto
Según estadísticas de informes públicos de incidentes de seguridad, desde marzo de 2025 hasta ahora, ha habido al menos 8 casos confirmados de ataques dirigidos a contratos obsoletos, retirados o antiguos, con pérdidas acumuladas de aproximadamente 10,8 millones de dólares.
Si se incluyen en las estadísticas los incidentes de seguridad causados por grupos de liquidez antiguos y productos complementarios de versiones anteriores, la cantidad de incidentes relacionados alcanza los 10 (incluyendo este robo de Raydium), con un total de pérdidas de aproximadamente 22,5 millones de dólares.
La mayoría de las plataformas de seguimiento de incidentes de seguridad en la industria clasifican los tipos de ataque según su causa técnica. Las clasificaciones comunes incluyen: vulnerabilidades en el código de los contratos inteligentes, fallos en el control de permisos, manipulación de oráculos, filtraciones de claves privadas, defectos en puentes cruzados, etc.
Los contratos zombis (es decir, contratos antiguos que los proyectos anuncian como fuera de servicio pero que aún se pueden invocar normalmente en la cadena) pertenecen a una dimensión de riesgo completamente diferente. Son incidentes de seguridad causados por problemas en la gestión del ciclo de vida del contrato, pero siempre han quedado enterrados en las estadísticas de varias vulnerabilidades convencionales y no se han clasificado por separado.
La razón por la que se abandonaron los grupos de liquidez del creador de mercado automático V3 de Raydium fue el cierre oficial del proyecto Serum del que dependían, lo que dejó a estos contratos antiguos completamente sin su funcionalidad original y los activos de liquidez correspondientes inactivos en la cadena.
Los nuevos contratos que Raydium utiliza actualmente verifican dos veces información clave: primero, verifican la proporción de activos a través de un mecanismo de verificación de suministro total; segundo, verifican la dirección de acuñación de los tokens de liquidez y la información de varias cuentas relacionadas.
Pero este conjunto antiguo de contratos V3 omite por completo estos dos procesos de verificación. El hacker explotó esta vulnerabilidad para falsificar nuevos tokens de liquidez haciéndolos pasar por certificados legítimos, evadiendo así todas las reglas de control de riesgos.
En este incidente, se robaron aproximadamente 150,177 RAY, 5,603 SOL y 893,700 USDC. Estos activos habían estado depositados durante mucho tiempo en los antiguos grupos de liquidez de la plataforma. Aunque estaban fuera del negocio principal, los permisos de invocación en cadena nunca se cerraron.
Ocho Casos Expusieron Problemas Comunes
Desde 2025, varios proyectos DeFi conocidos han tenido problemas con contratos antiguos. Todos los incidentes presentan las mismas características: los equipos de los proyectos declaran que las versiones actuales de sus productos y los usuarios activos no se ven afectados, pero debido a que los contratos antiguos no se cerraron por completo, las pérdidas totales finalmente fueron cubiertas por las tesorerías de los proyectos.
Por Qué Se Pasa por Alto el Riesgo de los Contratos Antiguos
En la actualidad, la gran mayoría de los sistemas de clasificación de incidentes de seguridad en la industria se centran en los métodos de ataque, los objetos manipulados y los puntos de falla del código, lo que representa una perspectiva de análisis "desde la vulnerabilidad técnica". Esto también provoca que los incidentes de contratos zombis queden enmascarados. El núcleo de este tipo de problemas nunca ha sido un error en la escritura del código, sino que los proyectos deberían haber cerrado completamente los contratos antiguos y no lo hicieron.
Un documento de investigación de la industria de 2025 analizó 50 grandes incidentes de seguridad criptográficos a nivel mundial entre 2022 y 2025, con pérdidas acumuladas superiores a los 1.000 millones de dólares. El estudio señaló que los ataques en cadena de alto daño suelen ser el resultado de la superposición de riesgos en cadena, involucrando simultáneamente múltiples niveles como las operaciones manuales, el mantenimiento diario, los modelos económicos, el ciclo de vida de los contratos, la gobernanza comunitaria, etc.
El documento propone un marco de análisis de causas raíz de cuatro niveles, clasificando claramente las vulnerabilidades en la gestión del ciclo de vida del contrato y las vulnerabilidades en la gobernanza comunitaria como categorías de riesgo independientes de las vulnerabilidades en la escritura del código. Y el problema de los contratos zombis es precisamente una vulnerabilidad típica de la gestión del ciclo de vida. Pero en los sistemas de estadísticas de seguridad existentes, este tipo de incidentes se clasifican invariablemente como "vulnerabilidades de código", y sus datos de pérdidas correspondientes también se ocultan bajo otras clasificaciones, sin haber llamado la suficiente atención de la industria.
Alerta con el "Cementerio de Contratos": La Infraestructura Antigua se Ha Convertido en un Nuevo Punto de Ataque
Si los proyectos DeFi siguen considerando el "cierre de contratos" como algo insignificante y opcional, limitándose a marcar en la documentación del producto que "este contrato está fuera de servicio" sin transferir los activos inactivos, cerrar las funciones de invocación y monitorear continuamente su estado, los hackers seguirán apuntando a este "cementerio de contratos".
Cada registro histórico de despliegue de un gran proyecto DeFi se ha convertido ahora en un objetivo de ataque que los hackers pueden buscar y explotar. Las pérdidas de 22,5 millones de dólares actualmente estadísticas son solo el valor de los casos expuestos públicamente; el riesgo real es mucho mayor.
Los antiguos grupos de liquidez, las interfaces de autorización históricas y los módulos de integración de cooperación temprana que contienen activos pero están desconectados del flujo de uso principal de los usuarios, reciben mucho menos monitoreo y mantenimiento que los sistemas comerciales activos, convirtiéndose precisamente en el objetivo preferido de los hackers.
Para cambiar esta situación, primero hay que clasificar los "contratos zombis" como una categoría de riesgo independiente y realizar estadísticas separadas de incidentes. En segundo lugar, hay que incorporar el proceso de retirada de contratos en los flujos de seguridad estandarizados, dándole la misma importancia que a las auditorías de código. Solo realizando un mantenimiento completo del ciclo de vida se puede reducir eficazmente el alcance de los ataques.
Actualmente, la forma de abordar el problema es similar en toda la industria. Raydium utilizó la tesorería del proyecto para compensar las pérdidas de 1,34 millones de dólares; Transit Finance y Huma Finance también asumieron las pérdidas de los usuarios con los fondos del proyecto.
Esto también significa que la retirada de contratos ya no es solo un trabajo de anotación en la documentación, sino un eslabón esencial de control de seguridad.
Siete Estándares de Control de Seguridad para la Retirada de Contratos
Para el cierre de contratos antiguos, la industria puede establecer un proceso de control estandarizado. Los requisitos específicos y sus funciones son los siguientes:
Simplemente marcar en la documentación que "el contrato está fuera de servicio" solo transfiere el riesgo de seguridad a la tesorería del proyecto, mientras que el riesgo de ataque sigue existiendo. Anunciar la retirada solo a nivel de producto sin cerrarlo completamente a nivel técnico hace que el contrato antiguo permanezca en un estado invocable: el equipo del proyecto lo descuida, pero los hackers lo observan atentamente en todo momento.
El valor de los proyectos DeFi no solo se refleja en el volumen actual de activos bloqueados, sino que también se sedimenta en el código histórico y la arquitectura subyacente acumulados a lo largo del camino. Y esta historia olvidada se ha convertido ahora en una nueva brecha de seguridad.
