Resumen: cronología del ataque a Polyfill.io
- Los titulares dijeron 100.000 sitios y era falso, porque ese era el límite por defecto de la herramienta PublicWWW que usaron los investigadores, y la huella real era mucho mayor y con más peso en sitios de alta confianza.
- cside repitió la búsqueda superando el tope y encontró más de 490.000 sitios web con polyfill.io, y Censys contó de forma independiente 384.773 hosts afectados el 2 de julio de 2024 antes de que la OFAC sancionara a Funnull el 29 de mayo de 2025.
- Si un solo script de proveedor puede volverse malicioso tras ser de confianza desde 2015, la aprobación basada en fuente no es un control, así que supervisa el comportamiento en tiempo de ejecución en cada sesión en lugar de fiarte de una firma única.
Respuesta rápida: Un ataque a la cadena de suministro web compromete una biblioteca o servicio CDN de terceros en el que los sitios legítimos ya confían, y usa esa confianza para ejecutar código controlado por el atacante en el navegador de cada visitante. El ataque de Polyfill.io es el ejemplo documentado más claro: el servicio de polyfill de confianza fue adquirido por Funnull en febrero de 2024, se volvió malicioso en junio y afectó a más de 490.000 sitios web antes de que nadie lo notara. Esta página explica cómo funciona la categoría de ataque, documenta el incidente de Polyfill.io en su totalidad y muestra qué debe hacer tu sitio de manera diferente.
Actualización 2026-07-19: Se añadió una sección sobre los tipos de ataques a la cadena de suministro web y cómo funciona la categoría, más nuevas entradas de FAQ. La cronología y los datos principales de Polyfill.io no han cambiado.
¿Qué es un ataque a la cadena de suministro web?
Un ataque a la cadena de suministro web compromete una biblioteca JavaScript de terceros, una CDN o un servicio que los sitios legítimos cargan y en el que confían. Como la página carga ese código como si fuera propio, el atacante obtiene ejecución de código en el navegador de cada visitante sin tocar directamente el sitio objetivo.
Un ataque a la cadena de suministro web tiene unas pocas propiedades definitorias. El sitio víctima aprobó el script una vez, y el atacante hereda esa confianza de forma permanente. El payload se ejecuta en el lado del cliente, después de que el servidor ya ha enviado la página, así que una sola biblioteca comprometida se propaga a todos los sitios que la cargan. Los WAF, los logs de CDN y los escáneres del lado del servidor no ven ninguna anomalía, porque el ataque ocurre completamente en el navegador.
Polyfill.io es el caso más documentado de esta categoría. Una utilidad gratuita y de amplia confianza estaba presente en cientos de miles de sitios. Los nuevos propietarios la convirtieron en una superficie de ataque de la noche a la mañana, y ningún propietario de sitio cambió una sola línea de código.
Cómo funcionan los ataques a la cadena de suministro web: cuatro vectores principales
Los ataques a la cadena de suministro web comparten el mismo modelo de abuso de confianza pero llegan a los sitios a través de diferentes puntos de entrada.
| Tipo de ataque | Cómo funciona | Cómo encaja el ataque de polyfill.io |
|---|---|---|
| Apropiación de CDN / dominio | El atacante adquiere un dominio que los sitios ya cargan mediante etiquetas de script | Funnull compró polyfill.io; los sitios siguieron cargándolo sin ningún cambio de código |
| Secuestro de paquetes npm | Un paquete popular es apropiado o se publica un typosquat; los pipelines de CI descargan la versión maliciosa a la compilación | No fue este ataque, pero el riesgo es el mismo si el output de compilación incorpora el paquete en el lado del cliente |
| Compromiso de repositorio de código abierto | Se toma el control de la cuenta de un mantenedor; se publica una versión maliciosa en el paquete oficial | El repositorio de GitHub de polyfill.io cambió de propietario junto con el dominio |
| Confusión de dependencias | Un nombre de paquete interno se registra en el registro público; la compilación descarga por defecto la versión del atacante | No fue este ataque, pero afecta a sitios que empaquetan y sirven dependencias desde su propia CDN |
El hilo común: en los cuatro casos, código que tú no escribiste acaba ejecutándose en los navegadores de tus usuarios con el mismo nivel de confianza que tu propio JavaScript.
El ataque de Polyfill.io a la cadena de suministro web: registro completo
La versión corta
- El dominio polyfill.io se vendió a Funnull en febrero de 2024. Para junio servía redirecciones maliciosas.
- No existe un CVE para todo el incidente; el más cercano, CVE-2024-38526, está acotado a la herramienta de documentación pdoc que cargaba polyfill.io, no al ataque en sí.
- La escala real fue de 490.000+ sitios web, no los 100.000 ampliamente citados. Esa cifra era el límite de resultados por defecto de PublicWWW. cside reportó la cifra real primero.
- El payload capturado era una redirección solo en móvil a sitios de estafa y apuestas, diseñada para evadir a los investigadores.
- El 2025-05-29, la OFAC sancionó a Funnull y a su administrador Liu Lizhi.
- A fecha de 2026-05-18, más de 61.000 páginas siguen incrustando polyfill.io. Si la tuya es una de ellas, elimínalo.
Cronología completa (2009-2026)
| Fecha | Evento |
|---|---|
| 2009-2010 | Remy Sharp acuña el término "polyfill"; la idea se extiende por la comunidad de desarrollo web |
| 2014 | Andrew Betts construye el servicio polyfill.io en Financial Times Labs; una etiqueta de script adapta los polyfills a cada navegador |
| 2014-10-28 | HTML5 se convierte en Recomendación del W3C; los navegadores evergreen, con actualización automática, pronto hacen que polyfill.io sea en gran medida innecesario |
| ~2023 | El Financial Times cede el proyecto a su mantenedor de toda la vida, Jake Champion |
| Feb 2024 | El dominio polyfill.io y su repositorio de GitHub se venden a Funnull, una empresa operada desde China |
| 2024-02-25 | Andrew Betts advierte públicamente: "Si tu sitio web usa polyfill.io, elimínalo INMEDIATAMENTE" |
| 2024-02-29 | Cloudflare publica un espejo seguro en cdnjs para reducir el riesgo de cadena de suministro; Fastly levanta su propio espejo unos días antes |
| 2024-06-24 | El investigador japonés "piyokango" señala el comportamiento malicioso |
| 2024-06-25 | Sansec publica su análisis forense; cside publica el mismo día y reporta la escala real de 490.000+ |
| 2024-06-26 | Cloudflare empieza a reescribir automáticamente polyfill.io hacia su espejo; Google avisa a los anunciantes afectados |
| 2024-06-27 | Namecheap suspende el dominio polyfill.io |
| 2024-07-02 | Censys cuenta de forma independiente 384.773 hosts afectados |
| 2025-05-29 | La OFAC sanciona a Funnull y al administrador Liu Lizhi; el FBI vincula 548 CNAMEs de Funnull a 332.000+ dominios |
| 2026-05-18 | 61.593 páginas siguen incrustando polyfill.io |
La cifra de los "100.000 sitios" era errónea
Casi todos los reportes sobre este ataque usaron la misma cifra: aproximadamente 100.000 sitios. Esa cifra es un artefacto de la herramienta, no una medición del ataque.
Los investigadores, cside incluido, usaron PublicWWW para encontrar todas las páginas que contenían el snippet de polyfill.io. PublicWWW limita los resultados a 100.000 por defecto. Así que todos los recuentos que se apoyaron en ella se quedaron en "100.000+". Cuando ejecutamos la búsqueda más allá del límite, la cifra real era de más de 490.000 sitios web.
Esto importa porque el conjunto afectado no era aleatorio. Estaba muy sesgado hacia destinos de mucho tráfico y mucha confianza: bancos, sitios gubernamentales, grandes editoriales y marcas conocidas. Reportar "100.000" subestimaba un ataque casi cinco veces mayor. cside sacó a la luz la cifra real de 490.000+, corrigiendo el registro público, y el recuento independiente de Censys de 384.773 hosts el 2024-07-02 confirma que la escala superaba con creces los 100.000.
Qué hacía realmente el código malicioso
El comportamiento que se capturó, decodificó y publicó era una redirección. El informe forense de Sansec del 2024-06-25 mostró que el script manipulado enviaba a algunos visitantes móviles a través de un typosquat falso de Google Analytics, googie-anaiytics[.]com (fíjate en las letras intercambiadas), y de ahí a sitios de apuestas deportivas y para adultos.
La sofisticación técnica es lo que lo hizo peligroso y difícil de detectar. La redirección:
- se activaba solo en dispositivos móviles, nunca en escritorio;
- variaba según la región geográfica y según la hora del día;
- afectaba a cada dispositivo o IP una sola vez, de modo que ni una víctima ni un investigador podían reproducirla al recargar;
- se silenciaba cuando detectaba a un usuario administrador o la presencia de analítica web;
- venía con blindaje anti-ingeniería inversa.
Como polyfill.io era un servicio dinámico por diseño, el operador podía servir código limpio a un visitante y código malicioso al siguiente. Subresource Integrity no podía ayudar, porque fija un hash de un archivo fijo y este servicio no tenía un archivo fijo. El script se ejecutaba como código de primera parte en el propio origen de cada sitio, así que tenía acceso al DOM, los formularios y las cookies de esa página, y figuraba en las allowlists de CSP de cientos de miles de dominios de confianza.
¿Fue solo una redirección? Esa es la parte honesta y sin resolver. La deofuscación independiente del payload recuperado encontró lógica de redirección y nada más: ni captura de pulsaciones de teclas ni robo de credenciales. Pero el diseño por petición significa que una variante dirigida a un único visitante de alto valor no tendría por qué aparecer nunca en ningún escaneo público. La redirección es lo que se capturó. Qué más pudo ejecutarse durante esos meses no puede demostrarse en un sentido ni en otro. Expusimos el argumento de la capacidad en detalle en El ataque de Polyfill.io: mucho más que un simple ataque de redirección.
Para el reportaje completo del incidente de la época, consulta El ataque de Polyfill explicado y nuestro reporte del mismo día, Más de 490k sitios web atacados en un ataque a la cadena de suministro web.
¿Existe un CVE para el ataque de Polyfill.io?
No hay un único CVE asignado al incidente de Polyfill.io en sí. El identificador más cercano en la National Vulnerability Database es CVE-2024-38526, pero está acotado a pdoc -una herramienta de documentación de API en Python que enlazaba a polyfill.io en los documentos que generaba (corregido en pdoc 14.5.1)-. No cubre cdn.polyfill[.]io ni el conjunto más amplio de sitios afectados. Si gestionas un programa de vulnerabilidades, rastrea este incidente por sus dominios afectados (cdn.polyfill[.]io, además de los relacionados bootcdn[.]net, bootcss[.]com, staticfile[.]net, staticfile[.]org y unionadjs[.]com) en lugar de por un único CVE, y referencia CVE-2024-38526 solo para la exposición de pdoc.
La conexión con Funnull y las sanciones de 2025
Polyfill.io no fue un hecho aislado. El comprador del dominio, Funnull, dirigía una operación mucho mayor.
El 2025-05-29, la Oficina de Control de Activos Extranjeros (OFAC) del Tesoro de EE. UU. sancionó a Funnull Technology Inc. y a su administrador, Liu Lizhi. El Tesoro vinculó la infraestructura de Funnull a más de 200 millones de dólares en pérdidas reportadas por víctimas en EE. UU. por estafas de inversión, el patrón que a menudo se llama pig butchering. Su comunicado describió la conexión con polyfill sin nombrar el servicio: en 2024 Funnull "compró un repositorio de código usado por desarrolladores web y alteró maliciosamente el código para redirigir visitantes de sitios web legítimos hacia sitios de estafa y sitios de apuestas online."
El mismo día, el FBI vinculó 548 CNAMEs de Funnull a más de 332.000 dominios. Esto es blanqueo de infraestructura: alquilar espacio cloud y de CDN de buena reputación a través de cuentas ilícitas y revenderlo a estafadores para que los sitios maliciosos parezcan legítimos y sean difíciles de retirar. Cubrimos las sanciones y lo que significan para los equipos de seguridad en Funnull sancionada: lo que el ataque de Polyfill.io reveló sobre el blanqueo de infraestructura.
Quién sigue expuesto
Las sanciones perturban a una empresa. No eliminan código de tu sitio. A fecha de 2026-05-18, PublicWWW todavía listaba 61.593 páginas que contenían polyfill.io, más de un año después de que el dominio fuera suspendido.
Ese residuo es la verdadera lección. Las dependencias del navegador siguen incrustadas mucho después de que un dominio quede bloqueado, porque la gente no elimina las cosas. Cada una de esas páginas sigue apuntando a un dominio que ya ha sido convertido en arma una vez.
Cómo encontrar y eliminar Polyfill.io hoy
Empieza por las páginas que tocan login, checkout, creación de cuenta, pago y datos personales.
- Busca en tu código fuente, gestores de etiquetas, plantillas de CMS y snippets heredados las referencias a
polyfill.io, además de los dominios relacionadosbootcdn[.]net,bootcss[.]com,staticfile[.]net,staticfile[.]orgyunionadjs[.]com. - Elimina las referencias. Los navegadores modernos ya no necesitan estos polyfills, así que borrarlos es más seguro que cambiarlos por un espejo.
- Asocia cada script de terceros restante con un dueño, un propósito, un alcance de página y un nivel de acceso a datos.
- Marca los scripts que cargan más scripts, construyen URLs dinámicamente o se comportan de forma distinta según el user agent, la región o la sesión.
- Usa Subresource Integrity solo donde un script sea estático y el proveedor soporte hashes estables.
- Refuerza la Content Security Policy en los flujos sensibles, empezando en modo report-only.
- Monitoriza lo que los scripts hacen realmente en tiempo de ejecución, para que un cambio de propiedad o un nuevo payload sea visible cuando usuarios reales cargan la página.
Qué enseña este ataque sobre la seguridad de la cadena de suministro web
El ataque de Polyfill.io funcionó porque se trató la confianza como algo permanente. Un script aprobado una vez siguió ejecutándose después de que cambiara la empresa que lo respaldaba y después de que cambiara el código que servía. Los logs del servidor no lo vieron. Los cuestionarios de proveedores no lo detectaron. El navegador lo ejecutó de todos modos.
Esa brecha, entre la inclusión de confianza y la ejecución en tiempo real, es exactamente lo que cside se construyó para cerrar. cside trabaja en la capa del navegador, donde los scripts de terceros realmente se ejecutan. Muestra qué scripts cargan en páginas reales, a qué llaman, cómo cambian y si intentan comportamientos sospechosos como redirecciones inesperadas o accesos a datos. En el caso de Polyfill.io, esa visión en tiempo de ejecución es lo que marca una dependencia de confianza en el momento en que se vuelve hostil.
El próximo polyfill.io ya está en algún lugar de la web, incrustado y de confianza. La única forma fiable de detectarlo es vigilar lo que hacen tus scripts, no solo quién los publicó. Protege tu sitio gratis con cside y ve cada script que tus usuarios cargan de verdad.
