This advisory has been withdrawn because the stylus npm package is not malware.
It took a while, but we now have some clarity.
righthand · 12h ago
I have to say NPM packaging is terrible. I probably spend 1 month of the year fiddling with upgrading packages due to security issues. That is just the amount of time I spend on my repos alone. All of this extra effort to avoid code signing and making package owners accountable.
It seems like every week there is a new security high sev ticket to fix some webpack dependency.
Not to mention that even if you do successfully run “npm audit fix” (—force), Npm may not update to the correct new version and will often downgrade packages many many many versions.
The error messages that Npm spits out have always frightened junior devs too.
I can’t wait for that whole ecosystem to be replaced.
sensanaty · 12h ago
The crazy thing is that `npm audit` doesn't even list `stylus` here, at least not in my repos. Despite them literally overtaking the damn package on the registry for a *security issue*.
righthand · 11h ago
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.
vdupras · 11h ago
I have a question. I'm curious.
I see two comments here on this subject, complaining about the churn of dealing with security advisories. Sure, it's churn.
... but isn't this problem dwarfed by the implications of having used a compromised package? Presumably, if the project you work on has a compromised dependency, it means you've ran it on your development machine. Presumably, you might have a couple of secrets (private keys, AWS credentials and other whatnots) lying around, which might have leaked to a malicious actor.
Wouldn't you need to review all the development, staging and production machines for all your projects and rotate secrets everywhere?
Wouldn't it be, by far, the biggest churn involved, so much that mentioning "npm audit" difficulties not worth mentioning at all, because of the ridiculous comparison in effort magnitude?
sensanaty · 10h ago
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.
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.
vdupras · 7h ago
So I understand that in NPM world, spurious security advisories are common and that the tooling will constantly have you run "fix" commands without real reasons? That's bad and it would explain this lax security culture oozing from it.
So the damage is already done, and real security problems will never be properly addressed. One must come to the conclusion that NPM has to be avoided at all cost if security is a concern at all. Additionally, one must make sure that when onboarding a developer coming from the NPM world into a sane project, they have to be properly de-conditioned with regards to security advisories.
righthand · 11h ago
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.
vdupras · 10h ago
That's what I suspect as well, but this means that we can assume that there's a giganormous amount of development machines being compromised around the world. If you're a gig worker, you might be exposing your other customers, including those with okay security practices.
It seems crazy to me that there's this ostrich culture about security. I'm guessing the vibecoding fashion doesn't help. Supply chain attacks can only grow exponential from there, flee for your lives.
The vast majority of "compromised packages" are just dev dependencies that have a slow regexp.
sensanaty · 13h ago
Man I thought I was going crazy.
My staging build was failing and I saw that stylus was the culprit. Running `npm why stylus`, `npm ls --all stylus`, and other variants of these two commands consistently returned nothing, but I can see it in my lockfile if I run `grep -R stylus package-lock.json`.
Even running `npm audit | grep stylus` returned nothing! Which I think is pretty crazy considering the package itself has been overwritten by NPM to include a 0 context scary "Security holding package" thing. Surely this sort of thing should show up in the `audit` results?
I'm still unsure if it's a mistake on NPM side or if stylus and the authors are compromised
clncy · 15h ago
It's so hard to triage this when no justification has been provided for the advisory. Was the GHSA released in response to npm pulling the package, or vice versa?
Many suggestions for workarounds, but if the GHSA is indeed accurate (all versions affected) then that seems unwise.
wut42 · 15h ago
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).
maury91 · 15h ago
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
clncy · 15h ago
I agree that it seems very improbable. The only possible malicious scenario I can imagine is that the Github repo is clean, but npm creds have been compromised.
From how is unfolding the most probable outcome is that one of the maintainer is compromised ( Ponya ), all of the packages he contributed to have been marked
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.
maury91 · 14h ago
It may simply be Github and NPM going nuclear and just flagging everything just in case
tetha · 11h ago
Since the Github issue is turning into an unusable mess and I am currently experiencing emotions I don't have to unleash here...
There is an interesting comment by one of the older maintainers of stylus, Panya [1]. Taking this at face value, they claim to have published some malicious packages for research purposes about dependency confusion [2] (their link). This also fits with the comments of a few people claiming to be security researchers, [3] and [4], which at least say the same and point to three malicious packages published by Panya.
Based off of that, my own personal interpretation and simplest thesis is that Panya released some packages with questionable code. This triggered some security mechanism in npm and that system yanked packages they were a contributor of [5], because the account looked compromised or otherwise malicious. And then pipelines went red.
If this was an actual malicious act, or curiosity about security and security responses getting a fairly nuclear security response, I don't know. You need to apply your own security reasoning to this -- if you even want to trust this comment :)
I just wanted to collect the interesting comments in a place, because that ticket is getting impossible to navigate.
Could be! Other comments (~~can't find them now as the issue got full of useless comments~~ e.g. https://github.com/stylus/stylus/issues/2938#issuecomment-31...) also noted that the GHSA bot have nuked a lot of other npm packages since days or weeks in the same fashion, so it could also be an AI scanner going full full nuclear.
maury91 · 14h ago
Agree it would be nice if people would stop posting "help! how can I fix this?" and "I fixed it by doing X", they were valid comments at the beginning, but now more than half of the comments are just these two
delfinom · 9h ago
Well, how else do people who never read and understood the tools they are using get help? Coding boot camps only teach so much lol.
yoavfr · 18h ago
A quick workaround if you're affected by a deep dependency and don't rely on stylus directly - add `"overrides": {"stylus": "0.0.1-security"}` to your package.json
dmitryeu · 17h ago
Work around the issue by installing directly from GitHub using package.json overrides:
```
"overrides": {
"stylus": "github:stylus/stylus#0.64.0"
}
```
The title is wrong. There's no proof of compromise. There are no releases of the package since October. Apparently one of the long-time maintainers has pushed other compromised packages, so npm just nuked all the packages he had access to, whether they were compromised or not.
kaelwd · 15h ago
Removing the entire package is pretty unusual, normally it's only specific compromised versions.
maury91 · 15h ago
The advisory says all the versions are affected ">= 0"
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.
kontercola · 12h ago
My workaround:
Add this on your package.json on the end of file bevor last }:
},
"overrides": {
"stylus": "0.0.1-security"
}
dale_lakes · 10h ago
Random internet person: Do not do this ^ . Wait for the package to be restored by npmjs, or use the workaround in the pinned issue on the stylus repo.
okcdz · 10h ago
It seems this doesn't work. The package is empty, it can't function. It makes the world stop, which is terrible!
borplk · 10h ago
Does anyone know what the malicious code was and what it did?
dale_lakes · 10h ago
The malicious code had nothing to do with the stylus package. One of the maintainers of stylus published malicious code in another package, and GitHub / npmjs response was to nuke ALL packages that he was a maintainer of, including stylus.
finchisko · 12h ago
Colleague of mine. Pointed out that github advisory had many new malware reports in last few days. All looking same.
Looks suspicious if you ask me. Maybe somebody hacked the github advisory db?
It seems like every week there is a new security high sev ticket to fix some webpack dependency.
Not to mention that even if you do successfully run “npm audit fix” (—force), Npm may not update to the correct new version and will often downgrade packages many many many versions.
The error messages that Npm spits out have always frightened junior devs too.
I can’t wait for that whole ecosystem to be replaced.
So you probably need to carefully audit the changes from two data sources and the security ticket ends up being 2+ merge requests.
I see two comments here on this subject, complaining about the churn of dealing with security advisories. Sure, it's churn.
... but isn't this problem dwarfed by the implications of having used a compromised package? Presumably, if the project you work on has a compromised dependency, it means you've ran it on your development machine. Presumably, you might have a couple of secrets (private keys, AWS credentials and other whatnots) lying around, which might have leaked to a malicious actor.
Wouldn't you need to review all the development, staging and production machines for all your projects and rotate secrets everywhere?
Wouldn't it be, by far, the biggest churn involved, so much that mentioning "npm audit" difficulties not worth mentioning at all, because of the ridiculous comparison in effort magnitude?
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
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.
So the damage is already done, and real security problems will never be properly addressed. One must come to the conclusion that NPM has to be avoided at all cost if security is a concern at all. Additionally, one must make sure that when onboarding a developer coming from the NPM world into a sane project, they have to be properly de-conditioned with regards to security advisories.
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.
It seems crazy to me that there's this ostrich culture about security. I'm guessing the vibecoding fashion doesn't help. Supply chain attacks can only grow exponential from there, flee for your lives.
The vast majority of "compromised packages" are just dev dependencies that have a slow regexp.
My staging build was failing and I saw that stylus was the culprit. Running `npm why stylus`, `npm ls --all stylus`, and other variants of these two commands consistently returned nothing, but I can see it in my lockfile if I run `grep -R stylus package-lock.json`.
Even running `npm audit | grep stylus` returned nothing! Which I think is pretty crazy considering the package itself has been overwritten by NPM to include a 0 context scary "Security holding package" thing. Surely this sort of thing should show up in the `audit` results?
No comments yet
https://github.com/advisories/GHSA-fh4q-jc76-r59p
I'm still unsure if it's a mistake on NPM side or if stylus and the authors are compromised
Many suggestions for workarounds, but if the GHSA is indeed accurate (all versions affected) then that seems unwise.
And the GHSA advisory: 2025-07-23T03:03:56Z
So the GHSA was released after the pull (by a minute).
This has been reflected in a recent edit and comments here: https://github.com/stylus/stylus/issues/2938
No updates to the security advisory at this time: https://web.archive.org/web/20250723155624/https://github.co...
There is an interesting comment by one of the older maintainers of stylus, Panya [1]. Taking this at face value, they claim to have published some malicious packages for research purposes about dependency confusion [2] (their link). This also fits with the comments of a few people claiming to be security researchers, [3] and [4], which at least say the same and point to three malicious packages published by Panya.
Based off of that, my own personal interpretation and simplest thesis is that Panya released some packages with questionable code. This triggered some security mechanism in npm and that system yanked packages they were a contributor of [5], because the account looked compromised or otherwise malicious. And then pipelines went red.
If this was an actual malicious act, or curiosity about security and security responses getting a fairly nuclear security response, I don't know. You need to apply your own security reasoning to this -- if you even want to trust this comment :)
I just wanted to collect the interesting comments in a place, because that ticket is getting impossible to navigate.
1: https://github.com/stylus/stylus/issues/2938#issuecomment-31...
2: https://medium.com/@alex.birsan/dependency-confusion-4a5d60f...
3: https://github.com/stylus/stylus/issues/2938#issuecomment-31...
4: https://github.com/stylus/stylus/issues/2938#issuecomment-31...
5: https://github.com/stylus/stylus/issues/2938#issuecomment-31...
5, also: https://github.com/stylus/stylus/issues/2938#issuecomment-31... (thanks to the sibling comment, I couldn't find that anymore)
Maintainer @iChenLei reports they are negotiating with npm officials to restore access: https://github.com/stylus/stylus/issues/2938
https://github.com/advisories/GHSA-fh4q-jc76-r59p
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.
Add this on your package.json on the end of file bevor last }:
Looks suspicious if you ask me. Maybe somebody hacked the github advisory db?
https://github.com/advisories?page=1&query=type%3Amalware