PolyFill Vulnerability is WILD

A supply-chain takeover of the popular Polyfill JavaScript library has been linked to malware injection across more than 100,000 websites, with the compromise traced to a Chinese purchase of the polyfill.io domain and associated GitHub account access earlier this year. The incident matters because it shows how attackers can weaponize trust in widely embedded third-party code: site owners often load polyfill.io via a CDN without reviewing or controlling what ultimately runs in users’ browsers.

The compromise reportedly began after the domain and GitHub control changed hands in February. Instead of a slow, stealthy “cook,” the attack could be executed quickly by replacing the CDN artifact while keeping the open-source project looking normal. After the change, polyfill.io was found injecting malicious payloads into mobile visitors on any site that embeds the service. Complaints were reportedly removed or archived, and the original maintainer’s GitHub issue was deleted without notification, according to the account described.

One described malware behavior redirects mobile users to a sports betting site using a fake Google Analytics domain. The injected code is described as dynamically generated based on HTTP headers, with multiple attack vectors possible. It also includes safeguards to reduce detection: it activates only on specific mobile devices, only during certain hours (notably between 2 and 4), avoids execution for admin users, and delays or suppresses behavior when analytics services are detected—presumably to avoid skewing logs or triggering monitoring.

The fallout extended beyond browser redirects. A separate timeline mentions a denial-of-service attack against infrastructure, followed by a shift to a payment provider that temporarily suspended service while restoration efforts were underway. In parallel, Google began blocking Google Ads for e-commerce sites using polyfill.io, signaling that major platforms were already acting on the risk.

The incident also sparked a broader debate about open-source monetization and governance. Offers to buy maintainer accounts—sometimes for tens of thousands of dollars—were framed as a realistic temptation for exhausted maintainers, even when the buyer claims they will “keep it open source.” The transcript emphasizes that vetting the buyer matters, because the attacker doesn’t need to modify the public repository in a way users can easily notice; controlling the served CDN content can be enough.

As mitigation, the original polyfill author is cited as recommending not using polyfill at all because modern browsers reduce the need. Alternatives from Fastly and Cloudflare were mentioned for teams that still require compatibility features. The discussion also highlights defensive tooling such as CSP monitoring services to gain visibility into what third-party scripts and dependencies are actually loading, and it underscores that JavaScript supply-chain risk is amplified by the sheer volume of packages in typical node_modules environments. Overall, the case is presented as a concrete example of how a “trusted” dependency can become an attack surface when ownership and distribution control change hands.