Polyfill supply chain attack - bootcdn and staticfile
If the authors do not update the script, could you add a warning to the users that "The listed script contains malware CDNs. Do you still want to install" when the install button is clicked?
I think this would not be just a one time case. China's network is so dirty.
This will happen again and again in the future.
I don't think it's the case that every script on those CDNs is infected; it sounds like just polyfill was affected.
If that's not true, then I think the thing to do would be remove the scripts that use those CDNs entirely from Greasy Fork until the authors update them.
I think this would not be just a one time case. China's network is so dirty.
This will happen again and again in the future.
Unfortunately, many "Western" CDNs are either blocked or very slow in China, so it's not as simple as getting everyone to use the ones we're familiar with.
So I'm not sure what the current status of these domains is. Based on this overview, it sounds like some creds were leaked, which is how polyfill on these CDNs were affected. I'm not sure if the CDNs themselves did anything wrong, or did wrong by not doing anything. For what it's worth, they're still on uBlock Origin's malware list.
@JasonBarnabe
Many jsdelivr URLs are allowed, but why main patch versions aren't?
https://cdn.jsdelivr.net/npm/marked/lib/marked.umd.min.js
Because this URL doesn't have a version, the author can modify the code and add something bad. When the URL has a version (or a commit hash), it will never change.
https://sansec.io/research/polyfill-supply-chain-attack
Of the domains listed as affected, Greasy Fork's allowed CDN list included bootcdn.net, bootcss.com, staticfile.net, and staticfile.org. These have now been removed as allowed CDNs. If you are using these CDNs in your scripts, I suggest you modify your script immediately.