Polyfill.io Supply Chain Attack: Malicious JavaScript Injection Puts Over 100k Websites At Risk

Polyfill.io helps web developers achieve cross-browser compatibility by automatically managing necessary polyfills. By adding a script tag to their HTML, developers can ensure that features like JavaScript functions, HTML5 elements, and various APIs work across different browsers. Originally developed by Andrew Betts, Polyfill.io injects JavaScript polyfill libraries based on the user agent or other characteristics, streamlining code maintenance.

A recent supply chain attack compromised over 100,000 websites through the popular Polyfill JavaScript library. Earlier this year, a Chinese company acquired the Polyfill.io domain and began distributing malicious JavaScript code across CDN libraries instead of legitimate libraries.

This form of a supply chain attack allowed arbitrary malicious activity in the context of the victim's browser: redirecting users to phishing sites, stealing sensitive information, or even further propagating malware. The attack is similar to stored Cross-Site Scripting (XSS) and does not require any actions from the victim other than visiting a web page.

How did Wallarm’s WAAP Platform detect compromised applications & web pages?

The polyfill code is dynamically generated using HTTP headers, which introduces several possible attack vectors. The first publicized instance of this attack in the wild was through a fake Google Analytics domain - http://www.google-anaiytics.com (misspelled “analytics” as “anaiytics”). 

Wallarm's WAAP platform detected compromised applications and the corresponding web pages with static imports of JavaScript code from the polyfill.io domain and other malicious domains involved in this campaign.

Table 1: Identified Malicious Domains

1. kuurza[.]com 2. googie-anaiytics[.]com 3. bootcss[.]com 4. macoms[.]lanewcrbpc[.]com 5. polyfill[.]io 6. bootcdn[.]net 7. staticfile[.]net 8. unionadjs[.]com 9. xhsbpza[.]com)

How to Stay Protected against Supply Chain Attacks?

Since the browsers that do use/support polyfill have become obsolete to an extent, it’s likely that you aren’t affected. Even the original author Andrew Betts issued a statement in early February this year announcing that he no longer possesses any domain authority over the tool and urged users to stop using Polyfill.io. 

Thus, we recommend you to verify whether the library is used in your project and consider entirely removing it.

Ensure that there are no references to malicious domains in the source code - kuurza[.]com, googie-anaiytics[.]com, bootcss[.]com, macoms[.]lanewcrbpc[.]com, polyfill[.]io, bootcdn[.]net, staticfile[.]net, unionadjs[.]com, xhsbpza[.]com).

If you are using the Wallarm WAAP, check the vulnerabilities page for the vulnerability titled - Malicious JavaScript injection via supply chain attack (polyfill.io) - as demonstrated in the figure below. 

However, if you are using polyfill.io and also have Wallarm’s WAAP platform in place, check the vulnerabilities page for the vulnerability titled - Malicious JavaScript injection via supply chain attack (polyfill.io) - as demonstrated in the figure below:

If any of the vulnerabilities are found/detected, Wallarm suggests that you:

1. Consider removing the Polyfill library entirely from the application’s dependencies.
2. Ensure that there are no references to malicious domains in the source code (check examples of identified domains mentioned in Table 1 above)
3. Investigate potential incidents of attacks on your application users as the system remained vulnerable for a long period.

*Note: If the vulnerability was not found, we still recommend analyzing the source code of all projects, especially those not protected with the Wallarm WAAP platform.