Un dominio de CDN abandonado vuelve a estar activo y miles de webs siguen llamándolo
El dueño original dejó expirar el dominio y ahora un desconocido tiene DNS comodín sobre él: cualquier hostname bajo ese dominio resuelve a su infraestructura
En julio de 2025 alguien registró un dominio que había sido de una CDN. La CDN se apagó años antes y el dominio se dejó expirar, pero no expiraron sus llamadas: miles de webs, repositorios de código y páginas de documentación siguen llevando hostnames de ese dominio escritos a mano. El nuevo dueño tiene DNS comodín sobre todo él, así que cualquier hostname bajo ese dominio resuelve ya a la infraestructura que él controla. Hoy la raíz sirve una página de descarga de vídeo llena de anuncios, que no tiene nada de especial. Lo que sí lo tiene es que la decisión sobre lo que cargarán esas miles de páginas está en manos de un desconocido, y nadie se ha enterado, porque desde fuera no se ha roto nada.
El código que nunca pasó por tu servidor
No es un patrón hipotético. En junio de 2024 el dominio polyfill.io, un shim de JavaScript embebido en más de 110.000 sitios, cambió de dueño y empezó a servir redirecciones condicionales a visitantes móviles. Esos sitios no habían sido hackeados: años atrás habían delegado una etiqueta script y nunca volvieron sobre la decisión.
El problema de fondo es dónde mira el análisis estático, el escaneo de dependencias y el SCA: todos examinan lo que la organización compila y despliega, y un script de terceros no es nada de eso. Lo pide el navegador del visitante a un servidor que la organización no administra, en cada vista de página, y corre con los mismos privilegios que el código propio. Lee el DOM, lee los campos de formulario carácter a carácter mientras se escriben, lee cookies y almacenamiento local y hace peticiones salientes a donde quiera. Un ataque tipo Magecart no necesita brecha en el servidor; le basta con que una etiqueta aprobada empiece a comportarse distinto. Y responde de forma distinta según geografía, user agent, referrer y hora del día, así que un crawler que baje el fichero una vez desde un rango de IP de datacenter verá la versión limpia mientras el comprador que entra desde una red móvil recibe otra cosa.
Reportar antes de bloquear
El navegador que ejecuta el código es el único testigo fiable de todas esas vistas. CSP se presenta como defensa contra XSS, y lo es, pero su segunda función resulta más útil para quien todavía no sabe qué código corre en su web: permite declarar qué puede ejecutarse y avisar cuando aparece algo no autorizado. Las alertas salen de sesiones reales, de usuarios reales y dispositivos reales, así que un payload que solo se dispara para usuarios autenticados de un país concreto también se reporta. En modo Content-Security-Policy-Report-Only no bloquea nada ni cambia comportamiento, solo informa, y convierte el primer despliegue en un ejercicio de medición.
Ahí conviene saber que el texto que acompaña a todo esto lo firma Report URI, una plataforma de seguridad client-side, y que parte de los datos son suyos. Según esa firma, en septiembre de 2026 sus alertas destaparon un grupo de comercios electrónicos comprometidos con una campaña de la familia ClickFix: cargadores en base64 plantados en el CMS tras comprometer una cuenta de administración, una cadena hacia un redirector y una falsa ventana de "verifica que eres humano" que dejaba un comando de PowerShell en el portapapeles y lo persistía como tarea programada. Los hostnames del atacante aparecían en alertas lanzadas por navegadores mientras varios servicios de reputación seguían dándolos por limpios. Ningún escáner había marcado esas páginas porque en el servidor estaban perfectas.
Para quien toca pagos con tarjeta la discusión ya está cerrada por otra vía. Los requisitos 6.4.3 y 11.6.1 de PCI DSS v4.0.1 dejaron de ser recomendación el 31 de marzo de 2025: exigen que cada script de una página de pago esté autorizado, que su integridad esté garantizada, que exista un inventario escrito con justificación de negocio y que haya un mecanismo que detecte y avise de modificaciones no autorizadas en el contenido y en las cabeceras. Un QSA va a pedir ese inventario y las evidencias que haya producido el sistema de alertas.
Lo caro de esto no es activar el modo informe ni leer los primeros correos, es mantener el inventario vivo: saber qué entra cada semana, quién lo aprobó y qué cambió respecto a ayer. El rastreo diario del millón de sitios más visitados que cita la compañía habla de un crecimiento superior al 12.000% en adopción de CSP en una década, una cifra que es suya y que conviene tomar como orientación, no como medición independiente.
