Summary
polyfill.io was a free, much-loved service that hundreds of thousands of websites embedded to make older browsers work, the kind of invisible utility you set up once and forget. That is exactly what made it dangerous. In February 2024 a Chinese-operated company bought the polyfill.io domain and its GitHub account from the original maintainer, who publicly warned that nobody should trust it anymore. Months later the CDN began injecting malware into the sites that still loaded its script (initial reports counted over 100,000; later scans found more than 384,000), redirecting mobile visitors to scam and betting sites. It is the lesson that a third-party script in your page is a permanent, live trust relationship, and that "who owns this domain now?" is a question you have to keep asking.
How it happened
polyfill.io served JavaScript "polyfills", small pieces of code that make modern web features work in older browsers, from cdn.polyfill.io, embedded through a simple <script> tag on what was first reported as 100,000-plus sites and later counted at more than 384,000. In February 2024 the domain and its GitHub repository were acquired by Funnull, a Chinese-operated CDN company. The project's original maintainer, Andrew Betts, immediately and publicly warned that the service should no longer be trusted and that modern browsers did not need it at all.
After the takeover, the CDN started injecting malicious JavaScript, and it did so cleverly to stay hidden. The code activated selectively, targeting mobile visitors, varying by time, and refusing to run when it detected an administrator's cookies or a security researcher, and it redirected victims to scam and sports-betting sites through a typosquatted fake Google Analytics domain (googie-anaiytics.com). Because every one of those sites was loading the script live, each was unknowingly serving the attack to its own users. It is a supply-chain attack carried out not by hacking, but simply by buying the domain and then abusing the trust that came with it.
The damage and response
The estimate of affected sites climbed from an initial 100,000-plus to more than 384,000 (Censys), with some reporting reaching 490,000, among them JSTOR, Intuit, and the World Economic Forum. After researchers raised the alarm in June 2024, the response was fast: Cloudflare deployed real-time rewrites that swapped polyfill.io links for its own safe mirror, Google blocked ads for impacted sites, and the domain's registrar, Namecheap, put it on hold. Researchers also found that a leaked Cloudflare API key in the polyfill repository exposed sibling CDN domains (bootcss, bootcdn, staticfile) referenced by over 1.6 million more hosts. In 2025 the US Treasury sanctioned Funnull and its administrator, tying the operation to more than $200 million in online-scam losses and naming the polyfill.io attack by name.
Why polyfill.io still matters
It is the live-third-party-script lesson, compounded by the risk of ownership changing hands. When you embed a remote <script>, you grant whoever controls that domain the power to run any code in your users' browsers, indefinitely, and that control can be sold to anyone without your knowledge. The defences are clear: self-host third-party scripts or lock them with Subresource Integrity (SRI) so a changed file is rejected, remove dependencies you do not actually need (modern browsers did not need polyfill.io), keep an inventory of every external resource your pages load, and watch for ownership and domain changes. It is the same CDN-served-malware pattern as the Ledger Connect Kit attack.
How to fix it
- Remove the polyfill.io script from your sites immediately, or repoint it to a trusted mirror (Cloudflare and Fastly published safe ones); modern browsers do not need it.
- Audit your pages for any other third-party scripts loaded live from domains you do not control, and self-host or SRI-lock them.
- Check analytics for malicious redirects served to your users during the window, and notify them if warranted.
How to avoid it
- Self-host third-party scripts or lock them with Subresource Integrity (SRI) so a changed file is rejected, rather than loading them live from a domain you do not control.
- Remove dependencies you do not actually need; the safest third-party script is the one you deleted.
- Watch for ownership and domain changes of services you embed; a sale can hand your users' browsers to a new, untrusted owner overnight.
- Maintain an inventory of every external resource your pages load, and review it the way you review code dependencies.
References
Related vulnerabilities
All Supply chain →- CRITICALGHSA-93qj-5q5v-3c2h
Trojanized pantheon-agents 0.6.1 and 0.6.2 on PyPI ship a credential stealer (supply-chain account compromise)
- CRITICALNPM-REDHAT-MIASMA-2026
In June 2026 the npm supply-chain worm finally produced something genuinely new and frightening: malicious packages that were signed and carried valid build provenance. Attackers used a compromised GitHub account inside Red Hat's own organisation to publish trojanised versions of 31 packages in the @redhat-cloud-services namespace through Red Hat's legitimate CI pipeline, so the poisoned releases arrived with authentic attestations proving they were built by the real build system. The payload, nicknamed Miasma, was a lightly re-skinned copy of Mini Shai-Hulud, a worm that a group called TeamPCP had open-sourced for anyone to reuse weeks earlier. No Red Hat customers were harmed, because Red Hat strips install scripts before deployment, but the permanent lesson is uncomfortable: a signature proves where a package was built, not that the build was clean.
- CRITICALNPM-AXIOS-2026
On 31 March 2026 the single most widely used HTTP client in the JavaScript world was turned into malware for about three hours. Axios carries well over 100 million weekly downloads and sits as a transitive dependency underneath a huge share of the npm ecosystem, so when a North Korea-nexus actor took over the maintainer's account and published two booby-trapped versions, the blast radius was enormous even though the bad versions were live only for one early-morning window. The poisoned releases pulled in a hidden dependency that ran on install and dropped a cross-platform remote access trojan onto developer machines and CI runners. It is the case study in why a few hours of a popular package being compromised is still a global incident, and in why a maintainer's own laptop is now a nation-state target.
- HIGHSC-NOTEPADPP-CHRYSALIS-2025
In 2025, a Chinese state-linked espionage group hijacked the update channel of Notepad++, one of the most widely installed Windows text editors, to plant a custom backdoor on a handful of carefully chosen targets. The attackers never touched Notepad++'s source code or its signing keys. Instead they compromised the third-party shared-hosting server that delivered updates, and abused the fact that the WinGUp updater shipped without any integrity check on what it downloaded (tracked as CVE-2025-15556). For machines on their target list, WinGUp was silently redirected to attacker-controlled servers that served a trojanized installer; everyone else kept receiving the genuine update. The campaign ran from roughly June to December 2025 and was only made public in February 2026 by Rapid7, with Kaspersky and Broadcom/Symantec corroborating it independently.
- HIGHSC-ESCAN-RELOAD-2026
On or around January 20, 2026, attackers who had broken into a regional update server for eScan, the antivirus product made by India's MicroWorld Technologies, pushed a trojanized Reload.exe through the legitimate update channel during a window of roughly two hours. The security software itself became the delivery vehicle for malware. The malicious binary carried eScan's code-signing identity, but its signature was actually invalid; it ran anyway because the updater trusted the channel rather than rigorously validating the signature. Once on a host, the malware rewrote the Windows HOSTS file to cut eScan off from its own update servers, blinded script scanning, and reached out to takedown-resistant command-and-control hosted on blockchain naming systems. Morphisec disclosed the campaign, with Kaspersky and Darktrace corroborating it independently.
- CRITICALNPM-SHAI-HULUD-2-2025
Shai-Hulud is the nightmare the npm ecosystem had long feared: a self-replicating worm. First seen in September 2025 and back in a more aggressive wave around 21-24 November 2025 ("The Second Coming"), it does not just poison one package and wait. When its malware runs in a developer's environment, it harvests every secret it can find, npm tokens, GitHub tokens, cloud keys, then uses those stolen npm tokens to automatically publish itself into other packages the victim maintains, spreading from maintainer to maintainer on its own. The second wave hit more than 25,000 GitHub repositories across roughly 500 compromised accounts, leaked the stolen secrets into public repos, and, if it failed to steal credentials, tried to wipe the victim's home directory. It is the moment supply-chain malware learned to propagate like a biological infection.