Researchers: polyfill.io, which offers JavaScript polyfills, is being used to infect 100K+ websites with malware, after a Chinese CDN bought the domain in 2024
The RegisterJessica Lyons
Context & Ripple Effects
This incident turns a widely reused JavaScript utility into a distribution point: a single third-party domain can affect many sites that embed its code. Earlier coverage had already found widespread exposure to known-vulnerable JavaScript libraries, underscoring how inherited front-end dependencies can outlive their security review.
The reported domain ownership change matters because sites may continue loading an external script without changing their own application code. It fits a broader record of legitimate web channels being used to deliver malicious JavaScript, including malware served through an e-file provider's site.
First-order effects
Sites still loading polyfill.io can expose their visitors to the reported malicious script, making the affected publishers immediate incident-response targets.
Developers and site operators need to remove, replace, or otherwise stop relying on the compromised external dependency; the domain buyer becomes a critical security dependency for every embedded deployment.
Second-order effects
Web teams are likely to review externally hosted JavaScript more broadly, especially dependencies loaded from domains whose ownership or delivery infrastructure can change independently of the site.
Security vendors and maintainers face greater demand for inventory and monitoring of client-side dependencies, rather than vulnerability scanning alone; the earlier library-vulnerability exposure study illustrates the scale of that maintenance gap.
Third-order effects
If such incidents recur, front-end supply-chain security will increasingly center on control of delivery paths—domains, CDNs, and hosted scripts—not only the integrity of package source code.
The pattern could push organizations toward tighter ownership verification, self-hosting, and explicit governance for third-party browser code, though the practical balance will vary with the cost of maintaining those assets.
The trend: The incident is part of a shift in software supply-chain risk from individual vulnerable libraries toward the trusted infrastructure that delivers code to large numbers of sites.
Can someone explain why the owner of the .io TLD isn't legally responsible for immediately nuking polyfill.io because it's literally the same as “buying a phone exchange do you can MitM all conversions, and you are that man”? …
fwiw, I just blocked some polyfill.io domains that are being used for this supply chain attack ( https://cside.dev/... in latest commit to my SNAFU list: https://github.com/... #pihole
Given supply chain risk, Cloudflare launched an alternative endpoint to polyfill under cdnjs in February 2024. We would strongly encourage immediate replacement of any remaining links to polyfill with the cdnjs alternative endpoint. https://blog.cloudflare.com/ ...
When I worked at PayPal I knew it would be irresponsible to use a third party service without an SLA so I grabbed the accompanying module and deployed it alongside our app so we could get the benefits with reduced risk. My concern was well-founded. https://kentcdodds.com/...
If your website uses https://polyfill.io/, remove it immediately. In Feb, a Chinese company bought the domain & Github account. Since then, this domain was caught injecting malware on mobile devices via any site that embeds https://cdn.polyfill.io/ https://sansec.io/...
After our Polyfill publication, someone launched a DDoS attack against our infra. We restored our primary services, but now the attack has shifted to our payment provider who has temporarily suspended us. https://x.com/... [image]
Google is now sending a warning about loading 3rd party JS from domains like polyfill . io bootcss . com bootcdn . net & staticfile . org that may do nasty things to your users if your site uses JS from these domains. [image]