Shai-Hulud Returns: Over 300 NPM Packages Infected

https://helixguard.ai/blog/malicious-sha1hulud-2025-11-24

105•mrdosija•41m ago

Comments

vintagedave•26m ago

Serious question: should someone develop new technologies using Node any more?

A short time ago, I started a frontend in Astro for a SaaS startup I'm building with a friend. Astro is beautiful. But it's build on Node. And every time I update the versions of my dependencies I feel terrified I am bringing something into my server I don't know about.

I just keep reading more and more stories about dangerous npm packages, and get this sense that npm has absolutely no safety at all.

sublinear•23m ago

The list of affected packages are all under namespaces pretty much nobody uses or are subdependencies of junk libraries nobody should be using if they're serious about writing production code.

I'm getting tired of the anti-Node.js narrative that keeps going around as if other package repos aren't the same or worse.

pxc•20m ago

The only way a worm like this spreads is usage of the affected packages. The proliferation itself is clear evidence of use.

DJBunnies•17m ago

Ok, I'll bite; which package repos are "the same or worse" than those of nodejs?

sph•22m ago

It's not "node" or "Javascript" the problem, it's this convenient packaging model.

This is gonna ruffle some feathers, but it's only a matter of time until it'll happen on the Rust ecosystem which loves to depend on a billion subpackages, and it won't be fault of the language itself.

The more I think about it, the more I believe that C, C++ or Odin's decision not to have a convenient package manager that fosters a cambrian explosion of dependencies to be a very good idea security-wise. Ambivalent about Go: they have a semblance of packaging system, but nothing so reckless like allowing third-party tarballs uploaded in the cloud to effectively run code on the dev's machine.

fouronnes3•17m ago

Surely in this case the problem is a technical one, and with more work towards a better security model and practices we can have the best of both worlds, no?

dotancohen•16m ago

Historically, arguments of "it's popular so that's why it's attacked" have not held up. Notable among them was addressing Windows desktop security vulnerabilities. As Linux and Mac machines became more popular, not to mention Android, the security vulnerabilities in those burgeoning platforms never manifested to the extent that they were in Windows. Nor does cargo or pip seem to be infected with these problems to the extent that npm is.

vintagedave•16m ago

I believe you, in that package management with dependencies without security mitigation is both convenient and dangerous. And I certainly agree this could happen for other package managers as well.

My real worry, for myself re the parent comment is, it's just a web frontend. There are a million other ways to develop it. Sober, cold risk assessment is: should we, or should we have, and should anyone else, choose something npm-based for new development?

Ie not a question about potential risk for other technologies, but a question about risk and impact for this specific technology.

progbits•9m ago

Agreed with the first half, but giving up on convenient packaging isn't the answer.

Things like cargo-vet help as does enforcing non-token auth, scanning and required cooldown periods.

tjpnz•8m ago

In the early days the Node ecosystem adopted (from Unix) the notion that everything has to be its own micro package. Not only was there a failure to understand what it was actually talking about, but it was never a good fit for a language package ecosystem to begin with. I have yet to hear of another language which suffers from this same affliction. I understand that there's been some course correction recently, but there are still many devs who think that the only answer to their problem is another package.

rafaelmn•5m ago

There are ecosystems that have package managers but also well developed first party packages.

In .NET you can cover a lot of use cases simply using Microsoft libraries and even a lot of OSS not directly a part of Microsoft org maintained by Microsoft employees.

vachina•5m ago

Node is the embodiment of move and break things. Probably will not build anything that should last more than a few months on node.

dkdbejwi383•22m ago

Node itself is still fine and you can do a lot these days without needing tons of library. No need for axios when we have fetch, there's a built-in test runner and assertion library.

There are some things that kind of suck (working with time - will be fixed by the Temporal API eventually), but you can get a lot done without needing lots of dependencies.

Gigachad•20m ago

The problem isn't specific to node. NPM is just the most popular repo so the most value for attacks. The same thing could happen on RubyGems, Cargo, or any of the other package managers.

