diariobitcoin.com
El protocolo cross-chain Squid salió a aclarar públicamente su posición luego de que un contrato de terceros con un nombre muy similar al suyo quedara en el centro de un exploit que drenó cerca de USD $3,2 millones en las redes Ethereum y Base. La reacción del equipo buscó contener la confusión inicial generada por la denominación del contrato comprometido, identificado en Basescan como SquidRouterModule.
De acuerdo con los reportes citados por la cobertura original de BeInCrypto, el ataque impactó a 86 cuentas de Gnosis Safe en un lapso aproximado de dos horas. El episodio volvió a mostrar un riesgo recurrente dentro del ecosistema DeFi: la dependencia de módulos y contratos externos que, aunque pueden integrarse con protocolos conocidos, no necesariamente forman parte de su infraestructura principal.
Squid sostuvo que el contrato vulnerado compartía su nombre, pero no pertenecía a su código. El equipo también subrayó que ninguno de sus usuarios resultó afectado por el incidente. Esa precisión fue clave, ya que las primeras menciones públicas hacían referencia a “SquidRouter”, lo que llevó a algunos observadores a pensar que el router oficial del protocolo había sido comprometido.
Según explicó el propio proyecto, el encuadre correcto del hecho es que un módulo de terceros llamado SquidRouterModule fue explotado, no el contrato Router de Squid. La diferencia no es menor. En el ámbito de las finanzas descentralizadas, un nombre verificado en un explorador de bloques puede generar asociaciones inmediatas, incluso cuando el código, el despliegue y la responsabilidad operativa pertenecen a otra parte.
Qué pasó con el contrato comprometido
El contrato afectado llevaba el nombre SquidRouterModule en Basescan, lo que alimentó la confusión en las primeras horas del caso. Squid aseguró que no tuvo ningún papel en la escritura del contrato ni en su despliegue on-chain. En su explicación, describió el módulo como un producto de smart-wallet de terceros que se integraba con varios protocolos, incluido el suyo.
La aclaratoria apuntó a separar responsabilidades técnicas. El router legítimo de Squid, indicó el equipo, se encuentra en la dirección 0xce16F69375520ab01377ce7B88f5BA8C48F8D666 y opera bajo un diseño distinto. Ese contrato no fue afectado por el ataque, y según la empresa, los saldos existentes de los usuarios, las aprobaciones y las integraciones de la plataforma siguen seguros.
El matiz es importante para lectores menos familiarizados con el funcionamiento de los smart contracts. En Web3, un protocolo puede interactuar con servicios externos o ser integrado por terceros en billeteras, módulos o interfaces personalizadas. Eso no significa que cada componente conectado haya sido desarrollado, auditado o administrado por el equipo del protocolo principal.
En este caso, la falla estuvo en el módulo externo añadido como componente de confianza dentro de ciertos Safes. Cuando un módulo recibe ese nivel de permiso, puede ejecutar acciones sensibles sobre los fondos custodiados. Si su lógica contiene errores críticos, el problema deja de ser un simple bug y se convierte en una vía directa para el robo de activos.
Cómo funcionó el exploit, según Squid
Squid ofreció una explicación técnica del mecanismo que habría permitido el drenaje de fondos. Según detalló, el módulo de terceros aceptaba una cadena constante proporcionada por el llamador como prueba de que un mensaje era seguro. Esa cadena estaba disponible públicamente en el código verificado del contrato, por lo que cualquier actor podía reutilizarla.
Con ese dato, explicó el protocolo, un atacante podía ejecutar un arreglo de calldata arbitrario y robar fondos a voluntad. El problema se agravó porque los Safes de las víctimas habían agregado ese contrato defectuoso como un Safe Module de confianza. Bajo ese esquema, el contrato podía gastar cualquier token dentro del Safe sin requerir firmas adicionales.
Ese tipo de vulnerabilidad ayuda a entender por qué los módulos y permisos extendidos merecen tanta atención en seguridad blockchain. Las billeteras multisig como Gnosis Safe suelen ser herramientas robustas, pero sus garantías dependen también de los contratos complementarios que reciben autorización para operar sobre ellas.
Cuando un módulo externo obtiene acceso privilegiado, el riesgo no está solo en su función declarada, sino en toda la superficie de ataque de su implementación. Una validación débil, un parámetro predecible o un control mal diseñado puede ser suficiente para que un actor malicioso eluda el esquema de firmas y tome control efectivo de los activos.
El rastro de los fondos y las firmas de seguridad
Firmas de seguridad blockchain siguieron el movimiento de los activos robados poco después del exploit. Blockaid señaló que el atacante intercambió los tokens sustraídos por DAI mediante pools de Uniswap V3 controlados por el propio agresor. Ese detalle sugiere una operación planificada para consolidar liquidez y facilitar la gestión posterior de los fondos.
Por su parte, PeckShield reportó que el atacante fue financiado originalmente con ETH 2,1 procedentes de Tornado Cash. Además, indicó que la billetera del explotador, identificada como 0xA447…54859, contenía los activos sustraídos. Esos datos no cierran por sí mismos la atribución del caso, pero sí ofrecen pistas útiles sobre el flujo del dinero y la preparación previa del ataque.
El uso de mezcladores como Tornado Cash sigue apareciendo con frecuencia en incidentes de alto perfil dentro del ecosistema. Para los analistas, ese tipo de financiamiento inicial puede ayudar a cubrir huellas tempranas, aunque la trazabilidad on-chain muchas veces permite reconstruir buena parte del recorrido posterior de los fondos.
También llama la atención la rapidez con la que los investigadores detectaron el exploit y mapearon las cuentas afectadas. En un entorno donde los ataques se ejecutan en minutos, la capacidad de respuesta de las firmas de monitoreo y de los propios protocolos resulta decisiva para limitar daños reputacionales y ofrecer contexto preciso a la comunidad.
Un mes cargado de incidentes en DeFi
El caso de SquidRouterModule no ocurrió en aislamiento. La noticia se suma a una racha de incidentes que han golpeado al sector cripto durante mayo de 2026. Según datos de DefiLlama citados en la cobertura original, el mes ya acumulaba más de 20 exploits al momento del reporte.
Esa cifra refuerza una preocupación persistente en torno a la seguridad de las finanzas descentralizadas. Aunque el ecosistema ha avanzado en auditorías, monitoreo en tiempo real y mejores prácticas de desarrollo, la complejidad composable de DeFi sigue abriendo puertas a errores en integraciones, permisos y módulos auxiliares.
Para usuarios e instituciones, el aprendizaje es claro. No basta con evaluar la reputación de un protocolo principal. También conviene revisar qué contratos externos han sido autorizados, qué funciones pueden ejecutar y si esos componentes fueron auditados de manera independiente. En muchos casos, el eslabón débil no está en la aplicación más visible, sino en piezas secundarias que operan con privilegios elevados.
Por ahora, la postura de Squid es que su router oficial no fue comprometido y que sus usuarios no sufrieron afectaciones. Sin embargo, el episodio muestra cómo una simple similitud de nombres puede amplificar la confusión en medio de un ataque y por qué la seguridad operativa en Web3 depende tanto del código propio como de las conexiones de terceros.
ADVERTENCIA: DiarioBitcoin ofrece contenido informativo y educativo sobre diversos temas, incluyendo criptomonedas, IA, tecnología y regulaciones. No brindamos asesoramiento financiero. Las inversiones en criptoactivos son de alto riesgo y pueden no ser adecuadas para todos. Investigue, consulte a un experto y verifique la legislación aplicable antes de invertir. Podría perder todo su capital.