TL;DR: Polyfill.io attack timeline
- The count was wrong: The headlines said 100,000 sites and that was wrong, because it was the default result cap of the PublicWWW search tool the researchers used, and the actual footprint was much larger and heavier on high-trust properties.
- The real footprint: cside ran the search past the cap and found over 490,000 websites carrying polyfill.io, and Censys independently counted 384,773 affected hosts on 2 July 2024 before OFAC sanctioned Funnull on 29 May 2025.
- Trust is not a control: If a single vendor script can flip malicious after being trusted since 2015, source-based approval is not a control, so monitor runtime behavior on every session instead of trusting a one-time vendor sign-off.
Short on time? See cside's in-browser Magecart and skimmer blocking. It covers everything below in one deployment.
Quick answer: A web supply chain attack compromises a third-party library or CDN service that legitimate websites already trust, then uses that trust to run attacker-controlled code in every visitor's browser. The Polyfill.io attack is the clearest documented example: the trusted polyfill service was acquired by Funnull in February 2024, turned malicious by June, and hit more than 490,000 websites before anyone noticed. This page explains how the attack category works, documents the Polyfill.io incident in full, and shows what your site needs to do differently.
Update 2026-07-19: Added a section on web supply chain attack types and how the category works, plus new FAQ entries. The core Polyfill.io timeline and data are unchanged.
What is a web supply chain attack?
A web supply chain attack compromises a third-party JavaScript library, CDN, or service that legitimate websites load and trust. Because the page loads that code as if it were its own, the attacker gains code execution in every visitor's browser without touching the target site directly.
A web supply chain attack has a few defining properties. The victim site approved the script once, and the attacker inherits that trust permanently. The payload runs client-side, after the server has already sent the page, so one compromised library propagates to every site that loads it. WAFs, CDN logs, and server-side scanners see no anomaly, because the attack happens entirely in the browser.
Polyfill.io is the most documented case in this category. A free, widely trusted utility sat on hundreds of thousands of sites. New owners turned it into an attack surface overnight, and no site owner changed a single line of code.
How web supply chain attacks work: four main vectors
Web supply chain attacks share the same trust-abuse model but reach sites through different entry points.
| Attack type | How it works | How the polyfill.io attack fits |
|---|---|---|
| CDN / domain takeover | Attacker acquires a domain that sites already load via script tags | Funnull bought polyfill.io; sites kept loading it without any code change |
| npm package hijacking | A popular package is taken over or a typosquat is published; CI pipelines pull the malicious version into the build | Not this attack, but the risk is the same if build output embeds the package client-side |
| Open-source repository compromise | Maintainer account is taken over; a malicious release is pushed to the official package | The polyfill.io GitHub repo changed ownership along with the domain |
| Dependency confusion | An internal package name is registered on the public registry; the build pulls the attacker's version by default | Not this attack, but affects sites that bundle and serve dependencies from their own CDN |
The common thread: in all four cases, code you did not write ends up executing in your users' browsers with the same trust level as your own JavaScript.
The Polyfill.io web supply chain attack: full record
The short version
- The polyfill.io domain was sold to Funnull in February 2024. By June it was serving malicious redirects.
- There is no incident-wide CVE; the closest, CVE-2024-38526, is scoped to the pdoc documentation tool that loaded polyfill.io, not the attack itself.
- The real scale was 490,000+ websites, not the widely quoted 100,000. That figure was PublicWWW's default result cap. cside reported the true number first.
- The captured payload was a mobile-only redirect to scam and betting sites, built to evade researchers.
- On 2025-05-29, OFAC sanctioned Funnull and its administrator Liu Lizhi.
- As of 2026-05-18, more than 61,000 pages still embed polyfill.io. If yours is one of them, remove it.
Full timeline (2009-2026)
| Date | Event |
|---|---|
| 2009-2010 | Remy Sharp coins the term "polyfill"; the idea spreads through the web development community |
| 2014 | Andrew Betts builds the polyfill.io service at Financial Times Labs; one script tag tailors polyfills to each browser |
| 2014-10-28 | HTML5 becomes a W3C Recommendation; evergreen, auto-updating browsers soon make polyfill.io largely unnecessary |
| ~2023 | The Financial Times hands the project to its long-time maintainer, Jake Champion |
| Feb 2024 | The polyfill.io domain and GitHub repository are sold to Funnull, a Chinese-operated company |
| 2024-02-25 | Andrew Betts warns publicly: "If your website uses polyfill.io, remove it IMMEDIATELY" |
| 2024-02-29 | Cloudflare publishes a safe cdnjs mirror to reduce supply-chain risk; Fastly stands up its own mirror days earlier |
| 2024-06-24 | Japanese researcher "piyokango" flags the malicious behavior |
| 2024-06-25 | Sansec publishes its forensic disclosure; cside publishes the same day and reports the real 490,000+ scale |
| 2024-06-26 | Cloudflare begins auto-rewriting polyfill.io to its mirror; Google warns affected advertisers |
| 2024-06-27 | Namecheap suspends the polyfill.io domain |
| 2024-07-02 | Censys independently counts 384,773 affected hosts |
| 2025-05-29 | OFAC sanctions Funnull and administrator Liu Lizhi; the FBI ties 548 Funnull CNAMEs to 332,000+ domains |
| 2026-05-18 | 61,593 pages still embed polyfill.io |
The "100,000 sites" number was wrong
Almost every report about this attack used the same figure: roughly 100,000 sites. That number is an artifact of the tool, not a measurement of the attack.
Researchers, cside included, used PublicWWW to find every page containing the polyfill.io snippet. PublicWWW caps results at 100,000 by default. So every count that relied on it landed at "100,000+." When we ran the search past the cap, the real number was more than 490,000 websites.
This matters because the affected set was not random. It skewed heavily toward high-traffic, high-trust destinations: banks, government sites, major publishers, and well-known brands. Reporting "100,000" undersold an attack that was nearly five times larger. cside surfaced the true 490,000+ figure, correcting the public record, and Censys's independent count of 384,773 hosts on 2024-07-02 confirms the scale was far past 100,000.
What the malicious code actually did
The behavior that was captured, decoded, and published was a redirect. Sansec's forensic report on 2024-06-25 showed the tampered script sending some mobile visitors through a fake Google Analytics typosquat, googie-anaiytics[.]com (note the swapped letters), and on to sports-betting and adult sites.
The tradecraft is what made it dangerous and hard to catch. The redirect:
- fired only on mobile devices, never desktop;
- varied by geographic region and by time of day;
- hit each device or IP only once, so neither a victim nor a researcher could reproduce it on refresh;
- went quiet when it detected an admin user or the presence of web analytics;
- shipped with anti-reverse-engineering armor.
Because polyfill.io was a dynamic service by design, the operator could serve clean code to one visitor and malicious code to the next. Subresource Integrity could not help, because it pins a hash of a fixed file and this service had no fixed file. The script ran first-party in each site's own origin, so it had access to that page's DOM, forms, and cookies, and it sat on the CSP allowlists of hundreds of thousands of trusted domains.
Was it only a redirect? That is the honest, unresolved part. Independent deobfuscation of the recovered payload found redirect logic and nothing else: no keystroke capture, no credential theft. But the per-request design means a variant aimed at one high-value visitor need never appear in any public scan. The redirect is what was caught. What else may have run during those months cannot be proven either way. We made the capability case in detail in The Polyfill.io attack: more than just a redirect attack.
For the full incident write-up from the time, see The Polyfill attack explained and our same-day report, More than 490k websites targeted in a web supply chain attack.
Is there a CVE for the Polyfill.io attack?
There is no single CVE assigned to the Polyfill.io incident itself. The closest identifier in the National Vulnerability Database is CVE-2024-38526, but it is scoped to pdoc, a Python API-documentation tool that linked to polyfill.io in the docs it generated (fixed in pdoc 14.5.1). It does not cover cdn.polyfill[.]io or the wider set of affected sites. If you manage a vulnerability program, track this incident by its affected domains (cdn.polyfill[.]io, plus the related bootcdn[.]net, bootcss[.]com, staticfile[.]net, staticfile[.]org, and unionadjs[.]com) rather than a single CVE, and reference CVE-2024-38526 only for pdoc exposure.
The Funnull connection and the 2025 sanctions
Polyfill.io was not a one-off. The domain's buyer, Funnull, ran a much larger operation.
On 2025-05-29, the U.S. Treasury's Office of Foreign Assets Control sanctioned Funnull Technology Inc. and its administrator, Liu Lizhi. Treasury tied Funnull's infrastructure to more than $200 million in U.S. victim-reported losses from investment scams, the pattern often called pig butchering. Its notice described the polyfill connection without naming the service: in 2024 Funnull "purchased a repository of code used by web developers and maliciously altered the code to redirect visitors of legitimate websites to scam websites and online gambling sites."
The same day, the FBI tied 548 Funnull CNAMEs to more than 332,000 domains. This is infrastructure laundering: renting reputable cloud and CDN space through illicit accounts and reselling it to scammers so malicious sites look legitimate and stay hard to remove. We covered the sanctions and what they mean for security teams in Funnull sanctioned: what the Polyfill.io attack exposed about infrastructure laundering.
Who is still exposed
Sanctions disrupt a company. They do not remove code from your site. As of 2026-05-18, PublicWWW still listed 61,593 pages containing polyfill.io, well over a year after the domain was suspended.
That residue is the real lesson. Browser dependencies stay embedded long after a domain is blocked, because people do not remove things. Every one of those pages is still pointed at a domain that has already been weaponized once.
How to find and remove Polyfill.io today
Start with the pages that touch login, checkout, account creation, payment, and personal data.
- Search your source code, tag managers, CMS templates, and legacy snippets for
polyfill.io, plus the related domainsbootcdn[.]net,bootcss[.]com,staticfile[.]net,staticfile[.]org, andunionadjs[.]com. - Remove the references. Modern browsers no longer need these polyfills, so deletion is safer than swapping in a mirror.
- Map every remaining third-party script to an owner, a purpose, a page scope, and a data-access level.
- Flag scripts that load more scripts, build URLs dynamically, or behave differently by user agent, region, or session.
- Use Subresource Integrity only where a script is static and the provider supports stable hashes.
- Tighten Content Security Policy on sensitive flows, starting in report-only mode.
- Monitor what scripts actually do at runtime, so an ownership change or a new payload is visible when real users load the page.
What this attack teaches about web supply chain security
The Polyfill.io attack worked because trust was treated as permanent. A script approved once kept running after the company behind it changed and after the code it served changed. Server logs did not see it. Vendor questionnaires did not catch it. The browser executed it anyway.
That gap, between trusted inclusion and runtime execution, is exactly what cside was built to close. cside works at the browser layer, where third-party scripts actually run. It shows which scripts load on real pages, what they call, how they change, and whether they attempt suspicious behavior such as unexpected redirects or data access. In the Polyfill.io case, that runtime view is what flags a trusted dependency the moment it turns hostile.
The next polyfill.io is already on the web somewhere, embedded and trusted. The only reliable way to catch it is to watch what your scripts do, not just who shipped them. Secure your site for free with cside and see every script your users actually load.
