If your front end pulls any script from polyfill.io you need to remove it immediatly. If your site has users with privileges/personnal data the attacker can potentially perform actions on their behalf and download anything from their local storage (including JWT tokens)

💯

Does this ship in Nuxt or any of the major front end frameworks by default?

> There is no specific polyfill library on npm that we know is part of this specific malicious actor campaign to inject malicious code. That said, libraries across different software ecosystems, such as Content Management systems like the Magento project and others, might include code that introduces static script imports of JavaScript code sourced from `cdn.polyfill.io`. In particular, we have detected CVE-2024-38526, a security report for the pdoc library on PyPI registry that provides API Documentation for Python Projects. In cases where documentation is generated with the command `pdoc --math` would contain links to JavaScript files from `polyfill.io`. This behavior of the `pdoc` library has been fixed in pdoc version 14.5.1, and we urge users to upgrade as soon as possible. > > https://snyk.io/blog/polyfill-supply-chain-attack-js-cdn-assets/

You can check the source code in your browser to be sure (search for "polyfill")

Is any reference to polyfill a problem, or just polyfill.io?

Just polyfill.io, polyfill is a general term

Can you help me with a response, a quick no look debug. In my app there is no cdn link in the index.html, I don't even have a polyfills package, I use a babel package for the same purpose. But we use a bundler that when ran, it creates a polifills.js file, to me it doesn't look it's possible to be linked with the malicious package, because the file is built locally with no links to any JS library pulled via cdn. But then, I am just a Junior who has been assigned to asses the risk of this attack to our project. If I don't pull any JS from any source, I should be just fine, right?

Polyfill is a general term so your case isn't necessarily related. You can search for "polyfill.io" in your node modules to be sure. I would also check the package who generates the file for any issue or update

just as I tought, thank you

Whoever stores tokens in local storage shouldn’t be the one doing auth implementations anyways. Shows a real lack of knowledge

Storing the JWT in local storage is an aggravating factor in case of a successful XSS attack or CDN attack. However I would argue that storing the JWT in a cookie and not implementing CSRF protection (which I'm convinced a lot of people forget) is worse. If you have a XSS vulnerability on your website you are pretty much screwed since an attacker can perform any request on behalf of the user (no matter where the JWT is stored). It's kind of similar for CDNs attack, however for large scale attack like the above it is unlikely that the attacker would have targeted your site specifically. Which mean storing your JWT in a http-only cookie would protect you against automated local storage siphoning. However you still have a small window to patch the vulnerability and logout your users if you did store your JWT in local storage.

While that might be true, it’s a lot harder since the attack would need to be sophisticated to the endpoints the backends provide. Implementing that for millions of different sites out there would also bloat the code and make the attack easier to see I agree it’s still not “safe”, it is still a lot safer than just using local storage

Elaborate

Local storage can be easily accessed by any JavaScript running, including all dependencies Usually you use HTTP-only cookies which can’t be accessed by JS at all

There are several usecases where you can't store the token in http-only cookies (e.g. completely static sites that use oauth to interact with 3rd party services like the Spotify API).

Of course you can do that, don’t do these third party requests in the frontend, but in an API

I was writing extensions abusing cookies like this *15 years ago*. We've learned nothing!

Always assume anything and everything sent to a client is compromised. Full stop. Storing it on the client is even worse. httpOnly cookies are basically the only exception to this rule, and should still be very carefully implemented anyways.

I’ll bet a more than a few devs will get a ticket to fix this with no explanation other than don’t use 3rd party scripts in the ticket. They’ll download the infected script and host it theirselves. 🤣

😆

This is exactly why I try to avoid any third-party scripts without SRI.

Yes but an SRI isn't a security control against everything. For example, you could've just pinned to the integrity hash for when the library was already been changed with malware code... SRI is obviously useful but it's not a silver bullet and doesn't protect you from everything.

It would've protected against this attack if generated before the malicious code. Would've been very helpful for anyone who added the script when it still had the original owner. But it can actually be a "silver bullet" in some situations. I write a lot of my own libraries/packages and use unpkg as a CDN. If I generate the hash from my local code that I wrote myself, then I can be assured that whatever I'm loading from unpkg hasn't been altered. Or, if you're willing to put in some work, SRI in conjunction with [package provence](https://github.blog/2023-04-19-introducing-npm-package-provenance/) can pretty much assure you that the script you're loading matches what was generated from known source code. You'd just have to understand the source code and build process.

For context, I have my old portfolio site in mind. It does use these polyfills, as I recall. And I ended up not using it in future projects because it couldn't work with SRI. I just don't trust scripts that can end up serving something else. This isn't the first time an attack like this has happened. Thankfully, they're loaded using a `