Polymarket y el script de un proveedor: qué enseña a quien asume el riesgo cyber

Tema de la semana del 24 al 31 de octubre de 2026 · por cybercoverinsurance

El 29 de octubre de 2026, durante cerca de una hora, el sitio de Polymarket cargó en las sesiones de sus usuarios un script de un proveedor que ya no era el original. El script servía para medir el rendimiento de las páginas. El código sustituido usó el cliente de trading del propio sitio para mover fondos de cientos de cuentas hacia una única cartera. Las estimaciones independientes hablan de unos 2,7 millones de dólares.

La cifra es pequeña frente a otros eventos de la misma semana. El caso importa por otro motivo. El punto de entrada no fue un sistema del asegurado ni un proveedor crítico, sino una herramienta de monitorización que casi ningún cuestionario de suscripción enumera. Para quien asume el riesgo cyber, la pregunta es cuántos proveedores ejecutan código dentro de las páginas más sensibles de sus asegurados, y quién los controla.

Lo que se sabe

El incidente. Polymarket comunicó que un proveedor externo «fue comprometido», que el caso se remitió a las fuerzas de seguridad y que los usuarios afectados serán reembolsados. Polymarket no indicó el nombre del proveedor ni el importe sustraído (The Record). La empresa de threat intelligence Hudson Rock identificó al proveedor como DebugBear, empresa británica de monitorización del rendimiento web, cuyo script de real user monitoring estaba integrado en polymarket.com. DebugBear confirmó que estaba afectada por un «incidente de seguridad en curso» y pidió a sus clientes que retiraran su código de los sitios (ICOBench).

La secuencia. Según la reconstrucción de Ohey, el script malicioso se sirvió en las sesiones autenticadas desde aproximadamente las 16:54 UTC del 29 de octubre. Los primeros fondos llegaron a la cartera de destino a las 17:10 UTC. Polymarket publicó una versión del sitio sin el script a las 17:59 UTC. DebugBear anunció el incidente a las 18:00 UTC (Ohey). Polymarket puso la plataforma en modo de solo cancelación de órdenes a las 18:05 UTC y reabrió el trading a las 19:00 UTC (ICOBench). La plataforma afectada es la internacional (The Record).

Cómo funcionaba el código. Hudson Rock analizó el script. El código leía del navegador los datos de la cuenta, localizaba el cliente de trading ya cargado en la página, comprobaba los saldos y, por encima de un umbral mínimo, transfería las posiciones o las vendía para después transferir el producto. Las firmas se solicitaban a través del sistema de firma ya activo en la sesión y se enviaban al servicio de retransmisión de Polymarket. Los autores no encontraron rutinas que exportaran claves privadas o frases de recuperación (Hudson Rock). Ohey señala que todas las direcciones contactadas por el script, salvo las de DebugBear, ya estaban autorizadas por la Content Security Policy de Polymarket.

Las cifras. Son estimaciones de terceros, no datos de la empresa. Bitquery indica unos 2,73 millones de dólares de 737 cuentas entre las 17:10 y las 18:10 UTC. GoPlus indica unos 2,71 millones de 731 direcciones. La pérdida mediana por víctima es de 171 dólares (ICOBench). Polymarket no ha publicado un total.

Lo que no se sabe. No se ha aclarado cómo llegaron los atacantes a la infraestructura de distribución de DebugBear (Safestate). No se sabe cuántos otros sitios cargaban el mismo script. Hudson Rock no encontró pruebas de un compromiso más amplio que afectara a otros clientes de DebugBear (The Record). Nadie ha atribuido el ataque.

El proveedor que nadie enumera

Un script de monitorización tiene los mismos poderes que el código del sitio. Un navegador no distingue entre el código escrito por el asegurado y el cargado desde un proveedor. Una vez en la página, el script de terceros lee lo que lee el sitio y puede solicitar lo que el sitio puede solicitar. En el caso Polymarket no hizo falta robar credenciales: el script usó la sesión que el usuario ya había abierto.

Los cuestionarios miran a otro lado. Las preguntas sobre la supply chain suelen centrarse en proveedores de TI, cloud y software gestionado. Herramientas de analítica, tag managers, chat, widgets de reseñas y monitorización del rendimiento quedan fuera, porque se consideran marketing o herramientas accesorias. Es justo la categoría con menos controles y más acceso a las páginas de login, pago y confirmación.

Ya existe un estándar del que tomar las preguntas. Para las páginas de pago con tarjeta, PCI DSS 4.0 exige un inventario de todos los scripts con la justificación de cada uno, un método para autorizarlos y otro para verificar su integridad (requisito 6.4.3). También exige un mecanismo que alerte de cambios no autorizados en la página tal como la recibe el navegador, al menos cada siete días (requisito 11.6.1). Ambos son obligatorios desde el 31 de marzo de 2025 (PageCrawl). Polymarket no procesa tarjetas, pero la lógica vale para cualquier página en la que un usuario autoriza una transferencia de valor.

Qué póliza responde

