Durante años, añadir Polyfill a una web parecía una decisión sin historia. Una línea de JavaScript permitía que navegadores antiguos entendieran funciones modernas y el desarrollador podía volver al trabajo importante. La página cargaba un recurso desde polyfill.io, el usuario no veía nada especial y la dependencia quedaba enterrada en el HTML, convertida en parte del paisaje.
En febrero de 2024 el dominio y la distribución asociados al servicio fueron adquiridos por una empresa llamada Funnull. Meses después, investigadores de Sansec detectaron que el dominio estaba sirviendo JavaScript malicioso. La misma dirección que sitios legítimos habían incluido para resolver compatibilidad podía decidir, en el navegador de un visitante, si redirigirlo a páginas de apuestas o estafas. No era necesario vulnerar uno por uno a los comercios, medios o proyectos que lo cargaban. La dependencia ya tenía una puerta abierta en todos ellos.
El mecanismo tenía una sutileza propia de los ataques que quieren durar. Según el análisis de Sansec, el comportamiento variaba por dispositivo, hora y condición del usuario; las redirecciones se orientaban especialmente a móviles y trataban de no repetirse de forma obvia para un administrador que comprobara su propia página. La web podía parecer sana desde un escritorio y traicionar a visitantes reales en otro momento.
La cifra estimada por los investigadores superaba los cien mil sitios cargando el dominio. Es importante entender qué significa: esos sitios no habían elegido instalar malware. Habían conservado una referencia remota que algún día fue razonable y que dejó de serlo al cambiar su control. En infraestructura solemos revisar los servidores, los paquetes y los contenedores; en una página pública, un <script src="..."> también es una dependencia ejecutable en producción.
Cloudflare respondió reemplazando automáticamente las referencias a polyfill.io por una copia alojada bajo su propio dominio para los sitios que utilizaban su proxy. El proyecto original de Polyfill, por su parte, señaló que los navegadores modernos ya no necesitaban ese servicio de la misma forma y recomendó retirar su uso. Otras plataformas comenzaron a bloquear anuncios o advertir a propietarios de páginas que cargaban la URL comprometida.
El caso tiene una diferencia incómoda respecto a una biblioteca empaquetada en nuestro repositorio. Cuando vendemos o auditamos una aplicación, podemos congelar una versión de una dependencia y revisar su hash. Un script remoto, si no está fijado y protegido, puede cambiar sin que hagamos un despliegue. La página que ayer enviaba el JavaScript correcto hoy ejecuta otro porque quien controla el dominio ha cambiado la respuesta. Nuestro historial de commits permanece limpio mientras el navegador del usuario recibe el daño.
Esto no significa que cada CDN deba tratarse como enemigo, pero sí que la comodidad tiene una factura. Podemos reducir superficie evitando dependencias innecesarias, alojando localmente recursos pequeños, usando políticas de seguridad de contenido y, cuando el recurso sea estático, verificando su integridad. Sobre todo, debemos saber qué código de terceros ejecutan nuestros visitantes. El inventario de una web no termina en el repositorio.
Polyfill.io merece formar parte de este archivo porque muestra una infraestructura diminuta con consecuencias enormes. No hubo un rack ardiendo ni una región cloud caída. Hubo una línea olvidada en miles de páginas y una transferencia de control. Para el visitante redirigido a una estafa, la diferencia entre frontend e infraestructura no existía: la web en la que confiaba lo había llevado hasta allí.
Documentos y fuentes
Sansec, investigación del ataque de cadena de suministro a Polyfill
Cloudflare, respuesta y sustitución automática de enlaces a polyfill.io
Conversacion
Se el primero en comentar