SHA1-Hulud the Second Comming – Postman, Zapier, PostHog All Compromised via NPM
33 comments
·November 24, 2025nathan_compton
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.
netdevphoenix
> if I am going to run some code from somewhere and I haven't read it, it goes in a container
How does this work? Every single npm package has tons of dependency tree nodes
Lutger
Everything runs in the container and cannot escape it. Its like a sandbox.
You have to make sure you're not putting any secrets in the container environment.
mlnj
>You have to make sure you're not putting any secrets in the container environment.
How does this work exactly? containers still need env vars and access to databases and cloud environments. Without these the container is just useless isolated pod.
moffkalast
All right then, keep your secrets.
swsieber
I didn't read this as separate containers.
echelon
Another effective strategy I learned of recently that seems like it would have avoided this is to wait months before using new versions of packages.
Most attacks on popular packages last at most a few months before detection.
rco8786
How are you doing this in practice? These are npm packages. I don't see how could reasonably pull in Posthog's SDK in a container.
christophilus
What do you mean? You can drop into bash in a container and run any arbitrary command, so `npm install foo` works just fine. Why would posthog's SDK be a special case?
LeifCarrotson
I think the issue is more about what else has to go into or be connected to that container. Posthog isn't really useful if it's air-gapped. You're going to give it keys to access all kinds of juicy databases and analytics, and those NPM tokens, AWS/GCP/Azure credentials, and environment variables are exactly what it exfiltrates.
I don't run much on the root OS of my dev machine, basically everything is in a container or VM of some kind, but that's more so that I can reproduce my environment by copying a VMDK than in an effort to limit what the container can do to itself and data it has access to. Yeah, even with root access to a VM guest, an attacker they won't get my password manager, personal credit card, socials, etc. that I only use from the host OS... But they'll get everything that the container contains or has access to, which is often a lot of data!
myaccountonhn
I ssh into a second local user and do development there instead with tmux.
n4r9
I send mail to a demon which runs MsBuild and mails the output back to me.
smallerfish
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?
raunakchowdhuri
Have a slack channel with them, these are the versions they mentioned: posthog-node 4.18.1 posthog-js 1.297.3 posthog-react-native 4.11.1 posthog-docusaurus 2.0.6
timgl
co-founder here. We mentioned it in the main thread about this: https://news.ycombinator.com/item?id=46032650 and on status.posthog.com
- 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
If you make sure you're on the latest version you should be good.
smallerfish
Thanks. Also - maybe change "talk to a human" to "talk to a grumpy robot" :)
xnorswap
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.
QuantumNomad_
Typo in title. Current title of HN post says:
> SHA1-Hulud the Second Comming – Postman, Zapier, PostHog All Compromised via NPM
Should be Shai-Hulud, not SHA1-Hulud.
adzm
That said, the secrets are uploaded to a repo named `Sha1-Hulud: The Second Coming`
zahlman
Ah, I missed that detail.
pezezin
The worm itself is posting the secrets in Github with the name Sha1-hulud: https://github.com/search?q=sha1-hulud&type=repositories
zahlman
I don't know why you were downvoted. The actual page does not say SHA1, the attack as far as I know is not related to the SHA1 algorithm, and the name of the worm isn't intended as that sort of pun.
JadoJodo
Would the adoption of a Deno-like security posture in NPM have mitigated this?
jamietanna
See also: https://news.ycombinator.com/item?id=46005111
As it arguably would have reduced impact
(I'm one of the Renovate maintainers and have recently pushed for this to be more of a widely used feature)
benzible
a4isms
Please use the word "Dup" for a resubmission of the same link and "See also" for a different submission.
swsieber
This article has quite a bit more information though.
thih9
Not a dup, this is a different article about the same event, with different information too.
neogodless
See also: https://news.ycombinator.com/item?id=46032539 Shai-Hulud Returns: Over 300 NPM Packages Infected (helixguard.ai)
~6 hours ago | 430 comments
ChrisArchitect
[dupe] Discussion: https://news.ycombinator.com/item?id=46032539
David-Henrry
[dead]
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.