In February 2024, the original maintainer of polyfill.io sold the domain to a company called Funnull, and within four months the free JavaScript CDN embedded on more than 100,000 websites had become a malware distribution channel. For a decade, polyfill.io quietly served lightweight scripts that let older browsers run modern JavaScript, pulled in with a single <script src="https://cdn.polyfill.io/..."> tag on everything from government portals to Fortune 500 storefronts. On June 25, 2024, researchers at Sansec disclosed that the new owner had modified the service to inject redirect and tracking code into live responses, targeting mobile visitors while hiding the payload from admins, bots, and scanners. Namecheap suspended the domain two days later. By then, the polyfill.io attack had become one of the clearest public examples of a supply chain compromise executed through domain ownership transfer alone — no commit, no stolen credential, just a change in who controlled a DNS record everyone trusted.
What Is Polyfill.io and Why Did Over 100,000 Sites Depend On It?
Polyfill.io was a free content-delivery service that inspected each visitor's browser and served back only the JavaScript "polyfills" needed to make older browsers support modern web features, and it ended up embedded on more than 100,000 sites because it was fast, free, and endorsed for years by the developer community and major CDN documentation. It was created by Andrew Betts, a Financial Times engineer, in the mid-2010s and grew into one of the default answers to "how do I support IE11 and older Android browsers without bloating my bundle." Sites added it once, during initial build, with a script tag like polyfill.io/v3/polyfill.min.js?features=default, and rarely revisited the dependency again. That "set it and forget it" pattern — common to CDN-hosted scripts, font loaders, analytics tags, and chat widgets — is exactly what made the eventual takeover so effective: the attack surface was the collective inattention of thousands of unrelated engineering teams.
What Happened When the Domain Changed Hands in February 2024?
In February 2024, Andrew Betts sold the polyfill.io domain, along with control of the associated GitHub organization, to a company operating as Funnull, which security researchers later linked to infrastructure previously used in gambling-redirect and malvertising campaigns. Betts posted a public warning shortly after the sale, telling developers he no longer controlled the service and urging them to remove any reference to polyfill.io from their sites immediately. Cloudflare and Fastly, both of which had long recommended alternatives, echoed the warning. Despite that, adoption of the fix lagged for months — a pattern familiar from other domain and package-ownership handoffs, where the security advisory reaches a fraction of the sites that copy-pasted a script tag years earlier and never subscribed to any update channel for it.
How Did the Malicious Code Actually Work?
The injected script fingerprinted each visitor and only fired a malicious redirect for specific mobile user agents, while cloaking itself entirely from site administrators, analytics dashboards, and known security-researcher IP ranges. Sansec's analysis found the payload used delayed execution and conditional logic to avoid firing during business hours or when it detected WordPress admin sessions, ad-tech crawler agents, or requests coming from cybersecurity firms. Outbound callbacks were routed through typosquatted lookalike domains designed to blend into normal analytics traffic, such as lookalikes of Google Analytics hostnames, so a quick glance at browser network traffic wouldn't raise alarms. Confirmed victims were redirected to sports-betting sites and other low-value scam destinations rather than credential-harvesting pages, which is one reason detection took as long as it did — the blast radius looked more like nuisance adware than a targeted breach, until researchers correlated it across tens of thousands of unrelated domains.
How Many Sites and Brands Were Actually Affected?
Sansec identified more than 100,000 sites directly embedding the cdn.polyfill.io script at the time of disclosure, and follow-on scanning that counted transitive references and mirrors put total exposure above 380,000 domains. Confirmed or reported instances included Hulu, Mercedes-Benz, Warner Bros., Intuit, and multiple U.S. state and local government sites, none of which had intentionally added malicious code — they had simply never removed a four-year-old script tag. The number matters less than the shape of it: the sites affected had nothing in common technologically except a shared third-party dependency none of them monitored after initial integration. That is the defining signature of a modern software supply chain incident — impact measured in unrelated downstream organizations rather than a single breached network.
How Was the Polyfill.io Attack Detected and Shut Down?
Sansec's threat research team detected the malicious redirect behavior on June 25, 2024 by monitoring script changes served to client sites, and the response moved from disclosure to domain suspension in under 48 hours. Namecheap suspended the polyfill.io domain on June 27, 2024. Cloudflare and Fastly, which had already been urging customers off the service, stood up free automatic mirrors and began rewriting polyfill.io references for their own CDN customers to point at a safe, static replacement instead of the live domain. Google started blocking ads on pages that still referenced polyfill.io, adding a business-impact incentive on top of the security one. GitHub also stepped in to restrict access tied to the acquiring organization. The remediation took a coordinated, multi-vendor response rather than a single patch, because the compromise lived in DNS and domain ownership, not in a piece of code any one company could simply roll back.
What Does the Polyfill.io Incident Reveal About Third-Party Script and Supply Chain Risk?
It shows that a large share of software supply chain risk now sits outside your own repository, in scripts, packages, and domains you integrated once and never re-reviewed. Polyfill.io is a JavaScript CDN story, but the underlying failure mode — trust granted at integration time, never revisited as ownership or maintainers change — is identical to npm package takeovers like event-stream in 2018 or ua-parser-js in 2021, and to expired-domain attacks against abandoned S3 buckets and PyPI packages. Most of the 100,000+ affected sites had no Subresource Integrity (SRI) hash pinning the expected script content, no inventory listing polyfill.io as a runtime dependency, and no alerting on unexpected third-party script behavior. The incident is a direct argument for treating externally hosted scripts, CDN dependencies, and even DNS-linked infrastructure as first-class entries in your software bill of materials, not an invisible layer below the dependency graph your tooling actually scans.
How Safeguard Helps
Safeguard treats incidents like polyfill.io as a detection and prevention problem that starts well before an attacker ever ships a payload. Our SBOM generation and ingest pipeline captures third-party script and CDN dependencies alongside your package manifests, so a domain or maintainer change on something like polyfill.io shows up as a tracked component rather than an invisible script tag. Reachability analysis then tells you whether a flagged dependency is actually loaded on production pages your users hit, cutting through noise so teams aren't chasing every CDN reference equally. Griffin AI correlates ownership-transfer and typosquat signals across your dependency and script inventory to surface takeover risk before a Sansec-style disclosure forces a scramble, and our auto-fix PRs can pin Subresource Integrity hashes or swap a risky CDN reference for a vetted, self-hosted alternative automatically, closing the gap between "we found it" and "it's fixed" from months to hours.