The polyfill.io incident showed that a script you include from someone else's domain is code you run on your own pages. After the domain and GitHub account changed hands in February 2024, Sansec reported in June that the service was serving malicious redirects to visitors. Removing the reference, or self-hosting a pinned copy, ends the exposure.
What is the timeline?
This account relies on Sansec's research, published 25 June 2024 and updated afterward.
- February 2024: a Chinese company bought the polyfill.io domain and its GitHub account, according to Sansec.
- After the sale: complaints about suspicious behaviour were removed from the GitHub repository, Sansec says.
- 25 June 2024: Sansec reported that more than 100,000 sites embedded the script from the cdn.polyfill.io domain, and that the code injected on some requests redirected certain mobile visitors to a betting site through a fake analytics domain.
- 28 June 2024: Sansec flagged further domains it tied to the same actor, including bootcdn.net, staticfile.net and unionadjs.com, active since at least June 2023.
- Response: Sansec reports that Cloudflare began rewriting requests for the domain to its own mirror, Namecheap put the domain on hold, and Google began blocking ads for ecommerce sites that used it.
Sansec notes the malicious code was selective. It targeted certain mobile devices at certain hours, skipped visitors it believed were administrators, and delayed itself when analytics scripts were present. That makes it hard to see by loading your own site.
Why was this hard to spot?
The script was generated from HTTP request headers, so each browser could receive a different file. Sansec considered several attack paths likely for that reason. A site owner testing from a desktop at a quiet hour could see nothing wrong.
Notably, the original polyfill author advised against using the service at all, because modern browsers no longer need most polyfills.
What does this say about third-party scripts?
The code was never in your repository, so scanners that read your lockfile would not list it. The dependency was a URL in an HTML template. Many teams track packages carefully and track script tags not at all.
Ownership change is the risk that needs watching. A domain can be sold, lapse, or be compromised. Your page trusts whoever controls it today, not whoever controlled it when you added the tag.
What to do
- Search every template and tag manager for script and stylesheet references to domains you do not control. List them with an owner.
- Remove polyfill.io references. Sansec and the original author both recommend this.
- Self-host the files you still need, pinned to a reviewed version, and serve them from your own origin.
- Where you must load from a CDN, pin an exact file and use subresource integrity, so a changed file is refused by the browser. This only works for static files, not for responses that vary per request.
- Add a Content Security Policy that lists allowed script sources, and report violations to a collector you watch.
- Monitor domain ownership and DNS for third parties you depend on, where the registry data allows it.
- Treat a vendor going quiet or changing owners as a trigger to re-review that dependency.
- Test as a mobile visitor and use a real user monitoring or header-capture tool, because selective payloads skip desktop checks.
Where does tooling help?
An inventory that includes browser-loaded scripts closes the gap that package scanners leave. Safeguard's dependency inventory covers packages; the template and tag review in step 1 is something you still do by hand or with your own tooling, and it belongs on the same register.
Quick check
Did the polyfill.io problem come from a vulnerability in the code?
No. Sansec attributes it to a change of domain ownership followed by malicious code being served, not to a flaw in the original open source project.
Would subresource integrity have helped?
Only with a pinned static file. Sansec notes the polyfill output was generated from request headers, so a fixed hash did not fit that service. Self-hosting is the safer fix.
Sources
Last reviewed: 18 October 2026.
