Respuesta rápida: El ataque a la cadena de suministro de Polyfill.io empezó cuando el dominio polyfill.io, ampliamente incrustado, se vendió a Funnull en febrero de 2024 y empezó a servir JavaScript malicioso en junio. cside fue el primero en reportar la escala real del ataque: más de 490.000 sitios web, no los 100.000 que repitió casi todos los medios. Esa cifra menor era simplemente donde la herramienta de búsqueda dejaba de contar. Un año después, el Tesoro de EE. UU. sancionó a Funnull por la operación. Esta es la cronología completa, lo que hacía el código y cómo encontrarlo y eliminarlo.
El ataque de Polyfill.io es uno de los incidentes de cadena de suministro en el navegador más claros que se conocen. Una utilidad gratuita y de confianza estuvo años en cientos de miles de sitios. Los nuevos propietarios la convirtieron en una superficie de ataque de la noche a la mañana. Ningún propietario de sitio cambió una línea de código y, aun así, sus visitantes quedaron expuestos.
Esta página reúne toda la historia en un solo lugar: una cronología con fechas, la verdad detrás de la cifra de los "100.000 sitios", lo que hacía realmente el payload, el CVE, las sanciones a Funnull que vinieron después y una lista práctica de limpieza. Para análisis más profundos, cada sección enlaza a nuestra cobertura original de 2024 y 2025.
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. Que cside sacara a la luz la cifra real de 490.000+ es la corrección que el registro público necesitaba, 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.
El oficio 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 del lado del cliente
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.
