Shai-Hulud Returns: Over 300 NPM Packages Infected

ProTip: use PNPM, not NPM. PNPM 10.x shutdown a lot of these attack vectors.

1. Does not default to running post-install scripts (must manually approve each)

2. Let's you set a min age for new releases before `pnpm install` will pull them in - e.g. 4 days - so publishers have time to cleanup.

NPM is too insecure for production CLI usage.

And of course make a very limited scope publisher key, bind it to specific packages (e.g. workflow A can only publish pkg A), and IP bound it to your self hosted CI/CD runners. No one should have publish keys on their local, and even if they got the publish keys, they couldn't publish from local. (Granted, GHA fans can use OIDC Trusted Publishers as well, but tokens done well are just as secure)

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...

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.

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.

I never, ever, do development outside of a podman container these days. Basically if I am going to run some code from somewhere and I haven't read it, it goes in a container.

I know its not foolproof, but I can't believe how often people run code they haven't read where it can make a huge mess, steal secrets, etc. I'll probably get owned someday, I'm sure, but this feels like a bare minimum.

Because PostHog's "Talk to a human" chat instead gets a grumpy gatekeeping robot (which also doesn't know how to get you to a working urgent support link), and there's nothing prominently on their home page or github about this:

Hey PostHog! What version do we need to avoid?

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.

Why the biggest package mess is always with the Node ecosystem?

Why in particular this community still insists on preemptively updating all deps always, on running complicated extra hooks together with package installation and pretending this all is good engineering practices? ("Look, we have so plenty of things and are so busy, thus it must be good")

Why certain kind of mindset is typical to this community?

Why the Node creator abandoned his creation years ago?

Why, oh why?

Run npm and yarn inside docker [1].

Infact, do this for all risky tools[2]

1 - https://github.com/ashishb/dotfiles/blob/067de6f90c72f0cf849...

2 - https://ashishb.net/programming/run-tools-inside-docker/

Slightly OT, but who is HelixGuard?

The website is a mess (broken links, broken UI elements, no about section)

There is no history on webarchive. There is no information outside of this website and their "customers" are crypto exchanges and some japanese payment provider.

This seems a bit fishy to me - or am I too paranoid?

I compiled a list of NPM best practices one can adopt to reduce supply chain attack risks (even if there's no perfect security preventions, _always_): https://github.com/bodadotsh/npm-security-best-practices

Discussion on HN last time: https://news.ycombinator.com/item?id=45326754

Mitigate this attack vector by adding:

  ignore-scripts=true

https://blog.uxtly.com/getting-rid-of-npm-scripts

Shai-Hulud is the best thing to happen for npm.

It's much easier to demonstrate a problem (twice!) than to convince a herd that there is a problem.

I hope that other languages with similar package manager (looking at you, cargo) take note.

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...?

"No Way To Prevent This" Says Only Package Manager Where This Regularly Happens

This is a good sign that it's time to get packages off of NPM and come up with an alternative. For those who haven't heard of or tried Verdaccio [1], it may be an option. Relatively easy to point at your own server via NPM once you set it up.

[1] https://verdaccio.org/

There is no easy solution to these problems.

The solutions that are effective also involve actually doing work, as developers, library authors, and package managers. But no, we want as much "convenience" as possible, so the issues continue.

Developers and package authors should use a lockfile, pin their dependencies, be frugal about adding dependencies, and put any dependencies they do add through a basic inspection at least, checking what dependencies they also use, their code and tests quality, etc.

Package managers should enforce namespacing for ALL packages, should improve their publishing security, and should probably have an opt-in verified program for the most important packages.

Doing these will go a long way to ameliorate these supply chain attacks.

Hundreds of people had access to publish the Zapier SDK, so it's little surprise they were eventually compromised! (https://bsky.app/profile/benmccann.com/post/3m6fdecsbdk2u)

The e18e community are reducing dependencies in popular libraries and building tools to prevent and reduce the impact of such attacks. Join if you want to help out! https://e18e.dev/

Just this morning, after trying to make the case over the past year, we had a change landed to remove more than a dozen dependencies from typescript-eslint! https://bsky.app/profile/benmccann.com/post/3m6fcjax7ec2h

I always (very naively, I fully get it) wonder if someone at GitHub could take a minute and check the logs (if there are any at this level) from a week ago or so and scan them for patterns? The code seems to grab a few files off of GitHub, use Github actions, etc. -- perhaps there's a pattern in there that shows the attacker experimenting and preparing for this? I assume most people at this level have VPNs and so forth, but I'd never underestimate the amount of bad luck even those folks can have. Would be interesting, I know I'd have a look, if those logs existed.

I looked through some of the GH repositories and - dear god - there are some crazy sensitive secrets in there. AWS Prod database credentials, various API keys (stripe, google, apple store, ...), passwords for databases, encryption keys, ssh keys, ...

I think hijacked NPM packages are just the tip of the ice berg.

Whats the most full proof way of defending ourselves from such attacks? My opinion is that the applications should never deal with credentials at all. Sidecars can be run which can inject credentials in real time. These sidecars can be under tight surveillance against such attacks. After all, application code is the most volatile in an organization.

How do you test your projects if there are any infected/affected dependencies used? As i understand it could also be a dependency of a dependency ... that could be affected?

Ok, I think the verdict on the "JavaScript for everything" experiment is in. It was already resolved long ago (in my opinion), but this should convince any stragglers. Let's accept that the one thing JS is really great for is DOM patching, and move on.

Going forward, use WASM if you really want to make an SPA (and think about that choice), where the source language is not something that ties into the JS dependency ecosystem. Ban it and burn it with fire for anything on the backend, for christ.

So people using only distro provided dependencies were indeed right all along. ;-)

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"