vintagedave•18m ago

The concern is not 'could' happen, but _does_ happen. I know this could occur in many places. But where it seems highly prevalent is NPM.

And I am genuinely thinking to myself, is this making using npm a risk?

cluckindan•10m ago

Just use dependency cooldown. It will mitigate a lot of risk.

yoavm•4m ago

[delayed]

Ygg2•10m ago

NPM is the largest possible target for such an attack.

Attack an important package, and you can get into the Node and Electron ecosystem. That's a huge prize.

anonymous908213•19m ago

Node doesn't have any particular relation to NPM? You don't have to download 1000 other people's code. Writing your own code is a thing that you are legally allowed to do, even if you're writing in Javascript.

AIorNot•17m ago

So your supposed to write your own posthog? be serious

dkdbejwi383•15m ago

If they have a HTTP API using standard authentication methods it's not that difficult to create a simple wrapper. Granted a bit more work if you want to do things like input/output validation too, but there's a trade-off between ownership there and avoiding these kinds of supply-chain attacks.

jacquesm•8m ago

> Granted a bit more work if you want to do things like input/output validation too,

A bit? A proper input validator is a lot of work.

anonymous908213•6m ago

Yes. If your shop is serious about security, it is in no way unreasonable to be building out tools like that in-house, or else paying a real vendor with real security practices for their product. If you're an independent developer, the entirety of Posthog is overkill, and you can instead write the specific features you need yourself.

paradite•10m ago

npm has been the official package manager for node since forever (0.8 or earlier iirc). I think even before the io.js fork and merge.

jacquesm•9m ago

Yes, and you can code in assembly as well if you want it. But: that's not how 99% of the people using node is using it so that it is theoretically possible to code up every last bit yourself is true but it does not contribute to the discussion at all.

An eco-system, if it insists on slapping on a package manager (see also: Rust, Go) should always properly evaluate the resulting risks and put proper safeguards in place or you're going to end up with a massive supply chain headache.

paradite•19m ago

There's only two kind of technologies.

The ones that most people use and some people complain about, and the ones that nobody uses and people keep advocating for.

sandruso•16m ago

You can go very far with just node alone (accepts typescript without tsc, has testing framework,...). Include pg library that has no dependencies. Build a thin layer above node and you can have pretty stable setup. I got burnt so many times that I think it is simply impossible to build something that won't break within 3 months if you start including batteries.

When it comes to frontend, well I don't have answers yet.

zwnow•13m ago

Just keep the number of packages you use to a minimum. If some package itself has like 200 deps uninstall that and look for an alternative with less deps or think if you really need said package.

I also switched to Phoenix using Js only when absolutely necessary. Would do the same on Laravel at work if switching to SSR would be feasible...

I do not trust the whole js ecosystem anymore.

jacquesm•7m ago

Did Phoenix not require npm at some point or is that not true?

rvz•12m ago

> Serious question: should someone develop new technologies using Node any more?

I think we have given the Typescript / Javascript communities enough time. These sort of problems will continue to happen regardless of the runtime.

Adding one more library increases the risk of a supply-chain attack like this.

As long as you're using npm or any npm-compatible runtime, then it remains to be an unsolved recurring issue in the npm ecosystem.

jacquesm•11m ago

> Serious question: should someone develop new technologies using Node any more?

Please, no.

It is an absolutely terrible eco system. The layercake of dependencies is just insane.

cluckindan•5m ago

Node the technology can be used without blindly relying on the update features of npm. Vet your dependency trees, lock your dependency versions at patch level and use dependency cooldown.

This is something you also need to do with package managers in other languages, mind you.

weregiraffe•6m ago

Building websites =/= Developing new technologies.

julius-fx•25m ago

The list of affected packages is concerning - indeed.

timgl•25m ago

co-founder of PostHog here. We were a victim of this attack. We had a bunch of packages published a couple of hours ago. The main packages/versions affected were:

