For years, adding <script src="https://cdn.polyfill.io/v3/polyfill.min.js"> to a page was standard advice. The service looked at the browser's user agent and sent back only the polyfills that browser needed. In June 2024 researchers at Sansec reported that the same URL was serving malware. Later scans counted more than 380,000 hosts still embedding it.
No website in this story was hacked in the usual sense. Each one was running exactly the code it had asked for. The attack was on the trust those sites had put in a domain they didn't control.
How it happened
• February 2024: the polyfill.io domain and its GitHub project were sold to Funnull, a CDN company. The original author of the Polyfill service, Andrew Betts, publicly warned that he had never owned the domain and that sites should remove it immediately. Cloudflare and Fastly put up safe mirrors.
• June 2024: Sansec disclosed that the CDN was injecting malicious code into responses for some visitors. Within days the domain registrar suspended the domain and Google started warning advertisers whose landing pages loaded it.
Why it was hard to spot
Because the service generated a different bundle per browser by design, every visitor already received slightly different JavaScript. That made a targeted payload easy to hide. Analyses of the code described several evasion tricks:
• Mobile only, and only some of the time. The injected function (named check_tiaozhuan, roughly "check redirect") checked for a mobile device and fired only under specific conditions and times.
• Avoid the people who would notice. It skipped visitors who looked like site admins and avoided running when web analytics were watching, using a delayed start.
• Look like analytics. The second stage loaded from a typo-squatted domain designed to resemble Google Analytics.
• Low-value destinations. Victims were sent to sports-betting and adult sites, so few site owners heard complaints that pointed back to the script.
When a payload only fires for a fraction of mobile visitors who are not logged in as admins, the site owner testing from a desktop will never see it.
The general pattern: client-side supply chain
Polyfill.io belongs to the same family as Magecart card skimming: the attacker gets code into the browser through something the site includes, such as a CDN script, a tag-manager container, a chat widget or an analytics snippet. The site's server and database can be fully patched and it still won't matter, because the malicious code runs in the visitor's browser with full access to the page, forms included.
Defences that would have contained it
1. Self-host what you can
Polyfills, fonts and libraries can be bundled and served from your own origin. Modern build tools (and modern browsers) mean many sites no longer need runtime polyfills at all. A dependency in your bundle is pinned and reviewed. A script from someone else's CDN changes whenever they decide.
2. Subresource Integrity for static third-party files
SRI adds a hash to the tag: <script src="..." integrity="sha384-..." crossorigin="anonymous">. If the file changes, the browser refuses to run it. SRI doesn't work for services like polyfill.io that return different content per browser. That is a reason to avoid such services for anything security-relevant.
3. Content Security Policy
A strict CSP script-src limits which origins can run script. It wouldn't block polyfill.io itself if you had allowed it, but it would block the second-stage loader from an unknown look-alike domain. Use report-to / report-uri so violations reach you: an unexpected domain in CSP reports is often the first sign of client-side compromise.
4. Inventory and monitor third-party scripts
Keep a list of every external script on your pages and who owns its domain. Watch for ownership changes, and test pages from mobile user agents and fresh, non-admin sessions, not only from your logged-in desktop. PCI DSS 4.0 now requires an inventory and integrity checks for scripts on payment pages for exactly this reason.
Quick check for your site
Search your templates and rendered HTML for polyfill.io, bootcss.com, bootcdn.net, staticfile.org and polyfill.com. Researchers linked several of these domains to the same operators. Then list every other <script src> that points off your origin and ask, for each one, whether you would notice if it changed tonight.
osec.one builds small, focused security tools. Start with passwordless logins for your app or site.
Explore osec.one