Resumen: Polyfill.io y la redirección condicional por UA en 490.000 sitios
- Los threat feeds son reactivos: Los threat feeds no te salvaron. Polyfill[.]io siguió redirigiendo a usuarios móviles a sitios para adultos y de apuestas durante días después de las advertencias de la comunidad, porque los feeds son reactivos y este payload solo se activaba una vez por IP.
- Detectado donde otros fallaron: El archivo manipulado alcanzó a más de 490.000 sitios, redirigía según el User-Agent, y cside detectó el payload inyectado allí donde todos los proveedores de reputación no vieron nada. cside vigila el comportamiento de los scripts, así que los payloads condicionados por geolocalización, hora o sesión siguen activando nuestras alertas.
- Elimina estos dominios ya: Si tu código todavía carga polyfill[.]io, bootcdn[.]net, bootcss[.]com, staticfile[.]net, staticfile[.]org o unionadjs[.]com, elimina cualquier referencia esta misma semana. Si no puedes eliminarlas, añade monitorización de scripts en tiempo de ejecución para que el próximo cambio silencioso de propietario no se convierta en otro año de ataques sin detectar.
¿Poco tiempo? Consulta el bloqueo de Magecart y skimmers en el navegador de cside. Cubre todo lo de abajo en un solo despliegue.
Recientemente, más de 490.000 sitios web fueron objetivo de un ataque a la cadena de suministro web. (Censys contó de forma independiente 384.773 hosts que aún hacían referencia al dominio el 2024-07-02.) Fuimos los primeros en informar sobre la escala real del ataque en nuestro artículo original. Para la historia completa de 2024-2026, consulta nuestra cronología y análisis completos de Polyfill.io.
Algunos artículos que nos mencionaron incluyen:
NOTA: Si un sitio web sigue referenciando hoy los dominios polyfill[.]io, bootcdn[.]net, bootcss[.]com, staticfile[.]net, staticfile[.]org y unionadjs[.]com, sigue expuesto a este ataque.
¿Qué era el proyecto del servicio Polyfill?
Polyfill era originalmente un proyecto de código abierto que permitía a los sitios web usar funciones modernas de JavaScript en navegadores antiguos como Internet Explorer. Esto era necesario mientras la comunidad online iba migrando gradualmente hacia frameworks de navegador más modernos.
A pesar de ser en gran medida innecesario, ya que el volumen de tráfico de Internet Explorer se volvió insignificante, miles de sitios web todavía hacen referencia a este dominio.
Creado en octubre de 2014, Polyfill recibía actualizaciones regulares. En febrero de 2024, el colaborador Andrew Betts (@triblondon en X) advirtió a la comunidad cuando el dominio polyfill[.]io fue adquirido por una empresa china a sus propietarios originales:
Si tu sitio web usa
, elimínalo INMEDIATAMENTE.
Yo creé el proyecto del servicio polyfill, pero nunca he sido propietario del nombre de dominio y no he tenido ninguna influencia sobre su venta.
, Andrew Betts (@triblondon)
Cómo Polyfill[.]io facilitó un ataque a la cadena de suministro web
Los dominios usados para servir scripts populares de terceros son un gran problema de seguridad porque pueden cambiar dinámicamente sin avisar a nadie ni a nada. Esto incluye servir scripts totalmente distintos según tu navegador, User-Agent, geolocalización, IP o cualquier otro vector. Tienen vía libre para decidir qué sirven, a quién y bajo qué criterio.
Polyfill[.]io y Polyfill[.]com fueron comprados por una empresa china llamada Funnull.
Tras esta venta y la publicación de Andrew en X, el colaborador de Github "renchap" aporta contexto adicional sobre la transacción:
"Polyfill[.i]o era propiedad del equipo web del Financial Times, luego pasó a gestión comunitaria, y el último mantenedor vendió el proyecto a una extraña empresa china de CDN, que lo sacó de Fastly (la plataforma de CDN / edge compute que ejecutaba el código OSS del servicio) y empezó a manipular los archivos devueltos."
El colaborador de GitHub "munierujp" mencionó que Jake Champion decidió transferir la propiedad de Polyfill a Funnull:
El enlace al que hace referencia ha dejado de funcionar desde entonces. Tampoco existe una página disponible en Internet Archive.
Andrew Betts y Jake Champion, ambos exempleados del Financial Times y propietarios originales de Polyfill, trabajan ahora en Fastly.
Otros miembros de la comunidad en este hilo de Github mencionan que:
"Funnull es conocida por prestar servicios a las industrias de apuestas y pornografía."
Esto fue un preludio de lo que realmente ocurrió tras el ataque.
Antes de todo esto, Polyfill se ejecutaba en la plataforma edge compute de Fastly. Dado que esto no está disponible en la nube china, "renchap" observó en Github que polyfill[.]io tenía ahora un registro CNAME hacia polyfill[.]io.bsclink[.]cn.
Tras el sospechoso cambio de propietario, Fastly montó una réplica de la biblioteca Polyfill como dominio alternativo para que la gente pudiera seguir usando el servicio, polyfill-fastly.io. Lo pusieron a disposición apenas unos días después de comunicarse la venta.
Un día después del anuncio de Fastly, Cloudflare lanzó un endpoint alternativo para Polyfill[.]io en CDNJS para mitigar el riesgo de ataque.
Esto no es una solución 100% perfecta. Las vulnerabilidades de cdnjs de 2021 mostraron al mundo que incluso los grandes CDN de JavaScript de buena reputación pueden sufrir riesgos en la cadena de suministro. Esto demuestra que confiar únicamente en las fuentes no basta: hace falta una monitorización continua para detectar anomalías. Esta es parte de la razón por la que se fundó cside.
¿Qué sucedió en el ataque de Polyfill?
Un archivo JavaScript manipulado inyectado por el dominio polyfill[.]io redirigió a un porcentaje de usuarios a sitios web para adultos y de apuestas según su User-Agent. Un usuario japonés de X, "piyokango", fue probablemente el primero en informar de este ataque el 24 de junio.
El 25 de junio, "Huli" consiguió reproducir este ataque y lo publicó en inglés. Se topó con una publicación de GitHub del día anterior, donde un usuario llamado "alitonium" explica cómo lo descubrió.
Al cumplirse ciertas condiciones, el archivo JavaScript alterado se revela. Una vez decodificado, muestra un enlace falso de Google Analytics, googie-anaiytics[.]com/gtags.js. Fíjate en que este dominio es un caso de typosquatting: se usa la letra i en lugar de una l, tanto en "googie" como en "anaiytics". La empresa de seguridad Sansec publicó un desglose forense completo del payload. (El CVE-2024-38526 relacionado se asignó a pdoc, la herramienta de documentación de Python que cargaba polyfill.io, no al incidente en su conjunto.)
Este dominio de typosquatting redirige a los usuarios a varios sitios de apuestas deportivas y para adultos, aparentemente en función de su región. Este es uno de los sitios a los que fuimos redirigidos:
Aunque en este caso el ataque a la cadena de suministro web solo redirigió a los usuarios, podría haber ocurrido cualquier cosa. Desde ataques de abrevadero hasta la captura de datos de tarjetas de crédito. Un ataque de abrevadero es aquel en el que los atacantes atacan un sitio web que visita con frecuencia un grupo concreto de personas. Infectan el sitio con malware para que, cuando los miembros de ese grupo lo visiten, sus equipos se infecten.
Como la mayoría de las medidas de seguridad habituales se basan únicamente en comprobar fuentes, ataques como este siguen ocurriendo hoy en día. Como demostró este ejemplo concreto, los proveedores de threat feeds no marcaron el dominio polyfill[.]io como malicioso hasta días después de los primeros reportes. Esto responde a un enfoque de experimentar primero, reaccionar después que, por su propia naturaleza, permite que ataques como este sigan sucediendo.
cside se fundó específicamente para cuestionar la dependencia de los threat feeds, ya que el ritmo de aparición de nuevos métodos de ataque es mayor que la velocidad a la que estos feeds los procesan. Esto quedó claro hace poco con la crisis de la National Vulnerability Database (NVD), en la que más de 10.000 ataques conocidos esperaban en una cola de revisión antes de ser revisados y procesados como Common Vulnerabilities and Exposures (CVE).
En el caso de Polyfill, nuestro motor pudo detectar los polyfills inyectados y evitó que se ejecutaran. Protegió al usuario y alertó al propietario del sitio web sobre el código malicioso.
Cuando "Huli", del blog mencionado más arriba, publicó sobre este cambio de comportamiento, empezamos a redactar nuestro propio informe, que se publicó poco después. Al principio informamos de que unos 110.000 sitios web se habían visto afectados. Más tarde corregimos esa cifra hasta la estimación actual, que supera los 490.000 sitios web.
Esto afectó a marcas destacadas como el servicio de streaming Hulu (propiedad de Disney), The Guardian, Intuit, y muchas más.
Notamos que el sitio web de Polyfill[.]io añadió una cabecera de 'Cloudflare Security Protection' a su página de inicio entre el 7 y el 8 de marzo. Nos pareció extraño en su momento, tanto a nosotros como a otros miembros de la comunidad. Un día después de nuestro informe, Cloudflare confirmó que no habían autorizado su uso.
También observamos que la redirección maliciosa ocurría solo una vez por IP. Probablemente estaba diseñado así para evitar la detección durante el mayor tiempo posible.
Las consecuencias
El dominio Polyfill[.]io se había comprado a través de Namecheap. Durante la conmoción, Namecheap cerró el dominio, según informó MalwareHunterTeam en X:
Actualización muy importante/grande: en la última hora,
finalmente decidió eliminar el dominio polyfill[.]io.
No 👏 para ellos, para nada, porque les ha llevado mucho más tiempo del debido, pero probablemente merezcan un pequeño agradecimiento por hacerlo tarde en vez de no hacerlo nunca...
🤷♂️
, MalwareHunterTeam (@malwrhunterteam)
El sitio volvió a estar disponible en Polyfill[.]com, pero también ha sido cerrado desde entonces.
Google también reaccionó. Dejó de servir anuncios a sitios web que incluían esos scripts y presionó a los propietarios de esos sitios retirándoles sus ingresos publicitarios para que eliminaran los scripts. Google también envió avisos en los que mencionaba otros dominios, como observó Michal Špaček en X:
Google está enviando ahora un aviso sobre la carga de JS de terceros desde dominios como polyfill.io, bootcss.com, bootcdn.net y staticfile.org, que pueden hacer cosas desagradables a tus usuarios si tu sitio usa JS de estos dominios.
, Michal Špaček (@spazef0rze)
Lo que nos lleva de nuevo a MalwareHunterTeam, que siguió investigando. Mencionaron que todos estos dominios eran gestionados por el mismo grupo. Esto se confirmó cuando se filtraron en GitHub un token de API de Cloudflare y un ZoneID.
Estos dominios incluían Polyfill[.]io, pero también bootcdn[.]net, bootcss[.]com, polyfill[.]io, staticfile[.]net, staticfile[.]org y unionadjs[.]com.
También encontraron pruebas de que se servía código malicioso a través de estos dominios, afectando a cientos de miles de sitios web.
Actualización importante sobre la situación del ataque de tipo cadena de suministro de polyfill[.]io.
Cuando Google empezó a avisar de que los anuncios de páginas/sitios que usan polyfill[.]io podían suspenderse, mencionaron 3 dominios más:
bootcss[.]com
bootcdn[.]net
staticfile[.]org
Pero de alguna manera todos…
, MalwareHunterTeam (@malwrhunterteam)
Estos dominios tampoco figuraban como maliciosos en los proveedores de threat feeds. Y eso que algunos de ellos llevaban sirviendo ataques a la cadena de suministro desde junio de 2023. Eso es más de un año de ataques sin detectar.
Esperaba que los ataques de tipo cadena de suministro que usaban esos servicios/dominios llevaran ocurriendo desde algún momento del año pasado, pero solo ahora se ha confirmado, gracias a
(
), que se remonta al menos hasta junio pasado, así que algo más de 1 año…
, MalwareHunterTeam (@malwrhunterteam)
cside no existía todavía para detectar esos ataques.
En un intento de salvar las apariencias, una cuenta de X con el nombre Polyfill empezó a acusar a Cloudflare, a los medios y a otros de difamación. La cuenta se había creado en febrero de 2024, probablemente en torno al momento en que se produjo la venta del dominio.
Alguien nos ha difamado maliciosamente. No tenemos riesgos en la cadena de suministro porque todo el contenido está cacheado de forma estática. La participación de terceros podría introducir riesgos potenciales en tu sitio web,
pero nadie haría esto, ya que pondría en peligro nuestra propia reputación.
Ya hemos…- Polyfill (@Polyfill_Global)
El 30 de junio, el actor malicioso intentó volver a poner su sitio en línea en polyfill[.]site. Desde entonces ha sido eliminado.
El 1 de julio, reapareció y volvió a publicar su producto. Esta vez, bajo polyfillcache[.]com. Esperamos que también lo eliminen pronto.
Las lecciones aprendidas
Este ataque muestra el riesgo ampliado que suponen los scripts de terceros. Una vez integrados en miles de sitios web, se convierten en objetivos prioritarios para actores maliciosos. Con solo unas líneas de código, esos sitios web y millones de visitantes quedan en riesgo. Es un área sensible de la cadena de suministro web, y sin embargo las herramientas para monitorizar la superficie de ataque van por detrás y apenas se usan.
cside se creó para evitar que esto suceda. Nuestro script, que se carga en primer lugar, hace que todos los demás pasen por nuestro motor de análisis. Allí comprobamos el código completo en busca de cualquier cosa maliciosa, basándonos en más de 60 parámetros. Si nuestro motor de detección decide que no es seguro, se bloquea la carga del script. También optimizamos estos scripts para compensar cualquier latencia que introduzca el proxy, y en muchos casos consiguen ser más rápidos en lugar de más lentos.
Nota del editor (2026): Este párrafo describe la arquitectura original de cside de 2024. cside ahora realiza una monitorización completa de los scripts del lado del cliente: un único fragmento de JavaScript de primera parte que observa lo que los scripts de terceros hacen realmente en los navegadores de visitantes reales, incluidos los payloads condicionados por geolocalización, por hora o por sesión (como este) que muestran código limpio a los escáneres y rastreadores. El proxy de entrega de scripts descrito arriba se retiró a principios de 2026.
El ataque de Polyfill es un recordatorio: las medidas de seguridad que no comprueban el código completo antes de servirlo a los usuarios no logran detectar ataques nuevos y acaban dependiendo de que la comunidad los detecte, dejando en riesgo tanto a los sitios web como a sus visitantes.
En este caso, el actor malicioso optó solo por redirigir a los usuarios a sitios para adultos y de apuestas, pero podría haber pasado algo mucho peor: capturar pulsaciones de teclado en un pequeño porcentaje de sesiones según geolocalización y hora del día, inyectar malware, minar criptomonedas o reescribir botones en los sitios para redirigir a portales de pago suplantados. Desde una simple redirección hasta la captura de datos de tarjetas de crédito, los ataques de JavaScript del lado del cliente pueden hacer de todo. El ataque de Polyfill podría haber tenido un impacto mucho más negativo; en cierto modo, tuvimos suerte. Que esto sirva de recordatorio: debemos monitorizar nuestros scripts del lado del cliente. Profundizamos en por qué esto fue mucho más que un simple ataque de redirección, y en 2025 la historia se cerró cuando la OFAC sancionó a Funnull, la empresa detrás del dominio.
Puedes proteger tu sitio en segundos usando cside. Nuestro nivel gratuito protege tu sitio frente a este ataque y otros similares.