Small plug for my open source project: you can use Cartography [https://github.com/cartography-cncf/cartography], to map your infra and then run this query (https://gist.github.com/achantavy/2cc7cc49919a8f761fea5e2d75...) to see if you're affected

Why does every major Javascript vulnerability come off as something that would be easily avoided by not doing obviously stupid things (in this case automatically updating packages with no authentication, testing or oversight)?

Does NPM use any automatic scanners? Just scanning for eval/new Function/base64 and other tokens often used by malware, and requiring a manual review, could already help.

Also package manager should not run scripts.

Perhaps it's time to organize a curated "stable" stream for npm packages.

If I want more stability for my OS I can choose Debian-stable rather than Ubuntu-nightly.

But for npm, there doesn't seem to be the same choice available. Either I sign up to the fire-hose or I don't.

I can choose to only upgrade once a month, but there's a chance I'm still getting a package that dropped 5 minutes before.

https://github.blog/security/supply-chain-security/our-plan-...

So github has some tools available to mitigate some of the problems tied to it. Probably not perfect for all use cases. But considering the current scale, it doesn't seem to have any effect, as enough publishers seem not to care.

I think npm should force higher standards on popular packages.

I am amazed at the dates in this article. This compromise appears to have been discovered literally this morning. Incredibly fast turnaround on this article.

Whats the most full proof way of defending ourselves from such attacks? My opinion is that the applications should never deal with credentials at all. Sidecars can be run which can inject credentials in real time. These sidecars can be under tight surveillance against such attacks. After all, application code is the most volatile in an organization.

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.

I use pnpm, but even so: thankfully naming things is hard, and all my env variable names are very_convuluted_non_standard_names for things lol.

Used the following script to see if I had any affected packages:

https://gist.github.com/considine/2098a0426b212f27feb6fb3b4d...

It checks yarn.lock for any of the above. Maybe needs a tweak or two but you should be able to run from a directory with yarn.lock

`--ignore-scripts` should be the default behavior.

> Upon execution, the malware downloads and runs TruffleHog to scan the local machine, stealing sensitive information such as NPM Tokens, AWS/GCP/Azure credentials, and environment variables.

That's a wake up call to harden your operations. NPM Tokens, AWS/GCP/Azure credentials have no reason to be available in environments where packages may be installed. The same goes for sensitive environment variables.

Why can't package managers enforce attestations backed by a transparent log for each commit made to a public repository?

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

What is going on with this website though? It gives cursor stutter and slow scrolling. It seems like we now need an insane amount of CPU to read static text. What a regression.

Documenting technical details and payload analysis here: https://safedep.io/shai-hulud-second-coming-supply-chain-att...

Like previous variant, it has credential harvesting, self-replication and GitHub public repository based exfiltration.

Double base64 encoded credentials being exposed using GitHub repositories: https://github.com/search?q=%22Sha1-Hulud%3A%20The%20Second%...

Postman getting hit is scary. For many teams, it's effectively an unmanaged password manager for API keys.

I find it unbelievable that npm still doesn't upgrade integrity entries to SHA512 across the board. This seems like such a simple hole to plug. What gives?

I see a bunch of postman packages vulnerable. Does that mean the desktop application is compromised (oof)?

Seems to me the root problem here is poor security posture from the package maintainers. We need to start including information about publisher chain of custody into package meta data, that way we can recursively audit packages that don't have a secure deployment process.

As a marketer who relies on tools like Zapier and PostHog and n8n, etc - terrifing. Since it means the dev/security teams may take our toys away :(

If the JS ecosystem continues like this, we're Duned.

This is why I am not a huge fan of separate package managers for libraries, such as in the case of rust, or node. The C style of sharing deps. couldn't really be simpler as just including the headers in your Makefile.

We really don't need more package managers other than the ones provided by your operating system, but I dunno maybe its just me.

containerize all the things...Nix, Podman, Docker. It's not a big hassle once you get through the initial steps.

Would be good to see projects (like those recently effected) nudging devs to do this via install instructions.

I use the following to at least sandbox things in containers with an easy to use develop experience.

https://github.com/jrz/container-shell