El 29 de octubre de 2026, un script de medición de rendimiento suministrado por un proveedor y cargado en polymarket.com fue sustituido por código malicioso. Aprovechó las sesiones abiertas de los usuarios para vender sus posiciones y sacar los fondos. Polymarket devolverá 3,9 millones de dólares en total y ha reforzado el control de sus scripts de terceros.
Qué ha pasado
En un informe del incidente publicado el 30 de octubre de 2026, el mercado de predicciones Polymarket explica que detectó actividad no autorizada en monederos de usuarios el 29 de octubre a las 17:38 UTC. El origen no estaba en su propio código: un proveedor cuyo script de medición de rendimiento se cargaba en polymarket.com había sido comprometido, y el atacante sustituyó ese script por otro dirigido a los usuarios de Polymarket. En parte de las personas que tenían el sitio abierto durante un breve intervalo aquella tarde, el script usó la sesión activa para vender posiciones y transferir fondos fuera de sus monederos.
Polymarket devolverá 3,9 millones de dólares en total: 2,7 millones por el robo y 1,2 millones por las pérdidas causadas por la pausa de la negociación. Al publicarse el informe, el 95 % de los monederos afectados ya se había reembolsado por completo. La empresa no indica cuántos usuarios se vieron afectados y ha remitido el caso a las fuerzas del orden.
Cómo entraron los atacantes
El sitio confiaba en el dominio del proveedor, así que los navegadores ejecutaban todo lo que este servía. Según un análisis de Hudson Rock, la Content Security Policy del sitio permitía ese dominio; el script malicioso leía los datos de autenticación guardados en el navegador, localizaba el cliente de negociación en la página y después pedía firmas y enviaba transferencias a una dirección controlada por el atacante. Según The Record, el proveedor afirma que sus primeras conclusiones apuntan a un compromiso a través de su registrador de dominios.
Qué hacer ahora
- Inventaríe los scripts externos de sus sitios, por ejemplo con
curl -s https://www.example.com/ | grep -oE 'src=[^ >]+', y elimine los que nadie necesita, empezando por las páginas de acceso, pago y cuenta de cliente. - Fije y verifique los que queden: aloje usted mismo una versión fija o añada Subresource Integrity a los archivos que no cambian (hash generado con
openssl dgst -sha384 -binary archivo.js | openssl base64 -A), para que se rechace un archivo modificado. - Endurezca la Content Security Policy: listas
script-srcyconnect-srcprecisas, con notificación de infracciones activada. Permitir un dominio no comprueba lo que sirve. - Vigile los cambios: calcule con regularidad el hash de los archivos de terceros y genere una alerta ante cualquier cambio.
- Prepare la respuesta: debe poder retirar un script y anular todas las sesiones en minutos, como hizo Polymarket.
- Proteja sus propios dominios: autenticación multifactor y bloqueo de registrador en sus cuentas del registrador.
Nuestra opinión
Un script cargado desde otro dominio se ejecuta con los mismos derechos que su propio código, dentro de las sesiones de sus clientes. Una etiqueta de analítica o de monitorización rara vez se considera crítica, y aquí bastó para vaciar cuentas. Menos scripts de terceros, versiones fijas y controles de integridad cuestan poco frente a un reembolso millonario.
Fuentes
- Polymarket Status — Post-mortem of the 29 October 2026 incident
- The Record — Polymarket pledges to give $3.9 million back to victims after site compromise
- The Record — Polymarket confirms cyberattack involving third party
- Hudson Rock (Infostealers) — Polymarket breach alert: wallet-draining code found in a third-party script
Cómo elegimos, verificamos y redactamos nuestros análisis →
La puerta de entrada fue un tercero. Compruebe lo que sus proveedores exponen públicamente, sin intrusión y solo con información pública:
¿Le preocupa que sus servidores estén expuestos? Nuestro equipo audita, parchea y supervisa infraestructuras Linux y cloud 24/7.
Hablar con un experto Nuestros servicios de servidores gestionados →