- posthog-node 4.18.1, 5.13.3 and 5.11.3

- posthog-js 1.297.3

- posthog-react-native 4.11.1

- posthog-docusaurus 2.0.6

We've rotated keys and passwords, unpublished all affected packages and have pushed new versions, so make sure you're on the latest version of our SDKs.

We're still figuring out how this key got compromised, and we'll follow up with a post-mortem. We'll update status.posthog.com with more updates as well.

spiderfarmer•21m ago

If we don't know how it got compromised, chances are this attack is still spreading?

brabel•16m ago

If anything people should use an older version of the packages. Your newest versions had just been compromised, why should anyone believe this time and next time it will be different?!

timgl•10m ago

The packages were published using a compromised key directly, not through our ci/cd. We rolled the key, and published a new clean version from our repo through our CI/CD: https://github.com/PostHog/posthog-js/actions/runs/196303581...

progbits•6m ago

Why do you keep using token auth? This is unacceptable negligence these days.

NPM supports GitHub workflow OIDC and you can make that required, disabling all token access.

timgl•4m ago

Yep, we are moving to workflow OIDC as the next step in recovery.

_alternator_•16m ago

Glad you updated on this front-page post. Your Twitter post is buried on p3 for me right now. Good luck on the recovery and hopefully this helps someone.

spiderfarmer•22m ago

Will the list of affected packages expand? How were these specific packages compromised in the first place?

gonepivoting•22m ago

We're monitoring this activity as well and updating the list of affected packages here: https://www.wiz.io/blog/shai-hulud-2-0-ongoing-supply-chain-...

Currently reverse engineering the malicious payload and will share our findings within the next few hours.

westoque•20m ago

a concern i have is that it's only a matter of time before a similar attack is done to electron based apps (which also have packages installed using npm). probably worse because it's installed in your computer and can potentially get any information especially given admin privileges.

vintagedave•20m ago

The list of packages looks like these are not just tiny solo-person dependencies-of-dependencies. I see AsyncAPI and Zapier there. Am I right that this seems quite a significant event?

AsyncAPI is used as the example in the post. It says the Github repo was not affected, but NPM was.

What I don't understand from the article is how this happened. Were the credentials for each project leaked? Given the wide range of packages, was it a hack on npm? Or...?

throw-the-towel•15m ago

My understanding is, it's a worm that injects itself into the current package and publishes infected code to npm.

merelysounds•14m ago

This is the second time an attack like this happens, others may be familiar with this context already and share fewer details and explanations than usual.

Previous discussions: https://news.ycombinator.com/item?id=45260741

I_am_tiberius•20m ago

I guess you should never use the latest versions of libraries.

sublinear•17m ago

Not sure if you're serious, but if so I agree that people should take the time to set up their own package mirrors. Not just for npm but all other package managers as well.

This is why it's so important to get to know what you're actually building instead of just "vibing" all the time. Before all the AI slop of this decade we just called it being responsible.

kaelwd•17m ago

Everyone needs to switch to pnpm and enable https://pnpm.io/settings#minimumreleaseage

Pnpm also blocks preinstall scripts by default.

Ygg2•17m ago

But you also need the latest versions to avoid zero-day attacks.

rvz•19m ago

Very concerning, so that was what the "impending disaster" was as I first noted. [0] Quite worrying that this happened again to the NPM ecosystem.

Really looking forward to a deeper post-mortem on this.

[0] https://news.ycombinator.com/item?id=46031864

jacquesm•4m ago

It will keep happening until someone takes responsibility and starts maintaining the whole of the node eco system. This is probably a viable start-up idea: Node but audited.

darkamaul•16m ago

The "use cooldown" [0] blog post looks particularly relevant today.

I'd argue automated dependency updates pose a greater risk than one-day exploits, though I don't have data to back that up. That's harder to undo a compromised package already in thousands of lock files, than to manually patch a already exploited vulnerability in your dependencies.

[0] https://blog.yossarian.net/2025/11/21/We-should-all-be-using...

