El 2026-06-25, la plataforma de mercados de predicción Polymarket confirmó que unos atacantes habían robado alrededor de 3 millones de dólares a un pequeño número de usuarios. El investigador on-chain Specter, que detectó por primera vez el robo, rastreó unos 2,94 millones de dólares sustraídos de al menos 11 monederos; la firma de analítica blockchain Bubblemaps situó el total en menos de 15 cuentas y publicó las direcciones implicadas. Polymarket contuvo el incidente con rapidez, eliminó la dependencia responsable y se comprometió a reembolsar por completo a cada usuario afectado.
Para cualquiera que gestione un sitio web por el que circula dinero o datos sensibles, el detalle que importa es dónde ocurrió el ataque. Los smart contracts de Polymarket nunca se vieron comprometidos. La blockchain funcionó exactamente como estaba diseñada. El robo ocurrió en el navegador, a través de un script de terceros en el que la plataforma confiaba. Este es un ataque de cadena de suministro del lado del cliente de manual, la misma clase de ataque que golpea cada semana a las páginas de pago de e-commerce, las páginas de inicio de sesión de fintech y los paneles SaaS.
La mecánica importa, porque explica por qué tantos equipos están expuestos al mismo riesgo.
Qué ocurrió
En su propio comunicado, Polymarket dijo que había "descubierto que un proveedor externo había sido comprometido, inyectando un script malicioso en nuestro frontend para algunos usuarios", y que había contenido el incidente y eliminado la dependencia afectada. Al momento de la publicación, ni Polymarket ni los reportes independientes han identificado el proveedor o la dependencia comprometida.
El objetivo era pUSD, la stablecoin de Polymarket respaldada por USDC y el principal colateral de trading de la plataforma. Cuando los usuarios afectados conectaron sus monederos, el código inyectado les indujo a firmar o aprobar transacciones que, de forma silenciosa, entregaban fondos al atacante. La firma de seguridad PeckShield informó de que el pUSD robado se transfirió de Polygon a Ethereum y se intercambió por alrededor de 1893 ETH, que los investigadores rastrearon hasta una única dirección de consolidación. Varias firmas clasificaron el evento como un compromiso de cadena de suministro combinado con una campaña de phishing que operó a través de la propia interfaz de la plataforma.
La mecánica es sencilla, y se aplica a casi cualquier sitio web moderno:
- El atacante nunca tuvo que entrar en los servidores ni en los smart contracts de Polymarket.
- Comprometió a un proveedor de confianza cuyo código ya tenía permiso para ejecutarse en el sitio.
- Una vez que ese código se ejecutó dentro del frontend en vivo, parecía idéntico al código legítimo para las personas que usaban el sitio.
Un usuario que mirara la interfaz normal no tenía forma práctica de saber que el script que gestionaba su transacción había cambiado. Esa es la característica que define a esta clase de ataque, y es la razón por la que resulta tan difícil de detectar desde fuera.
El ángulo técnico: un vaciador de monederos entregado por la cadena de suministro
La mayoría de la cobertura se queda en "ataque de cadena de suministro". El mecanismo es más concreto, y es lo que hace que este incidente merezca estudio.
Un skimmer clásico de Magecart es pasivo. Lee lo que la víctima escribe en un formulario de pago y lo copia al servidor del atacante. Este ataque no tenía ningún formulario que robar, así que el script inyectado pasó a ser activo y fue a por la firma en sí.
Según el análisis on-chain, cuando un usuario afectado conectaba su monedero, el script le presentaba una solicitud maliciosa de aprobación o de firma a través de la interfaz genuina de Polymarket. Aprobarla daba al atacante la capacidad de mover el pUSD de la víctima. Esta es la misma técnica de phishing de aprobaciones en la que se apoyan los vaciadores de monederos: conseguir que el titular firme una aprobación ERC-20 o un permit de tokens y luego barrer el saldo a una dirección controlada por el atacante. La señal más clara es la remediación que dieron todos los investigadores, que fue revocar las aprobaciones de tokens. Solo se revocan aprobaciones cuando las aprobaciones fueron el arma.
Esto es lo diferente de este caso. Los vaciadores de monederos suelen llegar a las víctimas a través de sitios falsos de airdrop, anuncios maliciosos, dominios con typosquatting o enlaces sociales secuestrados. Todos ellos dependen de atraerte a un lugar falso, así que el consejo habitual funciona: comprueba la URL, usa el sitio oficial, busca el candado. Nada de eso ayudó aquí. El vaciador se ejecutó en el polymarket.com real, en una sesión en la que el usuario ya había conectado su monedero y tenía todos los motivos para confiar en el siguiente aviso. La inyección en la cadena de suministro convirtió el frontend legítimo en la página de phishing.
Este patrón tiene un precedente claro y con nombre. En diciembre de 2023, unos atacantes hicieron phishing a la cuenta de npm de un antiguo empleado de Ledger y publicaron versiones maliciosas de @ledgerhq/connect-kit, la biblioteca de código abierto que muchas dApps usan para conectar los monederos hardware de Ledger. Las versiones envenenadas inyectaron un vaciador de monederos en el frontend de cada sitio que cargaba la biblioteca, incluidos SushiSwap, Zapper y Revoke.cash, y se llevaron alrededor de 600.000 dólares en pocas horas. Una sola dependencia de código abierto secuestrada vació a usuarios de muchos sitios a la vez, sin ninguna URL falsa de por medio. La dependencia comprometida de Polymarket no se ha identificado, pero el esquema es el mismo.
Las propias palabras de Polymarket contienen el detalle que más importa a los defensores: el script se inyectó "para algunos usuarios". El payload era condicional. Esa es la misma propiedad que permite a estos ataques esquivar a un escáner que rastrea desde un centro de datos, y es la razón por la que un control que solo comprueba el origen de un script no puede ayudar una vez que el origen es de confianza.
Dónde ocurrió realmente este ataque
Archivar esto como "otro hackeo cripto" oculta la parte que debería importar a todo equipo web. La capa de blockchain se comportó correctamente. Los smart contracts no fueron explotados. No hubo bug de reentrancy, ni flash loan, ni manipulación de oráculos. El ataque vivió por completo en el runtime del navegador, la capa entre tu servidor y la pantalla de tu usuario, donde el JavaScript de terceros se ejecuta con los mismos privilegios que tu propio código.
Esa capa es una de las superficies menos monitorizadas de las aplicaciones web modernas. Los equipos repiten la regla "nunca confíes en el lado del cliente" y luego cargan de forma rutinaria docenas de peticiones de terceros en ese lado del cliente: analítica, gestores de etiquetas, widgets de chat, píxeles de marketing y SDKs. Cada uno de ellos es una dependencia, y cada dependencia es un posible punto de entrada. El atacante de Polymarket usó una relación con un proveedor que ya era de confianza, porque el proveedor al otro lado había sido comprometido.
Ya hemos documentado este patrón antes. El compromiso del SDK web de AppsFlyer siguió el mismo esquema: los atacantes secuestraron un SDK de marketing de confianza y sirvieron un payload malicioso a miles de sitios cuyos propietarios no tenían ni idea de que sus scripts habían cambiado. También hemos rastreado extensiones de navegador maliciosas que suplantaban a Microsoft Clarity para sobrescribir tokens de referido y desviar ingresos. Payloads distintos, misma causa raíz: código de terceros de confianza que se vuelve hostil, se ejecuta en el navegador y permanece invisible para las defensas tradicionales.
Por qué las defensas estándar no detectan esta clase de ataque
Si te preguntas por qué los controles de seguridad habituales no detienen esto, la respuesta es estructural. La mayor parte de las herramientas en las que confían los equipos simplemente no pueden ver este ataque.
- La seguridad del lado del servidor y de red monitoriza tu propia infraestructura. El código malicioso nunca la tocó. El proveedor fue comprometido aguas arriba, y el payload se ejecutó en el dispositivo del usuario.
- La Content Security Policy (CSP) autoriza qué dominios pueden servir scripts, pero valida el origen, no el comportamiento. Si un proveedor de confianza y autorizado empieza a servir código malicioso, la CSP lo deja pasar. No tiene ni idea de si el script está leyendo un campo de formulario o pidiendo al monedero una aprobación de tokens. Para profundizar, consulta por qué la CSP por sí sola no detiene los ataques del lado del cliente.
- Los escáneres estáticos rastrean tu sitio en busca de scripts maliciosos conocidos. Los atacantes más sofisticados detectan el escáner y le sirven una versión limpia mientras entregan el payload real a los usuarios reales. El script de Polymarket se ejecutó "para algunos usuarios", que es exactamente ese tipo de entrega condicional, y un escáner es lo más fácil de excluir.
El comportamiento que debería haber destacado es concreto: un script de terceros que nunca había tocado el proveedor del monedero interactuando de repente con él y pidiendo a los usuarios que aprobaran transferencias de tokens. Eso es observable en el runtime de JavaScript, donde el script realmente se ejecuta. Es invisible para un control que solo comprueba de dónde vino el script.
Un patrón en toda la web
Si tomas distancia, la tendencia es clara. DefiLlama registró el segundo trimestre de 2026 como el peor trimestre de incidentes de seguridad cripto que ha documentado nunca, con unos 74,9 millones de dólares perdidos en 29 exploits solo en junio. La historia que define la seguridad web en 2026 ya no es el smart contract con errores ni el servidor sin parchear. Es la dependencia de confianza que se vuelve maliciosa, y el runtime del navegador donde se desarrolla ese fallo.
Los atacantes se diversifican porque los puntos de entrada más antiguos son cada vez más difíciles de abrir. A medida que maduran las defensas a nivel de protocolo y de servidor, el lado del cliente sigue siendo el objetivo más blando. Es fácil de alcanzar y rara vez se monitoriza en tiempo real. El ataque de cadena de suministro de polyfill[.]io, que alcanzó a cientos de miles de sitios a través de una sola dependencia de confianza, es la misma historia a una escala mucho mayor.
Cómo cside detecta esta clase de ataque
cside se creó precisamente para la superficie que usó este ataque. Así es como se vería a través de nuestro motor de detección.
Comportamiento, no solo origen. No solo comprobamos de dónde viene un script. Vigilamos lo que hace en el runtime: manipulación del DOM, event listeners, a qué datos accede y a dónde los envía. El script de un proveedor de confianza que de repente recurre al proveedor del monedero, pide una aprobación de tokens o contacta con un dominio recién registrado es exactamente el tipo de anomalía que sacamos a la luz.
Detección de drift. Los scripts no se quedan estáticos. Una dependencia que la semana pasada hacía analítica y esta semana empieza a tocar APIs de monedero y un dominio nuevo activa una alerta. Nuestra IA genera una explicación en lenguaje claro de qué cambió y por qué importa, así no necesitas a un investigador para leer un diff de hashes.
Modo Gatekeeper. Nuestro motor en el edge puede situarse entre los terceros no confiables y tus usuarios, sirviendo el script a través de un conducto que controlamos, para los scripts que tú elijas. Conservamos una copia de lo que se entregó realmente, lo que anula el truco de "servir al escáner una versión limpia", y captura payloads que solo se activan para usuarios, geografías o sesiones específicas, la misma segmentación "para algunos usuarios" que se vio aquí.
Bloqueo en tiempo real, no solo informes. Los escáneres informan. La CSP bloquea con datos limitados. cside puede bloquear un script según su comportamiento observado antes de que vacíe un monedero o robe una tarjeta. Una herramienta que solo te avisa de una brecha después de que ocurra te deja reaccionando.
La respuesta de Polymarket, contener el incidente, eliminar la dependencia y reembolsar por completo a los usuarios afectados, es como se ve una respuesta sólida tras un ataque. La oportunidad para cualquier otra plataforma es asegurarse de que nunca haya un "después". La monitorización de integridad del frontend en tiempo real aún no es estándar en la web, y incidentes como este son la razón por la que debería serlo.
A Polymarket le golpearon en el lado del cliente, donde los ataques son más fáciles de ocultar y más difíciles de detectar. Si en tu sitio se ejecuta JavaScript de terceros, y se ejecuta, esa superficie está expuesta tanto si la vigilas como si no.
Las cifras y la atribución anteriores reflejan los primeros informes de Specter, PeckShield y Bubblemaps y son válidas a fecha de 2026-06-26.
¿Quieres ver qué se está ejecutando realmente en los navegadores de tus usuarios? Empieza gratis o reserva una demo para hablar con nuestro equipo.
