Does anyone know what the malicious code was and what it did?
NPM stylus package contained malicious code and was removed from the registry
31–40 of 45 posts
Re: NPM stylus package contained malicious code and was removed from the registry
#32I 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 successf…
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 (pr…
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.
Re: NPM stylus package contained malicious code and was removed from the registry
#33I 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 successf…
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 (pr…
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
Re: NPM stylus package contained malicious code and was removed from the registry
#34Does anyone know what the malicious code was and what it did?
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.
Re: NPM stylus package contained malicious code and was removed from the registry
#35My workaround: Add this on your package.json on the end of file bevor last }: }, "overrides": { "stylus": "0.0.1-security" }
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.
Re: NPM stylus package contained malicious code and was removed from the registry
#36Earlier quoted context omitted.
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.
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
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.
Re: NPM stylus package contained malicious code and was removed from the registry
#37From 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
That could track but people in the GitHub issue ( https://github.com/stylus/stylus/issues/2938#issuecomment-31... ) have found that no "other" version of Stylus has been released.
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.
Re: NPM stylus package contained malicious code and was removed from the registry
#38I 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 successf…
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 (pr…
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.
Re: NPM stylus package contained malicious code and was removed from the registry
#39The package has now been restored/reinstated:
https://web.archive.org/web/20250723155529/https://www.npmjs...
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...
Re: NPM stylus package contained malicious code and was removed from the registry
#40Earlier quoted context omitted.
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 (pr…
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…
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.