In June 2024, the widely-embedded cdn.polyfill.io script became the center of a major supply-chain attack, serving malicious JavaScript to visitors on a domain reportedly embedded on more than 100,000 websites, redirecting mobile users to betting and adult-content sites, after the domain quietly changed ownership months earlier. Security researchers at Sansec disclosed the compromise on June 25, 2024. There is no single CVE covering the incident itself — the closest identifier, CVE-2024-38526, is scoped narrowly to an unrelated documentation-tool vulnerability that also referenced polyfill.io, not the compromised CDN or the sites it affected. The root cause was not a hack of any single website — it was a trust failure in shared third-party infrastructure that thousands of sites had no direct control over. For Indian web teams, the incident is a concrete case study in why every third-party script loaded from someone else's domain is a standing liability, and why controls like Subresource Integrity, Content Security Policy, and self-hosting are not optional hardening steps anymore.
What Actually Happened in the Polyfill.io Supply-Chain Attack
Polyfill.io was a free, popular service that let older browsers understand modern JavaScript features, and cdn.polyfill.io was embedded directly on tens of thousands of sites, including large, well-known platforms. In February 2024, the domain and the associated GitHub account were sold to Funnull, a company researchers linked to Chinese ownership. Andrew Betts, the original creator of the polyfill service, had never controlled the domain himself, and as soon as the sale happened he publicly warned developers to remove the dependency immediately, months before any malicious activity was confirmed.
That warning turned out to be prescient. By late June 2024, Sansec researchers found that the script served from cdn.polyfill.io had been modified to inject malicious code under specific conditions, primarily targeting mobile visitors while evading detection tools, analytics bots, and admin sessions.
How the Compromise Spread
The malicious script was engineered to be hard to catch in a manual check: it activated only for certain visitor conditions, avoided triggering when it detected admin or analytics traffic, and used time-delayed execution so a quick spot-check of the live page often showed nothing unusual. Sites had no way to know their own pages were compromised unless they were specifically monitoring what the third-party script was actually delivering at any given moment.
The Response and What It Revealed
Once Sansec's research went public, the response moved fast, but the fact that a response was needed at all is the real story. Google began blocking ads for e-commerce sites still loading the compromised domain. Cloudflare and Fastly, two major CDN providers, offered free, safe mirrors so affected sites could keep functionality without pointing at the poisoned domain. Namecheap, the registrar, put polyfill.io on hold, which effectively neutralised the live threat. Despite that fast-moving mitigation, researchers continued to find large numbers of hosts still referencing the malicious domain days after the takedown began — remediation on the registrar side does not automatically mean every affected site removed the dependency from its own code.
One detail specific to this incident matters for how teams think about Subresource Integrity as a fix: because the polyfill.io service dynamically generated different JavaScript depending on the requesting browser, a single static SRI hash could not simply be pinned against the CDN response the way it can for a normal, unchanging library file. That does not make SRI useless — it makes "any script that returns dynamic, per-request content from a third-party domain" a category of risk that deserves extra scrutiny, on top of SRI for everything that is genuinely static.
Why This Matters for Indian Web Teams
Indian e-commerce platforms, SaaS products, fintech front-ends, and government-adjacent portals all rely on the same pattern the rest of the world does: pulling in analytics tags, chat widgets, payment SDKs, A/B testing tools, and compatibility shims from third-party CDNs, often without a formal review process for what happens if that vendor's domain is compromised, sold, or repurposed. The Polyfill.io incident is a preview of what any of those dependencies could do if the same failure mode repeats.
| Control | What It Addresses | Practical First Step |
|---|---|---|
| Subresource Integrity (SRI) | Tampered content served from a trusted-looking CDN URL | Add integrity and crossorigin attributes to every static third-party <script> and <link> tag |
| Content Security Policy (CSP) | Scripts loading from domains never explicitly approved | Define a script-src allowlist; block inline and unapproved third-party script execution by default |
| Self-hosting critical dependencies | Loss of control over a vendor's domain, ownership, or infrastructure | Bundle stable, rarely-changing libraries into your own build instead of loading them live from someone else's CDN |
| Vendor and domain-ownership monitoring | Silent ownership or registrar changes on a script you depend on | Track WHOIS/registrar changes and vendor security advisories for every third-party script domain in production |
| Dependency inventory and review cadence | "We forgot we still load that" — dead dependencies nobody owns | Maintain a living list of every external script embedded in production, with an owner and a periodic re-justification |
| Incident response for compromised vendors | Slow reaction when a third-party dependency turns malicious | Pre-write a runbook for "remove or swap a compromised third-party script" so it is a same-day action, not a scramble |
Why Self-Hosting Is Often the Simplest Fix
For libraries that rarely change — polyfills, older jQuery-era dependencies, small utility scripts — the practical lesson from this incident is that self-hosting removes an entire class of risk outright. If the file lives in your own build and deploys through your own pipeline, a third party's domain sale, registrar dispute, or CDN compromise simply cannot reach your visitors. Self-hosting does mean owning the responsibility to patch and update that dependency yourself, but for stable, low-churn libraries that trade-off is usually worth it, especially for anything running on payment, login, or checkout pages.
Know your vulnerabilities before attackers do
Run a free VAPT scan — takes 5 minutes, no signup required.
Book Your Free ScanWhere Third-Party Script Risk Concentrates
The incident's own reporting makes clear which parts of the risk surface mattered most: the malicious behaviour was conditional, targeted mostly at mobile visitors, and designed to stay invisible to the people most likely to notice it.
This targeting logic is exactly why static "does the page look fine to me" checks failed across so many affected sites for weeks. Detection depended on researchers actively probing the live script's behaviour under different conditions, not on a single visual review.
Building the Practical Response
Indian teams do not need to eliminate every third-party script to close this gap — most production sites genuinely need analytics, payment gateways, and compatibility libraries from outside vendors. What the Polyfill.io incident demonstrates is that "we embedded it once and it has worked fine for years" is not a security posture. Every externally-loaded script on a production page is effectively a standing grant of code-execution trust to whoever controls that domain today, which may not be who controlled it when the script was first added.
At Bachao.AI, automated VAPT assessments are built to surface exactly this kind of overlooked exposure — third-party scripts, outdated dependencies, and misconfigured CSP or SRI controls that most manual reviews miss because the page "looks fine" on the surface. Dhisattva AI Pvt Ltd built the platform around the reality that most real-world breaches trace back to something already known and simply unaddressed, not something novel. If your team cannot currently list every third-party script domain running on your production pages with an owner attached, a free VAPT scan is a fast way to find that gap. For organisations where a compromised script could touch personal data covered under India's data protection law, our DPDP compliance guide covers the broader regulatory exposure, and the Bachao.AI blog has more real-world incident breakdowns like this one.