by twistedpair
15 subcomments
- 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)
by darkamaul
5 subcomments
- 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.
by vintagedave
28 subcomments
- 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.
by nathan_compton
10 subcomments
- 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.
by gonepivoting
0 subcomment
- 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.
- GitLab's write-up mentions a dead man's switch where "The malware continuously monitors its access to GitHub (for exfiltration) and npm (for propagation). If an infected system loses access to both channels simultaneously, it triggers immediate data destruction on the compromised machine. "
https://about.gitlab.com/blog/gitlab-discovers-widespread-np...
by das_keyboard
1 subcomments
- 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?
- 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?
by smallerfish
2 subcomments
- 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?
by vintagedave
2 subcomments
- 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
- 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
to your .npmrchttps://blog.uxtly.com/getting-rid-of-npm-scripts
- 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/
by benmccann
2 subcomments
- 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
- 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.
- 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.
- 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/
by mittermayr
2 subcomments
- 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.
by alexchantavy
0 subcomment
- 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
by willtemperley
0 subcomment
- I just cannot believe what a cluster of a show this is. Microsoft, you own NPM, sort it out. It's ridiculous.
by 999900000999
1 subcomments
- I remember when I was young...
12 years ago NPM went down due to a very issue and getting stuff working again wasn't easy.
Someone got on GitHub and said something along the lines of "Get it together or get forked. "
I asked my manager if this was real or just a random guy talking. My manager, correctly said, it's just talk.
But it's different now. NPM is owned by Microsoft. One of the world's biggest companies should be able to sort things out.
Ohh well. Can't fix it.
by snickerbockers
1 subcomments
- 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)?
by AmazingTurtle
1 subcomments
- 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.
by tomaytotomato
3 subcomments
- 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"
by BrouteMinou
0 subcomment
- I was going to tell my team that we didn't hear about a NPM supply chain attack for about 2 weeks and that we should celebrate.
I guess it's not going to happen...
by jackconsidine
0 subcomment
- 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
by computersuck
0 subcomment
- I cannot believe how long it's taking github to shut this down, it's still going, and all they need to do is block a 18 char alphanumeric repo name from creation for this specific wave.
([0-9a-z]{18})
- Postman getting hit is scary. For many teams, it's effectively an unmanaged password manager for API keys.
by codedokode
2 subcomments
- 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.
- 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.
by developerjhp
0 subcomment
- I’ve been tracking these supply-chain incidents as well, so I built a small
real-time scanner that looks for suspicious SHA-1 patterns inside repositories.
It’s basically a lightweight CLI tool you can run directly inside any local
project:
npx sha1-hulud-scanner
Repo is here:
https://github.com/developerjhp/sha1-hulud-scannerIt’s not meant to be a full security product — just a simple “first-pass”
detector that helps catch unexpected checksum strings or injected artifacts
before they slip into CI. Feedback and contributions are welcome!
- 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 don’t feel confident there is a way to use npm safely. The basic problem is that of curation, and there not being any except for what you do yourself. Every day brings new surprises, and osv.dev’s npm feed is a continuous horror show.
I would love to see the equivalent of a linux distro, a curated set of packages and package versions that are known to be compatible and safe. If someone offered this as a paid product businesses would pay for it.
- `--ignore-scripts` should be the default behavior.
- 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.
- 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.
by throwawayffffas
1 subcomments
- > 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.
by rishabhaiover
2 subcomments
- Why can't package managers enforce attestations backed by a transparent log for each commit made to a public repository?
- I see a bunch of postman packages vulnerable. Does that mean the desktop application is compromised (oof)?
by I_am_tiberius
3 subcomments
- I guess you should never use the latest versions of libraries.
- 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?
- If the JS ecosystem continues like this, we're Duned.
- 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%...
by throwaway1389z
0 subcomment
- 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.
by liampulles
0 subcomment
- 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.
- 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.
- 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.
- 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.
by shadymoney
2 subcomments
- 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.
- 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.
by darnthenuggets
1 subcomments
- Both of these attacks have used trufflehog. Is there an out of the box way to block that executable by name or signature?
by gdotdesign
1 subcomments
- - There is a single root dependency somewhere which gets overtaken
- A new version of this dependency is published
- A CI somewhere of another NPM package uses this new version dependency in a build, which trigger propagation by creating a new modified version of this dependency?
- And so on...
Am I getting this right?
- Is there a terminal AI assistant that doesn't have heaps of depenedancies and preferably no node?
Claude and codex both require node. I'm a fan of the lightweight octofriend. But also node.
I do not like installing node on systems that otherwise would not require it.
by jbverschoor
0 subcomment
- I use the following to at least sandbox things in containers with an easy to use develop experience.
https://github.com/jrz/container-shell
- 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.
- 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 :(
- Maybe, we have to rethink depencies from the ground up.
Implementing everything yourself probably won't cut it.
Copying a dependency into your code base and maintaining it yourself probably won't yield much better results.
However, if a dependency would be part of the version control, depends could at least do a code review before installing an update.
That wouldn't help with new dependencies, that come in with issues right from.the start, but it could help preventing new malware from slipping in later.
A setup like that could benefit from a crowd-sourced review process, similar to Wikipedia.
I think, Nimble, the package manager of Nim, uses a decentralised registry approach based on Git repos. Something like that could be a good start.
- 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?
- Why do the attackers publicly share the keys they found? Like what’s their mission?
by indigodaddy
1 subcomments
- Is this a problem with Python package management too? If not, what distinguishes Python from NPM or makes it more resistant etc?
- "This appears to have limited the imapct of the attack at this time."
typo after the listed affected packages
- So people using only distro provided dependencies were indeed right all along. ;-)
by exceptione
1 subcomments
- My motto wrt language choices: "It's the standard lib, stupid!"
My ultra hot take: there are only¹ two² programming ecosystems suitable for serious³ work:
- .net (either run on CLR or compile as an AOT standalone binary)
- jvm
The reason why is because they have a vast and vetted std lib. A good standard lib is a bigger boost then any other syntactic niceties. __
1. I don't want other programming languages to die, so I am happy if you disagree with me. Other valid objection: some problems are better served by niche languages. Still, both .net and java support a plethora of niche languages.
2. Shades of gr[e|a]y, some languages are more complete out of the box than others.
3. cf «pick boring tools»
by ChicagoDave
0 subcomment
- I’m looking for info on whether MalwareBytes would catch this and not finding anything.
- Would the adoption of a Deno-like security posture in NPM have mitigated this?
- Funny coincidence reading this while in the middle of rewatching Dune 2 on Netflix
- the left-pad fiasco seems to have been the only time npm changed a policy and reacted to a security problem, since then it seems that supply chain attacks just belong to the npm-eco-system
by 1vuio0pswjnm7
0 subcomment
- I have never tried NPM. Somehow I can still find the software I want, or write it myself. I think I would find Javascript too slow
- How was the attack detected in the first place?
by sunshine-o
0 subcomment
- I was looking at the packages affected and there are some recognizable names.
The ones that got my attentions are the @ensdomains/*, that are the legit packages and are probably in every Ethereum/EVM/blockchain related apps for the resolution of decentralized domain names.
A quick search shows those Ledger hardware wallet use those libs too [0]
So I guess they weren't just after API keys.
- [0] https://github.com/search?q=org%3ALedgerHQ%20%40ensdomain&ty...
- > bun_environment.js is a highly obfuscated malicious JavaScript file. It is over 10MB in size and contains a significant amount of built-in logic for information theft.
That seems a bit silly. Even on the beefy boi I used to work on a 10MB hiccup in deployable size would have been sufficient to make me look.
I released one of the packages I work on last night so of course this drew my eye. I assume checking the unpacked size hasn’t gotten ridiculous confirms that your code is not infected yeah? And looks like it’s past time for me to set up a separate account for release management.
- Friends don’t let friends NPM.
by lukebechtel
0 subcomment
- This is still happening -- github should implement a hotfix to disallow creation of repos with this exact name and structure...
by scottcorgan
0 subcomment
- Thought this was about the band ...
by jhatemyjob
1 subcomments
- And this, kids, is why you should vendor your dependencies
- Once again, you cannot ask the open source world to provide you with free dependencies and security.
At some point, someone has to pay for an organisation whose job will be to review the contents of all of these modules.
Maybe one could split the ecosystem into "validated" and "non validated" stacks ? much like we have stable and dev branches ?
The people validating would of course give their own identity to build trust. And so, companies (moral person) should do that.
- 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
by spiderfarmer
0 subcomment
- Will the list of affected packages expand? How were these specific packages compromised in the first place?
by jamietanna
1 subcomments
- 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)
- The list of affected packages is concerning - indeed.
by ChrisArchitect
0 subcomment
- More:
SHA1-Hulud the Second Comming – Postman, Zapier, PostHog All Compromised via NPM
https://www.aikido.dev/blog/shai-hulud-strikes-again-hitting...
- Here's the underlying problem: let's imagine someone very smart. They figure out a way to solve this problem. They are not going to make any money by doing so. That's why we have this problem.
by nautilus12
1 subcomments
- If you always run npm inside of docker does that pretty much prevent attacks like this?
by yourapostasy
1 subcomments
- GitHub back in September already published their roadmap of mitigations to NPM supply chain attacks:
https://github.blog/security/supply-chain-security/our-plan-...
I'm guessing no one yet wants to spend the money it takes for centralized, trusted testing where the test harnesses employ sandboxing and default-deny installs, Deterministic Simulated Testing (DST), or other techniques. And the sheer scale of NPM package modifications per week makes human in the loop-based defense daunting, to the point that only a small "gold standard" subset of packages that has a more reasonable volume of changes might be the only palatable alternative.
What are the thoughts of those deep inside the intersection of NPM and cybersecurity?
- why don't web devs just learn html and css properly, and maybe xslt for the really complex transformations then use vanilla js only when it's truly necessary?
instead we've got this absolute mess of bloated, over-engineered junk code and ridiculously complicated module systems.
by agentifysh
0 subcomment
- these packages stood out for me
shinhan is a large korean bank and this admin area geo json util seems to be embedded in many korean gov services.
shinhan-limit-scrap
korea-administrative-area-geo-json-util
by David-Henrry
0 subcomment
- [dead]
by tony-john12
0 subcomment
- [dead]
by sora2video
0 subcomment
- [dead]
by throwaway984393
0 subcomment
- [dead]
by burninhell
0 subcomment
- I wish everyone here would read https://en.wikipedia.org/wiki/Capability-based_security and then realize that maybe, JUST MAYBE, THE PROGRAMMING LANGUAGES WE USE SHOULD NOT ALLOW IMPORTED PACKAGES TO ACCESS EVERYTHING, AND THEIR LACK OF SECURITY GUARANTEES AND ACCESS RESTRICTION MECHANISMS MAKES THEM DANGEROUS!
The number and range of affected devices may be reduced with any number of package manager level workarounds, but NOT the impact of attacks once any succeeds. For this, you NEED the above.
- What we need is an open source industry standard stdlib equiv developed and maintained by MS, GOOG and some open source players.
All libraries should strive to have dependency only on it.
by amitassaraf
1 subcomments
- There are actually hundreds more NPM packages infected, see here: https://www.koi.ai/incident/live-updates-sha1-hulud-the-seco...
Hacker News