Un script ajeno vació carteras en Polymarket
Bastó con cambiar un medidor de velocidad para mover millones. Cualquier web que cargue código de terceros puede estar dejando abierta la misma puerta.

Una parte de quienes tenían la sesión iniciada en Polymarket, el mercado de predicciones, se encontró el 29 de octubre con sus posiciones vendidas y sus fondos en manos ajenas. Según The Hacker News, el responsable fue código malicioso servido desde la propia web de Polymarket. No hizo falta romper la plataforma: bastó con sustituir un pequeño script que la página cargaba desde fuera.
Qué ha pasado
Ese script servía para medir la velocidad de carga de la página y lo proporcionaba una empresa externa. Según el titular de The Hacker News, se trataba de un script de DebugBear que fue secuestrado. En algún momento, el código legítimo se reemplazó por otro que, al ejecutarse en el navegador de quienes estaban conectados, vendía sus posiciones y transfería el dinero a los atacantes.
Polymarket asegura que devolverá unos 2,7 millones de dólares a 726 carteras afectadas. Los registros de la cadena de bloques muestran que llegaron a los atacantes criptomonedas por valor de unos 2,64 millones de dólares, según el mismo medio.
Con el material disponible quedan preguntas sin responder. No está claro cómo se produjo la sustitución del script, si el problema estuvo en la infraestructura del proveedor o en otro punto de la cadena, cuánto tiempo estuvo activo el código malicioso ni si otras webs que usaban ese mismo script se vieron afectadas.
Por qué importa más allá de Polymarket
El caso es llamativo por las cifras, pero el mecanismo es de lo más corriente. Buena parte de las webs cargan código de terceros: analítica, publicidad, chats de soporte, fuentes, herramientas de rendimiento. Cada una de esas líneas pide al navegador del visitante que ejecute, con los mismos permisos que el código propio, lo que otro servidor decida entregar en ese momento.
Si ese servidor cambia lo que entrega, por un ataque o por un error, la web que lo incluye lo sirve igual. Y quien la visita no tiene forma de notar la diferencia. En una tienda puede traducirse en datos de tarjetas robados; en una plataforma donde el navegador puede firmar operaciones financieras, en carteras vaciadas.
Lo paradójico es que el origen fue una herramienta para medir cuánto tarda en cargar la página, algo que no aporta nada a quien la usa y que aun así tenía acceso a todo.
Qué se puede hacer
No hay soluciones mágicas, pero sí prácticas conocidas para reducir el riesgo de cargar código ajeno:
- Cargar menos: revisar qué scripts externos son realmente necesarios y retirar los que no lo son.
- Alojarlos en casa: servir una copia propia y revisada en lugar de enlazar a la versión viva del proveedor.
- Fijar su contenido: la integridad de subrecursos (SRI) permite indicar al navegador el hash exacto del archivo esperado y rechazarlo si cambia.
- Acotar permisos: una política de seguridad de contenidos (CSP) limita desde dónde se puede cargar código y adónde puede enviar datos.
- Aislar lo crítico: las páginas que firman operaciones o manejan credenciales deberían cargar el mínimo código de terceros posible.
Polymarket ha optado por reembolsar a los afectados. Queda por ver qué explicación técnica dan la plataforma y el proveedor del script, y si el caso sirve para que más webs se pregunten cuántas puertas tienen abiertas sin saberlo.
Fuente: The Hacker News
Sigue leyendo
Noticia
El ataque a Polymarket entró por el DNS de DebugBear
Según el proveedor, sus sistemas no se tocaron: bastó con controlar el dominio. Confiar en un script ajeno es confiar también en quien gestiona su DNS.
Noticia
Ivanti tapa dos agujeros más de su VPN ya explotados
Quien parcheó en octubre tiene que volver a hacerlo. Y la VPN que debía proteger la red puede haber sido la puerta de entrada.
Noticia
California podría dar un atajo a los centros de datos
Una ley vendida para construir viviendas y renovables quizá acabe dejando a los vecinos sin voz frente a los centros de datos de la IA.
