Resumen: el ataque mediante scripts a Polymarket en octubre
- Otro proveedor comprometido: El 2026-10-29, un script de monitorización del rendimiento sustituido utilizó sesiones activas de Polymarket para vender posiciones y mover fondos.
- El precedente de junio: Polymarket comunicó un ataque similar a la cadena de suministro del frontend el 2026-06-25. cside analizó el robo de aproximadamente 3 millones de dólares del que se informó.
- Reembolsos: Polymarket anunció 3,9 millones de dólares en reembolsos por el incidente de octubre, incluidos 1,2 millones por pérdidas relacionadas con la pausa de operaciones.
¿Poco tiempo? Consulta la seguridad del lado del cliente de cside para conocer la monitorización de scripts y la protección durante la ejecución en el navegador.
Un script de monitorización del rendimiento se convirtió en una vía de acceso a los fondos de los usuarios. Cuatro meses después del incidente de junio en su frontend, Polymarket ha sufrido otro ataque relacionado con scripts de terceros.
El 2026-10-29, un script comprometido de un proveedor utilizó sesiones activas de Polymarket para vender posiciones y mover fondos de las carteras afectadas. En su actualización del 2026-10-30, Polymarket fijó el reembolso total en 3,9 millones de dólares, incluidos 1,2 millones por pérdidas relacionadas con la pausa de operaciones. El informe del incidente de Polymarket describe la respuesta y los reembolsos.
Para los equipos que gestionan aplicaciones financieras, el problema recurrente merece atención: el JavaScript de terceros forma parte de su perímetro de seguridad.
Qué ocurrió el 2026-10-29
Polymarket explicó que un atacante sustituyó el script de monitorización del rendimiento de un proveedor por código dirigido a sus usuarios. La empresa retiró el script y vació las cachés. También pausó las operaciones y su relayer, y después reinició todas las sesiones de acceso activas. Su informe posterior describió más controles de integridad, monitorización, versiones fijadas, aislamiento y una Content Security Policy más restrictiva.
Las cifras de reembolso requieren precisión. Los 3,9 millones de dólares anunciados por Polymarket incluyen compensaciones adicionales a los fondos sustraídos. Presentar todo ese importe como dinero robado exageraría el robo comunicado. Fuente
Cómo el código de monitorización accedió a las funciones de negociación
La investigación técnica de Hudson Rock identificó JavaScript malicioso servido desde una URL de DebugBear asociada a la integración de monitorización de usuarios reales de Polymarket.
El código malicioso leyó el contexto de la cuenta almacenado en el navegador y recorrió estructuras internas de React para encontrar el cliente de negociación y el firmante de la aplicación. Sus distintas ramas intentaban transferir tokens de posiciones o vender posiciones y después transferir los ingresos. Solicitaba firmas e intentaba enviar las operaciones a través del relayer de Polymarket.
Una herramienta de rendimiento estaba intentando ejercer autoridad financiera dentro de la página.
El análisis de Hudson Rock no demostró que todas las solicitudes de firma se completaran sin avisar al usuario. Las confirmaciones de la cartera, las reglas de sesión y la ejecución de las transacciones siguen siendo relevantes. Los investigadores tampoco identificaron una rutina que extrajera claves privadas o frases semilla. El enfoque observado se centraba en reutilizar la autoridad disponible dentro de la aplicación autenticada. Fuente
Polymarket sufrió un ataque similar en junio
Ya analizamos el anterior ataque a la cadena de suministro del lado del cliente de Polymarket después de su comunicación del 2026-06-25. Aquel incidente implicó a un proveedor externo comprometido que inyectó código malicioso en el frontend, con un robo comunicado de aproximadamente 3 millones de dólares.
Nuestro análisis de junio describió un flujo de phishing de aprobaciones a través de la interfaz auténtica de Polymarket. La investigación de octubre describe código malicioso que busca el cliente de negociación y el firmante dentro de una sesión existente.
| Incidente | Mecanismo comunicado | Impacto económico comunicado |
|---|---|---|
| 2026-06-25 | Un proveedor comprometido inyecta código en el frontend asociado a solicitudes maliciosas de aprobación o firma | Aproximadamente 3 millones de dólares robados, según nuestro análisis anterior |
| 2026-10-29 | Un script de monitorización sustituido abusa de sesiones activas; los investigadores identifican lógica de negociación y firma | Polymarket anuncia 3,9 millones de dólares en reembolsos, incluidas compensaciones relacionadas con la pausa |
El patrón común es que scripts de terceros acceden a un flujo financiero sensible. Esta similitud no demuestra que se trate del mismo atacante, proveedor o método de compromiso inicial.
Qué deben cambiar los equipos de aplicaciones
La pregunta práctica para una revisión de seguridad es si una integración de monitorización puede acceder a capacidades que exceden ampliamente su función prevista.
Empieza por reducir la ejecución de scripts de terceros en páginas autenticadas de negociación y firma. Exige una justificación comercial clara para cada integración, una persona responsable y un procedimiento de retirada. Revisa el límite de acceso a la firma y decide qué acciones requieren una confirmación nueva y explícita.
Para las dependencias cuyas versiones puedan fijarse, utiliza Subresource Integrity. SRI permite al navegador comparar un archivo descargado con un hash criptográfico esperado y rechazarlo si no coincide. Las implementaciones entre orígenes requieren compatibilidad adecuada con CORS y un proceso controlado de actualizaciones aprobadas.
Conserva también el contenido de los scripts entregados a los usuarios. Una investigación necesita pruebas de qué se ejecutó, cuándo cambió y qué sesiones pudieron recibirlo.
Qué aporta cside
cside proporciona visibilidad de la ejecución en el navegador, un inventario de scripts, un historial de su contenido y detección de comportamientos maliciosos. Estas capacidades ayudan a investigar cambios en el código que se ejecuta en las sesiones de los clientes. Conoce la seguridad del lado del cliente de cside.
Los incidentes de junio y octubre concretan la prioridad: revisar el código que permites ejecutar junto a tus flujos más sensibles, limitar su autoridad y verificar de forma continua qué llega a los usuarios.
