Un ataque al DNS de DebugBear cambia su script de Core Web Vitals

DebugBear pidió el 29 de octubre de 2026 a los clientes de su medición con usuarios reales (RUM) que retiraran el código de sus webs. En una actualización posterior informó de que habían comprometido los registros DNS a través de su registrador. Eso permitió dirigir las peticiones a otra infraestructura y entregar código distinto bajo el dominio del proveedor.

La empresa dice que la investigación inicial apunta a un cliente concreto y que no ha visto indicios de entrada en sus sistemas internos. Es el alcance de su declaración, no una garantía de que todos los demás clientes estén a salvo.

Polymarket confirma la sustracción de fondos

El informe del incidente de Polymarket explica que un script externo de monitorización fue sustituido por código dirigido a sus usuarios. Aprovechó algunas sesiones abiertas para vender posiciones y mover fondos. La plataforma retiró el script y cerró las sesiones activas.

Polymarket anunció 3,9 millones de dólares en devoluciones: 2,7 millones por fondos sustraídos y compensaciones asociadas, y otros 1,2 millones por pérdidas durante la pausa de operaciones. El total no equivale al dinero robado.

Polymarket no identifica al proveedor en ese informe. Hudson Rock vincula el código con DebugBear mediante el archivo analizado y una referencia a su retirada en la aplicación. Su análisis no determina el comienzo exacto de la exposición ni prueba que se atacara a otros clientes.

Un dominio permitido no garantiza el contenido del script

Nuestra lectura: permitir un dominio en la política de seguridad de contenido (CSP) no comprueba que el archivo servido siga siendo el esperado. Un script externo ejecutado en una página puede acceder a los datos que esa página expone a JavaScript y actuar dentro de una sesión abierta. El impacto depende de la aplicación; no significa que pueda leer cualquier dato protegido del navegador.

Subresource Integrity permite rechazar un fichero cuyo contenido no coincide con el resumen esperado. Requiere una versión controlada y, si se carga desde otro origen, una configuración compatible de CORS. Alojar una copia en tu servidor tampoco sustituye la revisión del código ni el control de las actualizaciones.

Si usas el RUM de DebugBear, sigue su aviso de retirada y comprueba que no se cargue desde plantillas, plugins o gestores de etiquetas. En las publicaciones públicas consultadas el 2 de noviembre no aparece una autorización para reinstalarlo; espera una confirmación del proveedor por un canal fiable.

Revisa también qué scripts de terceros necesitan ejecutarse en páginas con cuentas o pagos. Retira los innecesarios y acuerda con desarrollo cómo controlar las versiones y detectar cambios en los imprescindibles.