The Polyfill.io Supply Chain Attack: When a Trusted CDN Script Turned Malicious

For over a decade, a free service called Polyfill.io did something useful and unglamorous: it served small snippets of JavaScript ("polyfills") that let modern web features work in older browsers. Hundreds of thousands of websites simply added one line — a script tag pointing to cdn.polyfill.io — and let the service handle the rest. It was a convenience, trusted and forgotten.

In June 2024, that forgotten convenience turned into one of the largest web supply chain attacks on record. The very same script tag that had quietly improved browser compatibility for years began delivering malicious code to unsuspecting visitors across more than 100,000 websites — including properties associated with major brands. Nobody breached those websites. They didn't have to. The attacker simply took over the script the websites had already chosen to trust.

How a Useful Service Became a Weapon

The roots of the attack trace to February 2024, when the polyfill.io domain and its associated GitHub project changed hands and came under the control of a China-based content delivery network company, Funnull. The transfer immediately raised concern in the web development community. The original creator of the project publicly warned that no website actually needed polyfill.io anymore and urged everyone to remove it — cautioning that the domain was now in unknown hands.

Those warnings proved prophetic. Because the script was loaded live from the CDN on every page view, whoever controlled the domain controlled the code executing in the browsers of every visitor to every site that embedded it. The new operators had inherited a position of enormous, silent trust across the web.

The Malicious Payload

In late June 2024, security firm Sansec published research showing that cdn.polyfill.io was injecting malicious JavaScript into the sites that embedded it. The attack was deliberately stealthy and evasive. Rather than firing on every visit, the malicious code activated selectively — primarily targeting mobile users, avoiding execution when it detected web analytics services or what looked like an administrator or developer, and in some cases delaying activation to dodge inspection. When it did fire, it redirected victims to scam destinations, including sports betting and fraudulent sites.

This selectivity is what made the attack so dangerous. A site owner spot-checking their own pages from a desktop browser would likely see nothing wrong, while mobile visitors in the wild were being redirected. The malicious behavior hid from exactly the people most likely to notice it.

Estimates of scale varied as researchers mapped the fallout. Multiple security vendors put the number of affected websites at more than 100,000, and follow-up analysis identified hundreds of thousands of hosts referencing the compromised domain and related infrastructure. Affected properties reportedly included sites associated with large, well-known brands — a reminder that scale and brand recognition offer no protection against a compromised dependency.

The Response

The industry reaction was swift. The domain registrar suspended the polyfill.io domain shortly after the disclosure, cutting off the malicious delivery. Google began warning advertisers whose landing pages referenced the compromised script. Cloudflare and Fastly — which had already set up safe, static mirrors of the legitimate polyfill code months earlier when the ownership change first raised alarms — gave site operators a clean alternative, and Cloudflare automatically rewrote requests for sites behind its network. Subsequent reporting by security journalists and researchers connected the malicious infrastructure to a broader web of fraudulent activity.

But the cleanup exposed an uncomfortable truth: many organizations did not even know they were exposed. The polyfill.io tag had often been added years earlier by a developer who had since moved on, buried in a template or a third-party widget, never inventoried and never reviewed. You cannot remove a risk you don't know you have.

Why This Is a Vendor and Supply Chain Risk Problem

Polyfill.io is a textbook illustration of a risk category that traditional vendor management routinely misses: the third-party code your applications execute is part of your supply chain, even when no contract, invoice, or procurement record exists for it.

1. "Shadow vendors" hide in your codebase

A free script loaded from a CDN is a vendor relationship in every way that matters — it runs code on your customers — but it rarely appears in a vendor register. These shadow dependencies bypass procurement, never get a security review, and accumulate over years. A serious TPRM program has to account for the third parties your engineers add, not just the ones your purchasing department signs.

2. Concentration and inherited trust amplify the blast radius

When 100,000+ sites all load the same script, a single takeover compromises them all at once. This is the web-layer version of the technology concentration risk that turned incidents like the CrowdStrike outage into global events. Shared dependencies create shared, correlated failure.

3. Point-in-time review cannot catch a live, mutable dependency

A script served live from a CDN can change at any moment — and in this case it changed only for certain users. An annual questionnaire or a one-time code review would have found nothing. Managing this kind of risk requires continuous monitoring of what your applications actually load and execute, paired with technical controls. Subresource Integrity (SRI) hashes and Content Security Policy (CSP) headers, for example, can prevent a tampered script from running at all.

The Bigger Picture

Polyfill.io was not the first attack of its kind — the Magecart campaigns had been weaponizing third-party JavaScript for years — and it will not be the last. The web's convenience model, where any site can pull live code from anyone, is fundamentally a supply chain on autopilot. Every embedded script, analytics tag, chat widget, and font loader is a standing trust relationship that can be inherited, sold, or hijacked.

The organizations that weathered Polyfill.io best were the ones that already knew what their applications loaded and from whom. In a world where your dependencies can turn against you without warning, that visibility is no longer optional — it is the foundation of modern third-party risk management.