Polymarket: script RUM de DebugBear manipulado roba cripto

El 29 de octubre de 2026 Polymarket, la plataforma de mercados predictivos basada en criptomonedas, suspendió durante una hora aproximadamente la negociación en su plataforma internacional, Polymarket.com, tras el compromiso de un proveedor externo. Según BleepingComputer, SecurityWeek y The Record, el proveedor es DebugBear, un servicio británico de monitorización del rendimiento de sitios web: desde su infraestructura se sirvió un JavaScript malicioso que usó las sesiones de los usuarios conectados para transferir sus activos a carteras controladas por el atacante.

Polymarket confirmó el incidente, lo comunicó a las fuerzas del orden y se comprometió a reembolsar a todos los usuarios afectados. Sin embargo, no ha indicado el nombre del proveedor, el número de víctimas ni el importe sustraído. Según SecurityWeek, la plataforma estadounidense de Polymarket no se vio afectada.

Cronología

Los tres medios coinciden en los pasos principales, reconstruidos a partir de la página de estado y los mensajes públicos de Polymarket (horas en UTC):

• 17:50–17:56: según el análisis de la blockchain de BleepingComputer, la cartera sospechosa realiza numerosas transacciones en el contrato de los tokens de los mercados predictivos de Polymarket;
• 17:59: Hudson Rock identifica una build de producción de Polymarket con el mensaje de commit chore(polymarket): remove debugbear rum script (#15337), es decir, la eliminación de la integración de DebugBear;
• 18:05: el exchange pasa al modo «solo cancelación» y se suspenden las operaciones del relayer;
• 18:37: Polymarket comunica que ha identificado y corregido el problema, pero detiene la negociación por prudencia;
• 19:05: incidente cerrado y negociación de nuevo activa.

DebugBear confirmó que está afectada por un «incidente de seguridad en curso», pidió a los clientes de su producto RUM (Real User Monitoring) que quitaran el código de integración de sus sitios y, según SecurityWeek, recurrió a especialistas en respuesta a incidentes.

Cómo funcionaba el script

Los servicios RUM funcionan con un fragmento de JavaScript insertado en las páginas del cliente, que mide el rendimiento en el navegador de los visitantes. Precisamente por eso el script se ejecuta con los mismos privilegios que el código del sitio. Según Hudson Rock y BleepingComputer, la versión maliciosa se servía desde cdn.debugbear[.]com/C7xcKKrjUnXK.js y:

1. comprobaba si el visitante estaba autenticado en Polymarket;
2. leía los saldos en criptomonedas y las posiciones en los mercados predictivos para estimar su valor;
3. según el tipo de autenticación de la cuenta, vendía las posiciones y movía lo obtenido, o transfería directamente los tokens de las posiciones a una dirección elegida por el atacante;
4. convertía las criptomonedas en activos transferibles usando las propias funciones de transacción de la plataforma.

BleepingComputer, que analizó una copia del archivo, informa de que el script intercambiaba datos con data.debugbear[.]com para recibir instrucciones y enviar las cuentas atacadas, las direcciones de las carteras, los saldos y los resultados de las transacciones: la misma infraestructura del proveedor servía, por tanto, para la distribución y como canal de mando y control. Hudson Rock precisa que el código lee material relacionado con las credenciales, pero que no encontró rutinas que envíen contraseñas, frases semilla o claves privadas: el enfoque consiste en reutilizar la autoridad ya disponible en la aplicación autenticada.

Todavía no se sabe cómo se manipuló el script. Hudson Rock afirma no tener indicios de un ataque más amplio contra otros clientes de DebugBear.

En nuestra lectura, las técnicas MITRE ATT&CK pertinentes son T1195.002 (Compromise Software Supply Chain), T1185 (Browser Session Hijacking), T1071.001 (Web Protocols), T1041 (Exfiltration Over C2 Channel) y T1657 (Financial Theft).

Las pérdidas: estimaciones diferentes

Las cifras no coinciden y ninguna es oficial:

• BleepingComputer rastreó unos 28,6 millones de POL (unos 2,57 millones de dólares) transferidos desde la cartera sospechosa a otras tres carteras;
• Hudson Rock vio unos 2,19 millones en la dirección de respaldo escrita en el script, aclarando que no es un recuento verificado;
• según SecurityWeek, GoPlus estima unos 2,71 millones, con una ruta que pasa por 710 carteras de depósito y 731 direcciones (que no equivalen al número de víctimas), mientras que los datos de Arkham indican unos 2,65 millones en la misma dirección;
• The Record habla de más de 2,1 millones según varias empresas de seguridad de la blockchain.

SecurityWeek recuerda también que en junio Polymarket ya había comunicado otro compromiso de un proveedor externo, con un script malicioso inyectado en el frontend y pérdidas estimadas en torno a 3 millones de dólares.

Impacto para las empresas europeas e italianas

El caso va más allá de las criptomonedas. Cualquier script de terceros cargado en una página (monitorización del rendimiento, estadísticas, gestores de etiquetas, chat, pruebas A/B) puede leer y hacer todo lo que puede hacer el usuario conectado. En las áreas privadas de bancos, comercios electrónicos, portales sanitarios y aplicaciones SaaS esto significa datos personales, pedidos, pagos y operaciones dispositivas.

Para las entidades sujetas a NIS2, los proveedores de estos scripts entran en la seguridad de la cadena de suministro: hay que inventariarlos y evaluarlos como a los demás proveedores TIC. Un script comprometido que lee datos en las páginas autenticadas debe evaluarse también como posible violación de datos personales a efectos del RGPD.

Qué hacer ahora

1. Si usas DebugBear RUM, quita el código de integración como indica el proveedor y busca en los registros del proxy y del firewall y en los informes CSP las peticiones a cdn.debugbear[.]com y data.debugbear[.]com.
2. Haz el inventario de los scripts externos cargados en producción, empezando por las páginas autenticadas y las que inician transacciones.
3. Quita de las páginas sensibles los scripts que no necesitan para funcionar: la monitorización y las estadísticas rara vez tienen que ejecutarse donde el usuario maneja dinero o datos.
4. Aplica una Content Security Policy con script-src y connect-src limitados a los dominios necesarios y con el informe de violaciones activado.
5. Donde el script sea estático, aloja una copia versionada o usa Subresource Integrity; para los scripts que cambian a menudo, vigila las modificaciones de su contenido.
6. En el servidor, pide una confirmación separada para las operaciones de alto riesgo (retiradas, transferencias a nuevos destinatarios) y vigila ráfagas anómalas de transacciones desde la misma sesión: un script que reutiliza la sesión no supera un segundo factor solicitado en el momento de la operación.
7. Si trabajas con criptomonedas, añade a tus listas de bloqueo la dirección señalada por Hudson Rock: 0x3F99139F1C5854bb628c2e576Aaf638e99dFfc18.

Cómo ayuda ARXDOME

ARX Horizon permite buscar los indicadores públicos de este incidente en las fuentes de threat intelligence, y los eventos de los firewalls recogidos por ARX Sentry, enriquecidos con las listas de amenazas, ayudan a saber si puestos de trabajo y servidores de la empresa contactaron con los dominios usados por el script.

Última actualización: 30 de octubre de 2026