Polyfill.io JavaScript supply chain attack impacts over 100K sites

[spmedia]

https://www.bleepingcomputer.com/news/security/polyfillio-javascript-supply-chain-attack-impacts-over-100k-sites/

https://sansec.io/research/polyfill-supply-chain-attack

[Daniel15]

A good reminder to be extremely careful loading scripts from a third-party CDN unless you trust the owner 100% (and even then, ownership can change over time, as shown here). You're essentially giving the maintainer of that CDN full control of your site. Ideally, never do it, as it's just begging for a supply chain attack. If you need polyfills for older browsers, host the JS yourself. :)

If you really must load scripts from a third-party, use subresource integrity so that the browser refuses to load it if the hash changes. A broken site is better than a hacked one.

[gwillem]

SRI doesn't work here, since once of this project's features is to dynamically produce a polyfill subset based on user agent. So local hosting it is!

[Daniel15]

Hosting locally is definitely a better option in that case. How many unique combinations do you actually encounter in prod though?

Often it's sufficient to just have two variants of your JS bundles, for example "very old browsers" (all the polyfills required by the oldest browser versions your product supports) and "somewhat new browsers" (just polyfills required for browsers released in the last year or so), which you can do with browserslist and caniuse-lite data.

[shuuji3]

Please also refer to https://github.com/polyfillpolyfill/polyfill-service/issues/2873 for additonal information

[polyfillcust]

Someone has maliciously defamed us. We have no supply chain risks because all content is statically cached. Any involvement of third parties could introduce potential risks to your website, but no one would do this as it would be jeopardize our own reputation.

We have already outlined our future commercialization plan:

1) Polyfill JS CDN (completed) 2) Polyfill Analytics (50% completed) 3) Polyfill Cloud CDN+DNS (40% completed) 4) Polyfill Error Monitoring (50% completed) 5) Polyfill Globalping (80% completed)

Progress will be updated on Twitter.

[eligrey]

We have no supply chain risks because all content is statically cached

Statically cached where? On a webserver that can provide dynamic responses?

[Daniel15]

We have no supply chain risks

I don't think you understand... You are the supply chain risk. There's no way to tell who @polyfillpolyfill or @polyfillcust are, and a supply chain attack has already taken place. There was clearly some sort of malicious code injected into polyfill.io, to the point where Google started blocking ads for sites that use it. Either you directly inserted the malicious code, or someone else hacked in to your infrastructure and inserted it. Either way, it was a very obvious supply chain attack.

You need to try and win back people's trust, and saying "we have no risks" when there was clear evidence of malicious code being served from your infra is not going to help :)

I use AdGuard Home on my home server for DNS, mainly to block malicious sites, and it now blocks access to polyfill.io as a dangerous website.

Edit: Also, your new site https://polyfill.com/ is such an obvious copy of https://www.jsdelivr.com/, to the point where the logos listed under "polyfill is used by millions of websites globally" are identical to the logos under "jsDelivr is used by millions of websites globally". Not helping build trust.

[lordofpipes]

For anyone struggling to keep up, there are three new domains to add to your uBlock or DNS filters:

• polyfill.com
• polyfill.ai
• polyfill.site (still active)