jacquesm•5m ago

But even then you are still depending on others to catch the bugs for you and it doesn't scale: if everybody did the cooldown thing you'd be right back where you started.

Ygg2•5m ago

I don't buy this line of reasoning. There are zero/one day vulnerabilities that will get extra time to spread. Also, if everyone switches to the same cooldown, wouldn't this just postpone the discovery of future Shai-Huluds?

tomaytotomato•8m ago

Could npm adopt a reverse domain naming system similar to Java's for Maven libraries?

com.foo.bar

That would require domain verification, but it would add significant developer friction.

Also mandatory Dune reference:

"Bless the maker and his water"

KomoD•4m ago

I don't see how this solves the problem?

Shai-Hulud Returns: Over 300 NPM Packages Infected

RuBee

Fran Sans – font inspired by San Francisco light rail displays

We stopped roadmap work for a week and fixed bugs

Disney Lost Roger Rabbit

µcad: New open source programming language that can generate 2D sketches and 3D

Ask HN: Hearing aid wearers, what's hot?

The Rust Performance Book (2020)

Japan's gamble to turn island of Hokkaido into global chip hub

Breakthrough in antimatter production

Native Secure Enclave backed SSH keys on macOS

Lambda Calculus – Animated Beta Reduction of Lambda Diagrams

Build desktop applications using Go and Web Technologies

New magnetic component discovered in the Faraday effect after nearly 2 centuries

Show HN: Stun LLMs with thousands of invisible Unicode characters

Building the largest known Kubernetes cluster, with 130k nodes

Set theory with types

Calculus for Mathematicians, Computer Scientists, and Physicists [pdf]

Having Fun with Complex Numbers

Moss survived outside of the International Space Station for 9 months

A time-travelling door bug in Half Life 2

The Cloudflare outage might be a good thing

Passing the Torch – My Last Root DNSSEC KSK Ceremony as Crypto Officer 4

The Only GM EV1 Ever Publicly Sold, and Where It's Going Next

Hyperoptic: IPv6 and Out-of-Order Packets

Ego, empathy, and humility at work

Show HN: I wrote a minimal memory allocator in C

Pixar: The Early Days

Liva AI (YC S25) Is Hiring

Syd – An offline-first, AI-augmented workstation for blue teams

Shai-Hulud Returns: Over 300 NPM Packages Infected

Comments

Shai-Hulud Returns: Over 300 NPM Packages Infected

RuBee

Fran Sans – font inspired by San Francisco light rail displays

We stopped roadmap work for a week and fixed bugs

Disney Lost Roger Rabbit

µcad: New open source programming language that can generate 2D sketches and 3D

Ask HN: Hearing aid wearers, what's hot?

The Rust Performance Book (2020)

Japan's gamble to turn island of Hokkaido into global chip hub

Breakthrough in antimatter production

Native Secure Enclave backed SSH keys on macOS

Lambda Calculus – Animated Beta Reduction of Lambda Diagrams

Build desktop applications using Go and Web Technologies

New magnetic component discovered in the Faraday effect after nearly 2 centuries

Show HN: Stun LLMs with thousands of invisible Unicode characters

Building the largest known Kubernetes cluster, with 130k nodes

Set theory with types

Calculus for Mathematicians, Computer Scientists, and Physicists [pdf]

Having Fun with Complex Numbers

Moss survived outside of the International Space Station for 9 months

A time-travelling door bug in Half Life 2

The Cloudflare outage might be a good thing

Passing the Torch – My Last Root DNSSEC KSK Ceremony as Crypto Officer 4

The Only GM EV1 Ever Publicly Sold, and Where It's Going Next

Hyperoptic: IPv6 and Out-of-Order Packets

Ego, empathy, and humility at work

Show HN: I wrote a minimal memory allocator in C

Pixar: The Early Days

Liva AI (YC S25) Is Hiring

Syd – An offline-first, AI-augmented workstation for blue teams