Delegatecall multi-firma en UXLINK

En septiembre de 2025, el protocolo social Web3 con sabor a IA UXLINK perdió aproximadamente $41 millones tras que los atacantes comprometieran la billetera multi-firma del proyecto y usaran un delegatecall en un contrato privilegiado para extraer fondos de la tesorería.

Qué ocurrió

Las funciones de tesorería y admin de UXLINK estaban controladas por una billetera multi-firma. Los atacantes obtuvieron las claves privadas de esa billetera — el vector específico no fue divulgado públicamente, pero el patrón on-chain (firmado por los firmantes legítimos, sin artefactos de engaño de UI) es consistente con un compromiso directo de claves más que con un ataque basado en el frontend.

Una vez que tenían las claves, explotaron un delegatecall sin restricciones en un contrato privilegiado. Debido a que delegatecall ejecuta el código del contrato objetivo en el contexto de almacenamiento del llamante, el atacante podía llamar a un contrato que controlaba y hacerlo correr con los privilegios de la multi-firma confiada — moviendo cualquier activo, otorgando cualquier rol, llamando a cualquier función externa.

Consecuencias

• UXLINK pausó la multi-firma y disparó una migración de token de emergencia.
• El equipo publicó un post-mortem y rotó todas las claves administrativas.
• Los fondos fueron blanqueados a través de puentes cross-chain.

Por qué importa

delegatecall sigue siendo una de las primitivas más peligrosas en el diseño de la EVM — regularmente convierte un contrato que debería ser inerte en un shell de ejecución totalmente programable para el llamante. La mejor práctica es nunca exponer un delegatecall privilegiado con objetivo/calldata controlables por el atacante. UXLINK es uno de varios incidentes de 2025 que reafirmaron la regla.