Sansec reported in June 2024 that the polyfill.io domain, embedded by more than 100,000 sites, had been sold to a new owner and was serving code that redirected some mobile visitors. The fix for site owners was simple: stop loading scripts from domains you do not control.
What was reported
Sansec's research, published 25 June 2024 and updated through 28 June, says a company bought the domain and the associated GitHub account in February 2024. It reports that the served script targeted mobile devices, redirected some of them to a betting site, ran only at certain times, skipped users carrying admin cookies and varied by request headers. Sansec says the payload depended on headers, so it expected other attack paths too.
Cloudflare had earlier posted that the domain moved to a new provider, which raised community concern, and offered an alternative endpoint on its own CDN. The Cloudflare post describes the concern as a risk that a third party could alter code served to every site that loads it. Sansec lists further domains it flagged on 28 June.
Why this is a different kind of risk
Nothing was wrong with your code. A script tag pointing at someone else's domain means the owner of that domain can run code in your visitors' browsers. A change of owner changes who you trust, without any notice to you.
How to audit scripts on your site
- List every external script and stylesheet domain your pages load. Browser developer tools, a content security policy report mode or a crawler can all do this.
- For each one, ask who owns it, why it is needed, and whether you could host the file yourself.
- Remove ones you do not need. Modern browsers no longer need the polyfill code at all, per the original author, as Sansec notes.
- For the rest, host a copy yourself, or add subresource integrity so the browser rejects a changed file.
- Set a content security policy that lists the domains allowed to serve scripts.
- Monitor for new script sources appearing on your pages.
Limits of integrity checks
Subresource integrity only works for files that do not change. A service that returns different code per browser, as polyfill services do, cannot be pinned by a single hash. That is a reason to avoid such services or to host the versions you need.
Ownership changes are a signal
Domains expire and change hands. Project GitHub accounts do too. If a dependency's domain, repository or maintainer changes, treat that as an event worth a look, just as you would a new maintainer on a package.
Quick check
Is deleting the polyfill.io tag enough?
It removes the live risk. If you want the functionality, use a source you control, or drop it if your supported browsers no longer need it.
Would a content security policy have stopped this?
A policy that did not list the domain would have blocked it. If the domain was allowed, the policy would not have helped, which is why removing the dependency matters.
Sources
- Sansec, Polyfill supply chain attack, June 2024.
- Cloudflare, polyfill.io now available on cdnjs.
Last reviewed: 19 October 2026.
