A third party script on your pages runs with the full trust of your site. The polyfill.io case showed what happens when that third party changes hands. Would you notice? Check for an inventory of external scripts, integrity pinning, a content security policy with reporting, and an owner who watches domain changes.
What happened?
According to Sansec's research, a Chinese company acquired the polyfill.io domain and its GitHub account in February 2024. Sansec published its findings on 25 June 2024 and reported that more than 100,000 sites embedded the script, naming JSTOR, Intuit and the World Economic Forum among notable users.
Sansec reports the injected code redirected users on certain mobile devices to a sports betting site through a fake analytics domain. It reportedly activated only on some devices and at some hours, skipped admin users, and delayed execution when it detected analytics tools. Because the script was generated from HTTP headers, Sansec believes there could be several attack vectors.
On 27 June 2024 Cloudflare began rewriting cdn.polyfill.io requests to its own version, and Namecheap put the domain on hold. Sansec flagged further domains linked to the same actor on 28 June. The original polyfill author advised against using polyfill at all, since modern browsers no longer need it.
Why is it hard to catch?
The code on your own servers never changed. The change happened elsewhere, and the behavior was designed to avoid administrators and analytics. Teams that looked only at their own repositories saw nothing.
What should the checklist cover?
Answer each as yes or no for your own sites. A no is a gap to schedule, not blame.
Inventory
- Can you list every external script and stylesheet loaded by each of your production pages?
- Does the list name an owner and a reason for each?
- Does a build step or scan fail when a new external host appears?
Pinning
- Do external scripts that you must keep use Subresource Integrity? MDN explains that the browser compares the file to a hash you provide, and refuses to run it if no hash matches.
- Do those scripts carry the crossorigin attribute, which MDN says is required for integrity checks on cross origin files?
- Do you accept that a pinned hash must be updated whenever the file changes, and have a process for it?
A limit to know: a script that is generated per request, like the polyfill service reportedly was, cannot be pinned by a single hash. For those, copy the file to your own storage or remove it.
Policy and reporting
- Is there a content security policy that limits which hosts can serve scripts?
- Do you receive reports when the browser blocks or sees something unexpected? MDN describes an Integrity-Policy header, with a report only mode, that can require integrity metadata on scripts and report violations.
Ownership signals
- Does anyone watch for changes in ownership or behavior of the domains you depend on?
- Do you have a rule to review any external dependency whose maintainer or registrant changes?
Response
- Could you remove a third party script from every site within hours?
- Do you know which customers saw pages with the script, if you must notify them?
What is the cheapest fix?
Ask whether you need the script. In this case, the guidance from the original author and from Sansec was to remove references to polyfill.io altogether. Every script you delete is a trust relationship you no longer manage.
What to do
- Crawl your production pages and list every third party host.
- Remove scripts you no longer need.
- Self host or pin with integrity any that remain, with the crossorigin attribute.
- Add a content security policy and a reporting endpoint, starting in report only mode.
- Add a build check that fails on a new external host.
- Review domain ownership of critical dependencies twice a year.
Quick check
Would Subresource Integrity have stopped this?
For pages that pinned a fixed file, yes, since the browser would refuse a changed file. A script generated per request cannot be pinned with one hash, so removal or self hosting is the safer route.
Does a content security policy block malicious code from an allowed host?
No. A policy limits which hosts may serve scripts. If you allow a host that later turns hostile, the policy permits it. Pair it with integrity pinning and reports.
Sources
Last reviewed: 18 October 2026.
