In a significant supply chain attack, over 100,000 websites using Polyfill[.]io, a popular JavaScript CDN service, were compromised.
Earlier this year, a Chinese company called Funnull took over the ownership of the polyfill[.]io domain. What followed was the CDN delivering malicious JavaScript code which was automatically deployed on websites that embedded scripts from cdn.polyfill[.]io. The code would redirect mobile visitors of a website to scam sites.
As a result of the fall out from this attack, Google has informed advertisers about possible impacts on their landing pages that might be contaminated with malicious scripts, whereas safe mirrors of Polyfill have been setup by Fastly and Cloudflare.
We break down what this incident means for npm developers and packages relying on the Polyfill CDN.
Understanding the Polyfill.io compromise
In February 2024, Andrew Betts, the original developer of the polyfill service warned users against using polyfill[.]io as a precaution — months before there was any indication, knowledge of, foul play involved.
"If your website uses http://polyfill.io, remove it IMMEDIATELY," wrote Betts. "I created the polyfill service project but I have never owned the domain name and I have had no influence over its sale."
"No website today requires any of the polyfills."
Sansec researchers discovered this week that ever since the domain changed hands, it has been "injecting malware on mobile devices via any site that embeds cdn.polyfill[.]io." and raised the alarm bells for everyone.
Although technology leaders like Cloudflare, Fastly, and Google have all stepped in to thwart the threat, it's not yet over. Google started alerting advertisers that, as a result of this attack, their landing pages contain the malicious code that could send visitors away from the intended site without the website owner knowing about it. Cloudflare and Fastly setup safer mirrors of the Polyfill service.
Given how widespread this is, we don't expect to understand the real impact of this supply chain attack for many weeks. Attacks like these, however, can be quite devastating. For example, it can be used to plant backdoors that could allow the threat actor(s) to remotely access an infected device — similar to what we saw with the compromise of IRS-authorised tax filing service eFile.com that was caught delivering malicious JavaScript.
Cryptocurrency theft, mining, and credit card skimming are key characteristics of successful Magecart-style attacks that often involve delivering malicious JavaScript via otherwise legitimate websites or CDNs that have been quietly compromised.
npm libraries that still use unsafe Polyfill.io CDN
As Mozilla explains it, "A polyfill is a piece of code (usually JavaScript on the Web) used to provide modern functionality on older browsers that do not natively support it."
Several npm packages designed to offer the polyfill functionality continue to embed code from the 'cdn.polyfill[.]io' service. For example, looking at the 'create-polyfill-service-url' package, we can see it uses the service as the default provider for polyfill:
Similar behavior is exhibited by other libraries, like 'dynamic-polyfill' that fetch code from the CDN:
Although the polyfill[.]io domain is, at the time of writing, redirecting to Cloudflare's mirror, we can not conclude that the threat from this domain is over yet, given that the DNS entries could be manipulated in the future to resume the attack.
Out of caution, the Sonatype Security Research team has and continues to categorize several npm packages under sonatype-2024-2304 as 'Potentially Unwanted Application(s)' or PUAs.
Users of Sonatype Lifecycle and Sonatype Repository Firewall will notice that open source packages that rely on the risky polyfill[.]io domain will gradually start flagging a security alert.
We understand it may not be practical to identify and flag every single library from every registry that uses or has in the past used the 'cdn.polyfill[.]io service. Our teams are actively reviewing the ongoing incident and will discretionarily modify our package blocklists while bearing in mind that some applications could have a legitimate need for these packages and that their software builds should continue to run smoothly.
Mitigation and response
In response to the Polyfill.io compromise, security experts recommend several measures to mitigate the risks associated with JavaScript supply chain attacks:
- Regular Audits and Monitoring: Conduct regular security audits and monitor third-party services for unusual activity. Early detection can help prevent widespread damage.
- Content Security Policy (CSP): Implementing a robust CSP can help restrict the sources from which scripts can be loaded, reducing the risk of malicious code execution.
- Subresource Integrity (SRI): Use SRI to ensure that third-party scripts have not been tampered with. This security feature allows browsers to verify that a fetched resource matches the expected hash.
- Dependency Management: Maintain strict control over dependencies (a feature of Sonatype Nexus Repository) and avoid unnecessary third-party scripts. Regularly update and review dependencies to ensure they are secure.
Future of supply chain security
The Polyfill.io attack is a stark reminder of the evolving threat landscape in web development and is a wake up call. As the use of third-party services continues to grow, so does the need for robust supply chain security practices. It highlights the urgent need for improved supply chain security measures and greater vigilance in monitoring third-party services Developers and organizations must prioritize security at every stage of the development process to mitigate risks associated with third-party dependencies.
Investing in advanced threat detection systems, educating developers on secure coding practices, and fostering a culture of security awareness are crucial steps in enhancing supply chain security. Additionally, collaboration between security researchers, developers, and service providers is essential to identify and address vulnerabilities promptly.
