Script de DebugBear comprometido: qué hacer en tu web

DebugBear, una herramienta que mide la velocidad y los Core Web Vitals de las webs, pidió el 29 de octubre de 2026 a los clientes de su producto RUM que quitaran su script. Atacantes tomaron sus registros DNS y sirvieron código malicioso a Polymarket, que perdió fondos de usuarios. Afecta a quien tenga ese script instalado.

Lo que se sabe

El aviso: el 29 de octubre, DebugBear escribió en su cuenta oficial de X que estaba afectada por «un incidente de seguridad en curso» y pidió a quien usara su producto RUM (la medición con visitas reales) que quitara el código de su web.
La causa, según DebugBear: el 30 de octubre explicó que los registros DNS de su dominio se comprometieron a través de su registrador de dominios. Según su investigación inicial, el ataque apuntaba a la web de un cliente concreto, y no ha visto indicios de intrusión en sus sistemas internos. También dijo que no puede recibir los correos enviados a su dominio.
La víctima, según Polymarket: su página de estado describe que el 29 de octubre, entre las 17:38 y las 18:15 UTC, el script de un proveedor de monitoreo de rendimiento fue sustituido por uno hecho para atacar a sus usuarios. A quienes tenían la web abierta en ese rato les usó la sesión para vender posiciones y mover fondos. Polymarket no nombra al proveedor.
Lo que hizo Polymarket: quitó el script, borró cachés, pausó las operaciones, cerró todas las sesiones y volvió a poner sus scripts de terceros con más controles. Dice que devuelve 3,9 millones de dólares (2,7 por lo robado y 1,2 por la pausa) y que el 30 de octubre ya había reembolsado al 95 % de las carteras afectadas.
El archivo: la firma Hudson Rock analizó el 29 de octubre un archivo servido desde cdn.debugbear.com y, según su informe, buscaba el cliente de operaciones de Polymarket en el navegador para vender posiciones. Hudson Rock añade que sus pruebas no muestran que otros clientes de DebugBear recibieran código malicioso.

Qué cambia y qué no

No se sabe si otras webs recibieron código distinto del normal. DebugBear habla de un objetivo concreto; la investigación sigue abierta.
Quitar el script no borra tus datos de Search Console. El informe de Core Web Vitals de Search Console sale de los datos de Chrome (CrUX), no de herramientas RUM. Pierdes la medición propia mientras dure, no tu posición.
La lección no es solo de DebugBear. Cualquier script que cargas desde el dominio de otro corre en tu web con los mismos permisos que tu código. Si alguien controla ese dominio, controla lo que se ejecuta en tus páginas.

Cómo saber si te afecta

Si usabas el RUM de DebugBear:

Quita el código de las plantillas, los plugins y el gestor de etiquetas (Google Tag Manager u otro), y vacía las cachés de la web y de la CDN.
Comprueba que ya no carga: abre la web con las herramientas del navegador (pestaña Red) y busca «debugbear».
Si tu web tiene inicio de sesión, pagos o un área de clientes, cierra las sesiones abiertas y revisa en los registros si hubo cambios o accesos raros desde el 29 de octubre.

Para cualquier web que cargue scripts de terceros:

Haz la lista de dominios externos de los que cargas código. Quita los que ya no usas.
Saca los scripts que no son imprescindibles de las páginas sensibles (inicio de sesión, pago, panel). La medición puede vivir en el resto.
Usa una política de seguridad de contenido (CSP) que solo permita los dominios de la lista. No para un ataque como este, pero limita a dónde puede mandar datos un script alterado.
Protege tu propio dominio: verificación en dos pasos en la cuenta del registrador, bloqueo de transferencia activado y avisos por cambios en el DNS. Lo que le pasó a DebugBear empezó ahí.

Relacionado: Google bloquea certificados HTTPS no autorizados: qué revisar

Fuentes

Actualizaciones: si DebugBear publica su informe final o confirma otras webs afectadas, se añadirá aquí con su enlace.