Saltar al contenido principal

El informe de Polymarket atribuye el vaciado de cuentas a un script de un proveedor

La empresa explica cómo un script externo de monitorización utilizó sesiones activas y detalla la respuesta y la base de 3,9 millones de dólares en reembolsos.

Un panel de vidrio transparente con bloques azul grisáceo y cables, y un bloque ámbar iluminado delante.
TechKili · Ilustración conceptual generada con IA mediante Cloudflare Workers AI FLUX.2 klein.
Compartir este artículo:
En este artículo

El informe posterior al incidente de Polymarket, publicado el 30 de octubre de 2026, atribuye el vaciado de cuentas del día anterior a un script comprometido de un proveedor que utilizó las sesiones activas de algunos usuarios. El caso muestra por qué el código que carga una web de negociación forma parte de la seguridad de las operaciones realizadas con la sesión iniciada.

La cobertura original de WIRED, publicada el 29 de octubre, informó de la suspensión temporal y la reapertura de la negociación internacional. Señaló que la plataforma independiente Polymarket US no se vio afectada. El posterior informe oficial añade el mecanismo y la base de los reembolsos.

El código de un proveedor alcanzó una sesión de negociación activa

Según Polymarket, un atacante sustituyó un script de monitorización del rendimiento. Para algunas personas que tenían la web abierta durante un breve intervalo, el script utilizó su sesión para vender posiciones y transferir fondos.

El límite relevante es lo que puede hacer ese código externo una vez que la web lo carga. La guía de OWASP sobre JavaScript de terceros explica que ese código puede ejecutarse con los privilegios de la aplicación anfitriona. Por tanto, un cambio en el proveedor puede modificar la aplicación que recibe el usuario, aunque el operador de la web no publique una versión nueva.

Es un problema de integración en el navegador con consecuencias para las operaciones de la cuenta. Por sí solo, no acredita un fallo de un protocolo blockchain ni identifica cómo comprometió inicialmente el atacante al proveedor.

La contención y el reembolso requieren pruebas separadas

Polymarket afirma que retiró el script, vació las cachés, invalidó las sesiones activas y suspendió y después restableció la negociación. También describió controles de integridad y monitorización adicionales en fase de despliegue.

En la actualización del 30 de octubre, la empresa detalló 3,9 millones de dólares en reembolsos: 2,7 millones más 1,2 millones por pérdidas relacionadas con la suspensión. Por tanto, el total no debe describirse como el importe que sustrajo directamente el atacante. La publicación indica que las carteras elegibles se identificaron automáticamente y ofrece un canal para cuestionar una cantidad.

Para los afectados, contrastar las operaciones de la cuenta y el registro de reembolsos con esa explicación es más útil que considerar la reapertura del servicio una prueba de que se ha conciliado un saldo individual.

Evaluar los controles que rodean a la página

Para los desarrolladores, OWASP describe comprobaciones de integridad que rechazan archivos de script modificados y marcos aislados que limitan el acceso del código del proveedor a la página principal. Son controles que abordan partes distintas de la integración y requieren mantenimiento cuando cambia el código.

La pregunta práctica de diseño es qué código de terceros necesita acceder a una operación autenticada y cómo se revisan sus cambios. La respuesta descrita por Polymarket acredita lo que la empresa comunica estar haciendo; no constituye una auditoría independiente de todos los controles desplegados.

Fuentes