Also if all the versions are affected this malware is in stylus since 2010. Honestly, it sounds improbable to me that a malware exists unnoticed in open source software for 15 years. However, even if improbable it's better to play safe and just override the installation of stylus ( especially if you are not using it ) with an empty package until more information is released

The package was pulled at: 2025-07-23T03:03:01.239Z

And the GHSA advisory: 2025-07-23T03:03:56Z

So the GHSA was released after the pull (by a minute).

Once again proof that advisories are full of etc.

Stylus has been around for 15 (FIFTEEN) years. Obviously the "vulnerability" is a lie.

Npm is known to cause huge losses of money for developers and companies around the world when they pull things like this, blindly applying advisories.

It may simply be Github and NPM going nuclear and just flagging everything just in case

Amateur hour all around in that thread. I can't believe that people are actually, unironically recommending that you use a mutable git tag reference in package.json when they should be using a tamper-proof git SHA instead.

It gets even better, Dependabot will spam you severities of it’s own that don’t appear in audit.

So you probably need to carefully audit the changes from two data sources and the security ticket ends up being 2+ merge requests.

No the biggest churn involved is now I’m another engineer that prefers to stay away from using, developing on, and recommending javascript platforms.

To your point I think you will find most companies stop at the upgrade high sev packages step and do not have any requirements or churn related to checking for fallout from sevs.

I think this would be a fair assessment, if the security advisory would be true.

Since it's most probably false, the implications you refer to remain hypothetical, while the cost of cleaning up after npm's decision are measured in real M$s. And I think that's the real issue here.

I am not saying that we should give up on security altogether, but now there is so much toil attached to managing security, compliance and such aspects of the development lifecycle, that at some point managing all these aspects will outweigh all productivity a dev can bring to the project.

It's admittedly a hyperbole, but at that point the whole development procedure would simply become a pointless exercise without any benefit to anyone.

In my case, stylus is a transient dependency of a transient dependency of a transient dependency... Vite has had stylus as an OPTIONAL peer dependency for a very long time now, and stylus itself has existed for MANY years.

What NPM did here is eradicate every single version of stylus ever published, so the breakage for the large majority of people here is that NPM will now try to fetch a non-existent package, which will cause CI and other scripts that rely on `npm ci` or `npm i` to fail.

It's one thing to get a big scary warning saying "Hey, stylus has a vulnerability, here's an overview of the issue..." and then pushing out the overwritten version as its own standalone version that people can migrate to. Instead, NPM silently overtook a package and overrode it completely. Running `npm audit` in a project affected by this, I see 0 mention of stylus in it, there is ZERO indication anywhere that something about this package is wrong other than the fact that the package basically doesn't exist in the registry anymore. And in my testing so far, things like `package.json` `overrides` fields does not work [1].

So I wouldn't say this is your typical vulnerability situation. They pulled packages with 0 warning or notice to anyone, and their own security audit tooling gives you nothing to go by, and there seems to be basically nothing you can do to fix this, depending on how exactly your project is setup. We're not even sure there is an actual attack or vulnerability, because they don't link to any details literally anywhere! Just take a look at the NPM page [2], there are ZERO details here! And even weirder (could be that NPM just doesn't count downloads this early into a change's lifecycle), the downloads for the version they override is sitting at 0, to me indicating that nobody has been able to even download this, which I can confirm at least anecdotally from me trying to fix this issue myself.

[1] https://github.com/npm/cli/issues/4232 [2] https://www.npmjs.com/package/stylus

This article is four years old but still relevant: https://overreacted.io/npm-audit-broken-by-design/

The vast majority of "compromised packages" are just dev dependencies that have a slow regexp.

The sensible action would be to remove only the malicious packages and suspend that account.