• Posted by: Michal Zuberek
• February 12, 2025

The Polyfill.io Hijack: When the Script You Trust Becomes the Threat

On June 25, 2024, security researchers at Sansec published a finding that should have been impossible: cdn.polyfill.io, a domain used by over 100,000 websites to deliver JavaScript compatibility shims to older browsers, had been acquired by a Chinese CDN company and was actively serving malicious code to end users.

The domain had changed hands months earlier, but the full weaponization became apparent in late June. Visitors to affected websites — including major retail, news, and government sites — were silently redirected to scam pages and fake sweepstakes sites, but only if they matched a specific profile: mobile devices, not coming from known data center IP ranges, not running developer tools, and in a time window that avoided peak traffic hours. The payload was engineered to evade automated scanners.

How did 100,000 websites end up depending on a third-party domain?

Polyfill.js was a widely recommended solution for delivering browser compatibility fixes without bloating your own bundle. Thousands of tutorials, Stack Overflow answers, and even official documentation pointed to cdn.polyfill.io as the canonical way to include it. The original author, Andrew Betts, had long recommended against using the CDN and in favour of self-hosting, but the habit had already spread across the web. When the domain was sold, those 100,000 sites had no mechanism to know that the entity now responding to requests for that URL was not the one they had originally trusted.

Why existing defenses largely missed it

The script being served from cdn.polyfill.io was not static. The malicious payload was injected dynamically, and only under conditions designed to avoid detection: no bot traffic, no researchers, no monitoring systems. Classic approaches like subresource integrity (SRI) checks would have caught it if properly deployed, but most sites using the CDN had not configured SRI hashes — a common oversight when including third-party scripts. Vulnerability scanners testing for known CVEs found nothing, because there was no CVE. The software was simply doing what software does: calling a URL that someone else now controlled.

A supply chain attack on the browser side

Most supply chain security discussion focuses on the software development pipeline — build servers, package registries, update mechanisms. The Polyfill.io incident is a reminder that the same class of attack applies to runtime dependencies in browsers. When a page loads a script from a third-party CDN, it is extending trust to whoever controls that domain at that moment. Domain ownership changes. Companies get acquired or go under. Registration lapses. The script that was safe when you included it may not be safe a year later.

What detection looks like from the network side

In this case, the malicious behavior manifested as unexpected outbound redirects from browsers — HTTP 302 responses sending users to domains they had no reason to visit. From a network monitoring perspective, an organization that understands the normal communication profile of the applications and pages running in its environment is in a position to ask: why are users' browsers suddenly making requests to domains that were never part of our expected connection baseline? That question is answerable if you have the data. It is not answerable if you are only looking at what software is installed, not what it is doing.

CDN dependencies are a growing blind spot in supply chain security programs. If you would like to understand the full picture of what domains your software and web properties are communicating with — including dependencies you may not have catalogued — drop us a line.