What happened?
In late June 2024, researchers at Sansec dropped the finding that polyfill.io — a domain serving a humble JavaScript “polyfill” library embedded by hundreds of thousands of websites — had been sold, and its new owners rewrote the hosted script to inject malicious code: redirects to scam pages and phishing, mobile-only, triggered selectively so desktop QA never saw it. By June 27, when this post publishes, “100,000+ sites inherited a malicious script” was the headline, Cloudflare had stood up an auto-secure mirror, and the web was relitigating its third-party script addiction.
Quick Answer: polyfill.io’s new owner (Funnull) weaponized the domain in June 2024 — 385K+ embedded sites, 475M monthly visits — serving mobile/referer-conditional scam redirects that jammed security QA; remediation meant purging the tag (polyfills were no longer needed) or pinning self-hosted copies; arrests followed in 2025.
The sale chain read like a cautionary fable: a Chinese-registered buyer acquired the domain and GitHub org in February 2024; the code changed subtly from April; by June the S3-backed payload was serving conditional redirection to sports-betting and scam affiliates. Sansec’s telemetry, plus community OSS scans, sized the blast radius: hundreds of thousands of embeds — WordPress themes and plugins among them — and a total monthly footprint near half a billion visits. The nastiest detail was operational: the payload gated on mobile user-agents and referer conditions so standard desktop tests missed it entirely.
Anatomy of a supply-chain asset flip
The pattern had precedent — this was not the first time a genuinely valuable-but-neglected infrastructure asset was bought and weaponized, though the scale made it the century’s flagBearer so far. What made polyfill.io irresistible to a buyer: ubiquitous embeds, a trustworthy-seeming name, and an owner ready to sell without notifying dependents. The market lesson: any externally hosted “utility” script is one domain-transfer away from becoming an implant across its entire foreach of dependents, and the dependency graph has no notification mechanism when ownership changes hands.
| Date | Event |
|---|---|
| 2024-02 | Domain and GitHub organization acquired by new ownership after short public notice |
| 2024-04→ | Hosted script begins serving conditional malicious redirection (mobile plus specific referers) |
| 2024-06-25/26 | Sansec disclosure; Cloudflare auto-replaces polyfill.io requests with a safe mirror for its customers; Google delists malicious destinations |
| 2024-06-27 | Counts stabilize in the 100K–500K site range – depending on census method — this post publishes amid cleanup |
| 2024-06→07 | “polyfill hits back” round: DNSTXT-based retribution against Sansec; Namecheap seizes the domain; 2025 arrests of Taiwanese nationals linked to Funnull |
Why the polyfill was already obsolete
Aggravating irony: most embedders did not need the script anymore. The eponymous library back-filled ES5-era browser gaps; by 2024 every evergreen browser had native support for the relevant features, and the service’s own original author recommended everyone simply remove the tag years earlier. The lesson generalizes: dormant dependencies are silent liabilities without owners, they do not expire — they wait, embedded in themes and templates, until someone buys the upstream.
- Remove: if you embed polyfill.io today, delete the tag; it is dead weight at best, hostile at worst.
- Self-host and pin: any third-party script you must use belongs on your origin, SRI-hashed and version-locked, not fetched from a domain you do not control.
- CSP: default-src ‘self’-style policies with explicit allowlists turn “someone flipped the domain” from incident into non-event.
- Inventory: maintain a script-tag census of your properties (themes past and present); asset flips cannot be responded to in assets you did not know you ran.
FAQ
What did the malicious script actually do?
Served conditional redirects: mobile devices (and certain referer patterns) were bounced through an intermediary to scam and betting sites, likely earning affiliate revenue. No large-scale credential theft was required for the business model to work — traffic arbitrage paid fine. Later variants dallied with search-redirection and additional payloads, but redirect monetization was the core.
Were users of the CDN mirrors (jsDelivr, cdnjs) affected?
No — those served pinned copies of the open-source library code, not the polyfill.io domain’s rewritten payload. The compromise lived at the domain, not in the library source. Sites self-hosting or using mirrors with SRI were safe; sites hot-linking the service domain were the exposed class.
Who did it, and what happened to them?
Attribution converged on operators behind the Funnull CDN operation; Sansec tracked their infrastructure, the crew responded with petty DNS harassment against security researchers, and in 2025 authorities in Taiwan arrested Taiwanese nationals linked to Funnull in connection with the campaign — a rare supply-chain-to-handcuffs arc, even if the affiliate economics keep the model alive.
The bigger debate it ignited
Beyond cleanup, the hijack forced a structural question: how should the web treat widely-embedded, externally-hosted utility scripts? Interest sharpened around SRI adoption, “self-host everything you can” doctrine, and even proposals for ownership-change notifications in dependency chains. Meanwhile the incident entered marketing lore alongside the 2024 Edgeweight-style flips — proof that in the supply chain, the cheapest exploit is sometimes just buying the asset. Expect faster flipping going forward: the asset class now has a proven revenue model, and registrar-level intervention (Namecheap’s seizure here) became a precedent worth citing.
The mirror-war subplot
Cloudflare’s move deserves its own paragraph: it transparently stood up a clean, self-hosted replacement and began auto-serving it for sites requesting polyfill.io, converting an internet-wide cleanup into a plumbing fix for a large fraction of the web in days. Critics noted the precedent’s double edge – an infrastructure intermediary quietly rewriting third-party responses is exactly the capability defenders want here and fear everywhere else – and the debate matured into “intermediary responsibility” doctrine that resurfaced with every 2024-2025 supply-chain event. Meanwhile Funnull’s DNS-harassment retaliation against Sansec guaranteed the crew’s name stayed in every follow-up report, a self-inflicted reputational own goal.
Coda: check your pages today
For a timeline that usually deals in breaches and ransomware, polyfill.io is the entry most readers can personally verify: view-source any site you operate, search for polyfill.io, and if the tag exists — remove it. The campaign taught the web an uncomfortable inventory lesson at 475-million-visits scale: your page is your dependency graph, rendered; you own what it loads, whoever hosts it.
Detection and response playbook
The Polyfill.io hijack (June 2024) began with a domain acquisition: a Chinese company bought polyfill.io, redirected the popular script to collect user data and redirect traffic to scam and adult sites — and over 100,000 websites inherited the change automatically, because they had referenced the domain directly rather than bundling or vendoring the code.
- Treat third-party script domains as supply-chain dependencies. Every external script reference is a standing bet that the domain stays benevolent. Inventory them with the same discipline as npm packages: which domains serve code to your pages, who controls them, and what happens if ownership changes. The inventory is cheap; the unknowing is what cost six-figure site populations their integrity.
- Subresource integrity where possible, vendoring where practical. SRI hashes pin script content so silently swapped payloads fail to execute. For small utilities like polyfill, self-hosting removes the ownership-transfer risk entirely — the industry migration to Fastly and Cloudflare mirrors within days of the incident was exactly this lesson applied at scale.
- Detect third-party script changes in production. The hijack changed behavior for every site at once, but pages that monitor their own outbound script behavior — CSP violation reports, script-content change alerting, synthetic page testing — caught it within hours. Most sites relied on users and researchers instead. Monitoring your rendered page, not just your server, is the control.
- Plan domain-expiry risk for your own properties. The inverse lesson: your forgotten parked domains and legacy CDN references are someone else acquisition opportunity. Renew critical domains aggressively, and audit old properties for references that still load third-party code.
- Prepare the swap-out runbook. Sites that migrated in hours had one: a list of pages referencing the domain, a self-hosted or reputable replacement, and a deployment path. Sites without it were still serving hostile redirects a week later. Third-party dependency removal should be a rehearsed operation, not an archaeology project.
Where this sits in the broader pattern
Domain acquisition attacks are an established genre: the 2018 statistic-script hijacks, expired-domain takeovers of popular libraries and CDNs, and the DNS-redirect incidents of the prior decade. Polyfill.io was the largest by site count because the domain had been referenced directly by an enormous installed base — a usage pattern (script-tag includes) that predates every modern supply-chain lesson.
The modern echo is SRI and Trusted Types adoption across the web platform — controls that exist precisely because script sources can change hands. The adoption gap remains large: most sites still load third-party scripts without integrity attributes, accepting silent-content risk from domains they do not govern. Every jumbotron-scale incident like this one closes part of that gap, one postmortem at a time.
The consolidation with this series: the 3CX and XZ entries cover vendor and maintainer trust; this one covers domain trust. All three reduce to the same inventory question — what does your page or pipeline load, from whom, and who could become that whom tomorrow without your knowledge.
The bottom line. One domain changed hands, and 100,000 websites started serving someone else code within the hour. Inventory your third-party script domains, pin what you can with integrity attributes, vendor what is small enough to vendor, and rehearse the swap-out. Your page is only as trustworthy as every domain it still references — and ownership, unlike code, is always for sale.
Frequently Asked Questions
.aiopt-faq-block{border:1px solid var(–aio-border,#e2e8f0);border-radius:8px;overflow:hidden}
.aiopt-faq-item{border-bottom:1px solid var(–aio-border,#e2e8f0)}.aiopt-faq-item:last-child{border-bottom:none}
.aiopt-faq-question{width:100%;text-align:left;padding:16px 20px;background:none;border:none;cursor:pointer;display:flex;justify-content:space-between;align-items:center;font-size:16px;font-weight:600;color:#1e293b;gap:12px}
.aiopt-faq-question:hover{background:#f8fafc}
.aiopt-faq-icon{font-size:20px;transition:transform .2s;flex-shrink:0;color:#6366f1}
.aiopt-faq-open .aiopt-faq-icon{transform:rotate(45deg)}
.aiopt-faq-answer{max-height:0;overflow:hidden;transition:max-height .3s ease}
.aiopt-faq-open .aiopt-faq-answer{max-height:1000px}
.aiopt-faq-answer-inner{padding:0 20px 16px;color:#475569;line-height:1.7;font-size:15px}
{
“@context”: “https://schema.org”,
“@type”: “FAQPage”,
“mainEntity”: [
{
“@type”: “Question”,
“name”: “What was the Polyfill.io attack?”,
“acceptedAnswer”: {
“@type”: “Answer”,
“text”: “In June 2024, the polyfill.io domain u2014 sold to a new owner u2014 began serving malicious code that redirected users of 100,000-plus websites to scam and adult content, because sites referenced the script directly from the domain instead of bundling it.”
}
},
{
“@type”: “Question”,
“name”: “How did websites recover from the Polyfill.io hijack?”,
“acceptedAnswer”: {
“@type”: “Answer”,
“text”: “By replacing the reference u2014 self-hosting the code, removing it where unneeded, or switching to reputable mirrors such as Cloudflare and Fastly mirrors that began serving clean equivalents after the incident.”
}
},
{
“@type”: “Question”,
“name”: “How do you prevent third-party script hijacking?”,
“acceptedAnswer”: {
“@type”: “Answer”,
“text”: “Inventory all external script domains, vendor or self-host small utilities, apply subresource integrity (SRI) hashes where possible, and monitor rendered-page behavior so silent content changes trigger alerts.”
}
}
]
}
Related Reading
- What Studying 33 Historic Cyberattacks Taught Me About Defending Systems Today
- Passwordless in 2026: Why Passkeys Are Finally Killing the Password (and How Attackers Are Adapting)
- 2022–2024: Lapsus$, Change Healthcare & the XZ Backdoor
- Authoritative reference: CISA Known Exploited Vulnerabilities
- Codecov Breach: The CI Script That Leaked Build Secrets for Months
- Sisense Breach: CI Credentials, AWS Keys and a CISA Advisory
- MOVEit’s Ledger: 2,700 Orgs, 93 Million People