El daño es de los clientes, el reembolso es una decisión del asegurado. Los fondos sustraídos eran de los usuarios. Polymarket ha prometido reembolsarlos. Para quien asume el riesgo, la distinción importa. Las pólizas cyber cubren por lo general la responsabilidad frente a terceros establecida o las reclamaciones de daños, no los pagos voluntarios hechos antes de cualquier reclamación y sin el consentimiento del asegurador. Un reembolso espontáneo, aunque sensato para la reputación, puede quedar a cargo del asegurado si la póliza no prevé una garantía específica.

La garantía crime depende de quién custodiaba los fondos. Las garantías de fraude informático de las pólizas crime suelen presuponer una pérdida de dinero o bienes del asegurado, o mantenidos por cuenta de terceros. Aquí los fondos estaban en carteras de los usuarios, con las firmas solicitadas en su propia sesión. Muchas pólizas crime, además, excluyen las criptomonedas o solo las cubren con extensiones específicas. El perito deberá establecer si Polymarket mantenía esos fondos, y de qué forma.

El proveedor tiene una responsabilidad, el contrato la limita. DebugBear puede ser llamada a responder ante sus clientes. La cobertura de referencia es la responsabilidad profesional tecnológica (tech E&O) del proveedor, si existe. Pero los contratos SaaS de este tipo suelen limitar la responsabilidad a las cuotas anuales. El recobro por subrogación del asegurador de Polymarket puede valer poco.

La interrupción fue breve. El trading estuvo suspendido cerca de una hora. Las franquicias temporales de las garantías de business interruption suelen ser de varias horas. En este caso el coste real está en la respuesta al incidente, el análisis forense, las comunicaciones a los usuarios y los reembolsos, no en la parada.

Cúmulo: un script, muchos sitios

El mismo archivo puede llegar a miles de páginas. Un script distribuido desde la red de contenidos de un proveedor lo cargan todos los sitios que lo integran. En el caso DebugBear los investigadores no encontraron el código malicioso en otros clientes, y el código estaba escrito para Polymarket. Pero la misma posición, con un código genérico, habría podido afectar a todos los clientes del proveedor al mismo tiempo.

Es un escenario de daño que hay que mapear. Para una cartera, la pregunta no es solo qué proveedores cloud comparten los asegurados. Es también qué scripts de terceros aparecen a la vez en las páginas de login y de pago de muchos asegurados. Tag managers, herramientas de analítica y plataformas de consentimiento son comunes a muchísimos sitios. Un evento en uno de estos proveedores produciría siniestros correlacionados de fraude, violación de datos personales y responsabilidad frente a clientes.

El dato se puede observar desde fuera. A diferencia de muchas dependencias internas, los scripts que carga una página pública son visibles para cualquiera que la abra. Un escaneo externo de las páginas de login y pago de los solicitantes puede mostrar qué proveedores se repiten en la cartera, antes incluso del cuestionario.

Controles y tiempos de reacción

La Content Security Policy no basta por sí sola. Polymarket tenía una política, pero el script usó direcciones ya autorizadas, es decir, las del propio sitio (Ohey). Una política limita adónde puede enviar datos el código, no lo que puede hacer dentro de la página.

La integridad de los archivos es el control más directo. Subresource Integrity bloquea un script si su contenido deja de coincidir con la huella esperada. Hudson Rock lo incluye entre las medidas, junto con la retirada de los scripts de terceros innecesarios de las páginas de trading y firma. El límite es práctico: los proveedores actualizan a menudo sus scripts, y la huella debe actualizarse con un proceso controlado.

Una hora fue suficiente. Entre la llegada de los primeros fondos y la retirada del script pasaron unos 50 minutos (Ohey). La reacción llegó en menos de una hora y, aun así, no evitó la pérdida. Para transacciones automáticas e irreversibles, importan los controles que actúan antes de la firma: límites por sesión, confirmaciones adicionales para operaciones inusuales, bloqueo de transferencias hacia destinos nuevos.

Qué llevar a las renovaciones

Las preguntas valen para cualquier asegurado con páginas de login, pago o autorización de transferencias.

Impacto para las aseguradorasMedio

El siniestro individual fue contenido, pero el mismo vector en un proveedor muy extendido produciría siniestros correlacionados en muchas carteras.

En el lado de la cartera, el trabajo útil es un mapa de los proveedores de scripts recurrentes en las páginas sensibles de los asegurados. Si tres o cuatro proveedores aparecen en gran parte de la cartera, ese es un cúmulo que hay que tratar como el de los grandes proveedores cloud, con escenarios y límites específicos.

Fuentes

• The Record – Polymarket confirma el ataque a un proveedor externo
• ICOBench – estimaciones de pérdidas, número de cuentas y suspensión del trading
• Ohey – cronología del ataque y papel de la Content Security Policy
• Hudson Rock – análisis del código malicioso y recomendaciones
• Safestate – puntos aún sin aclarar sobre el compromiso de DebugBear
• PageCrawl – requisitos PCI DSS 4.0 6.4.3 y 11.6.1 sobre los scripts de las páginas de pago