Polyfill.io era un servicio de CDN que entregaba, bajo demanda, fragmentos de JavaScript para dar soporte a funciones modernas en navegadores antiguos. En febrero de 2024 el dominio fue vendido, y en junio los scripts que servía empezaron a redirigir a los visitantes hacia páginas fraudulentas en más de cien mil sitios, que solo mantenían la misma etiqueta
<script>de siempre.
A ninguno de esos sitios lo hackearon. La etiqueta <script> siguió apuntando a la misma dirección de siempre. Lo que cambió de dueño fue la dirección. Por eso el caso incomoda tanto: un equipo de seguridad podía haber hecho todo bien de su lado y aun así servir código malicioso a sus propios clientes.
El caso del Banco Horizonte Digital: una historia de confianza quebrada
El Banco Horizonte Digital es un ejemplo compuesto, no un cliente. Su comportamiento, en cambio, se repitió en buena parte de los sitios afectados.
El banco cargaba Polyfill.io en el portal de banca en línea desde hacía años, para mantener la compatibilidad con navegadores antiguos. En febrero, cuando el dominio cdn.polyfill.io cambió de dueño, no pasó nada. El servicio siguió respondiendo, los scripts siguieron cargando, el portal siguió funcionando. Meses después, una parte de los clientes empezó a caer en páginas de phishing que copiaban la pantalla de acceso, y las credenciales escritas allí iban al servidor del atacante.
La detección tardó semanas. Nadie en el banco tenía la lista de lo que el portal cargaba desde afuera, así que no había dónde buscar. Cuando apareció el origen, miles de clientes ya habían pasado por la página falsa, y quedó notificar a los clientes, responder al regulador y explicar en público lo que había ocurrido. Ninguno de esos pasos vino de una falla en el código del banco.
El ascenso de los ataques a las cadenas de suministro digitales
El caso Polyfill.io entra en un patrón más grande. Los ataques a la cadena de suministro digital llevan años subiendo y la curva todavía no da señales de doblarse.
El crecimiento en números
Los ataques a la cadena de suministro aumentaron más de 600% en 2021 frente al año anterior, según reportó PaloAlto Networks. En 2024, 75% de todas las cadenas de suministro de software reportaron haber sufrido ataques (Resilience Forward). Gartner proyectaba que, para 2025, 45% de las organizaciones del mundo habrían sufrido ataques en sus cadenas de suministro de software, tres veces la cifra de 2021.
Tiempo de detección
40% de los ataques a la cadena de suministro siguen sin detectarse por más de 6 meses. Seis meses alcanzan para que el código malicioso llegue a los sistemas internos, para que el atacante deje un segundo acceso plantado y para que los datos salgan de a poco, sin pico de tráfico que llame la atención. Cuando llega la cuenta, cubre medio año de operación del atacante.
Los ataques a las cadenas de suministro digitales explotan la confianza entre proveedores y consumidores, inyectando código malicioso en bibliotecas ampliamente utilizadas. La detección tardía permite que el compromiso se propague por millones de sitios.
Anatomía del ataque Polyfill.io
Cómo funcionaba Polyfill.io
Polyfill.io era un CDN legítimo. Detectaba el navegador del visitante y devolvía solo los polyfills que ese navegador necesitaba, lo que ahorraba código y resolvía la compatibilidad sin trabajo del desarrollador. Millones de sitios apuntaban a él. Esa base instalada es justamente lo que convirtió al dominio en un objetivo: comprar una sola dirección daba acceso a todos ellos de una vez.
La adquisición maliciosa
En febrero de 2024, el dominio cdn.polyfill.io fue adquirido por una entidad con intención maliciosa. Los nuevos dueños no cambiaron nada al principio. El servicio siguió entregando los mismos scripts, a la misma velocidad, y quien monitoreaba disponibilidad no vio diferencia. El código malicioso entró después, mezclado con el código legítimo.
La entrega era selectiva. Solo una parte de los visitantes recibía la redirección, elegida por geolocalización, tipo de dispositivo y hora de acceso. Un escáner corriendo desde un centro de datos en horario laboral recibía la versión limpia. Así fue como el compromiso atravesó meses antes de que alguien lo publicara.
El impacto global
Más de 100.000 sitios cargaban el script, entre ellos bancos, plataformas de comercio electrónico, portales de gobierno y sistemas de salud. Millones de visitantes pasaron por esas páginas en el período, y cada uno recibió lo que cdn.polyfill.io decidiera mandar en ese momento. Mirando la página, ninguno podía saber que el origen del script había cambiado de manos meses antes.
Técnicas de ataque utilizadas
Los scripts maliciosos venían ofuscados y mezclados con el código legítimo, lo que tumbaba el análisis estático y la mayoría de las herramientas automatizadas. La redirección solo se disparaba para una fracción de los visitantes, filtrada por geolocalización, dispositivo y hora.
Las páginas de phishing copiaban el sitio legítimo campo por campo. Las credenciales escritas iban a servidores de los atacantes, y las cookies y el almacenamiento local se manipulaban para reinfectar al visitante en la visita siguiente, que es la razón por la que la limpieza parcial no aguantaba.
El caso Polyfill.io expone varias fallas críticas en la forma en que las organizaciones gestionan su superficie de ataque y sus dependencias externas.
Falta de inventario de dependencias
La falla más común también es la más simple: la organización no sabe qué carga. Una biblioteca de terceros entra al proyecto sin registro, un CDN externo se agrega directo en la plantilla, la versión nunca se fija y el proveedor del servicio jamás llega a ser una línea en ninguna lista. Del control se puede discutir después. Antes de eso, nadie protege lo que no sabe que existe.
Ausencia de monitoreo continuo
Incluso donde la dependencia se documentó una vez, nadie vuelve a mirarla. Un dominio crítico cambia de dueño y no hay alerta. El script servido cambia de contenido y nadie compara el hash. Una aplicación empieza a hablar con un dominio con el que nunca habló y el tráfico pasa. En el caso de polyfill.io fueron meses de ventana abierta, y la ventana no era técnica. Era de proceso.
Confianza implícita
Servicio popular se vuelve sinónimo de servicio seguro. Un CDN que existe hace diez años entra sin revisión, una biblioteca con millones de descargas entra sin revisión, y la reputación pasada se toma como garantía futura. Polyfill.io tenía exactamente esa reputación en enero de 2024. En febrero tenía otro dueño.
Tiempo de respuesta lento
Cuando la historia se hizo pública, parte de las organizaciones sacó el script el mismo día. Otras tardaron semanas, porque primero tuvieron que averiguar en qué aplicaciones estaba la etiqueta. Sin plan escrito, el tiempo de respuesta se vuelve el tiempo que toma encontrar a quien sabe responder, y la comunicación con el cliente se atrasa junto.
Cómo el Attack Surface Management previene los ataques a la supply chain
El Attack Surface Management (ASM) trabaja esas cuatro fallas en el orden en que aparecen: descubrir lo que existe, vigilar lo que cambia, decidir lo que importa, responder.
Una plataforma de ASM mapea sola lo que la organización carga desde afuera: CDNs, bibliotecas de terceros, versiones en uso y las integraciones que algún equipo subió sin pasar por seguridad. En el caso de polyfill.io, ese inventario habría respondido en segundos la pregunta que trabó a todo el mundo por semanas: ¿cuáles de nuestros sitios cargan cdn.polyfill.io?
Monitoreo de cambios
Un inventario solo envejece. El ASM observa lo que se mueve dentro de él. Un cambio de titularidad en WHOIS y DNS de un dominio que su aplicación carga. Un hash del script servido que dejó de coincidir con el de la semana pasada. Un comportamiento nuevo en un JavaScript que antes solo leía el DOM y ahora abre conexión hacia afuera. Cualquiera de esas tres señales habría aparecido en el caso Polyfill.io, y la primera apareció cuatro meses antes de que el ataque fuera noticia.
Análisis del comportamiento de scripts
Parte de las herramientas va más allá de comparar hashes y ejecuta el script en un sandbox para ver qué hace: una redirección que nadie pidió, la lectura de un campo de formulario, una llamada a un dominio fuera de la lista conocida. Esa capa atrapa al Polyfill.io comprometido incluso si el cambio de dueño hubiera pasado inadvertido.
Priorización basada en riesgo
Las dependencias no son intercambiables. Un script en la pantalla de acceso de la banca en línea y el mismo script en la página institucional tienen riesgo técnico idéntico e impactos que no se comparan. El orden de trabajo sale de cuatro preguntas: cuántos usuarios pasan por ahí, qué dato circula en esa pantalla, qué tan fácil es explotarlo y qué se rompe si la dependencia se cae. Es lo que le permite a un equipo chico atender primero lo que duele.
Respuesta rápida y coordinada
Con el inventario listo, la respuesta cambia de naturaleza. La lista de activos afectados sale en el momento, el bloqueo de la dependencia comprometida se aplica por política en lugar de ticket por ticket, y la comunicación con clientes y reguladores sale con número en lugar de estimación. La diferencia entre remediar en un día y remediar en tres semanas casi nunca está en la corrección. Está en saber dónde aplicarla.
Validación continua de proveedores
La evaluación de proveedores suele ser un cuestionario respondido una vez, al firmar el contrato. El ASM lo cambia por verificación que corre sola: reputación del dominio del tercero en feeds de inteligencia de amenazas, historial de incidentes, certificación que venció y nadie renovó. Confianza revisada cada semana es una cosa distinta de confianza firmada en 2019.
Lecciones aprendidas del caso Polyfill.io
Para las organizaciones
Dos cosas cambian el resultado, y ninguna de ellas es comprar una herramienta. La primera es tener la lista de lo que sus aplicaciones cargan desde afuera, mantenida por descubrimiento automático y no por planilla. La segunda es tratar esa lista como algo vivo: alguien tiene que enterarse cuando un elemento cambia de dueño, de hash o de comportamiento.
El resto es defensa en profundidad, y ahí lo específico vale más que el principio. Una Content Security Policy restrictiva limita desde dónde el navegador acepta un script. Subresource Integrity fija el hash del archivo cargado, lo que resuelve para scripts de contenido fijo y no resuelve para un CDN que arma la respuesta por navegador. Ensaye el plan de respuesta en mesa una vez al año, porque el día del incidente es mal día para descubrir quién tiene acceso al DNS.
Para la industria
Del lado de la industria, el agujero es de aviso. Cuando un dominio que millones de sitios cargan cambia de dueño, no existe canal que avise a esos sitios. La transferencia es una operación comercial privada y el comprador no le debe explicaciones a quien depende del servicio. Mientras eso no cambie, cada organización se entera por su cuenta.
Lo que hay disponible hoy es más modesto y ya ayuda: publicar indicadores de compromiso temprano, incluso con el análisis a medias, y documentar las TTPs del ataque en vez de solo anunciar que hubo uno.
Implementando protección contra ataques a la supply chain
Paso 1: inventario completo
Levante lo que entra en la página desde afuera: biblioteca JavaScript de terceros en producción, CDN, API externa, SaaS conectado, plugin instalado. Hecho a mano, ese levantamiento nace desactualizado. Tiene que venir de descubrimiento continuo.
Paso 2: controles técnicos
El CSP le dice al navegador desde dónde puede cargar un script. Bien configurado, tira abajo el dominio que apareció de la nada:
Content-Security-Policy:
default-src 'self';
script-src 'self' https://trusted-cdn.com;
connect-src 'self' https://api.trusted.com;
El SRI fija el hash del archivo. Si el contenido cambia un byte, el navegador se niega a cargarlo:
<script src="https://cdn.example.com/lib.js"
integrity="sha384-oqVuAfXRKap7fdgcCY5uykM6+R9GqQ8K/ux..."
crossorigin="anonymous"></script>
Paso 3: monitoreo continuo
Compare el hash del script externo en cada ejecución. Alerte cuando la aplicación contacte un dominio nuevo. Bloquee y registre el intento de enviar datos de formulario fuera de la lista conocida. Es poca cosa y cubre la mayor parte de lo que ocurrió en el caso Polyfill.io.
Paso 4: procesos de validación
Una dependencia nueva entra con aprobación y revisión de seguridad. Una dependencia vieja se revisa por calendario, no cuando da problema. La versión sube con pruebas. La dependencia que ya nadie usa se saca, y esa última suele ser la más fácil y la más olvidada.
Paso 5: plan de respuesta
Escriba el procedimiento antes: cómo confirmar el compromiso, quién aísla la dependencia, quién habla con el cliente, quién habla con el regulador. Pruébelo en simulacro. Un plan que nunca se ensayó tarda casi lo mismo que ningún plan.
El papel del ASM en la prevención
El caso Polyfill.io no expuso una técnica nueva. Expuso que la mayoría de las organizaciones no sabía responder qué código de terceros corría en sus propias páginas. Sin esa respuesta, el resto del programa de seguridad trabaja a ciegas.
El ASM entrega esa respuesta y la mantiene al día. Descubrir activos es la parte que aparece en las demostraciones. La parte que cambia la semana del equipo es la segunda: saber, en la semana en que cambia, qué cambió.
Conclusión
Con 40% de los ataques a la cadena de suministro pasando más de 6 meses sin detectarse y 75% de las organizaciones ya habiendo sufrido un ataque en su cadena de suministro de software, planear para el caso de recibir uno dejó de ser pesimismo. Es cuenta de calendario.
Lo que todavía se controla es el tiempo entre el compromiso y el descubrimiento. Ese tiempo depende de algo que la mayoría de las empresas no tiene: la lista al día de lo que sus aplicaciones cargan desde afuera, y alguien a quien avisarle cuando esa lista cambia. Si hoy no sabe armar esa lista, empiece por ahí.
Referencias
- PaloAlto Networks - Supply Chain Attacks Frequency and Severity Stats
- Resilience Forward - 75% of Software Supply Chains Exposed to Cyber Attacks
- MITRE ATT&CK Framework - Supply Chain Compromise (T1195)
- NIST Cybersecurity Framework - Supply Chain Risk Management
- OWASP Top 10 - Using Components with Known Vulnerabilities