Please be careful when revoking tokens. It looks like the payload installs a dead-man's switch at ~/.local/bin/gh-token-monitor.sh as a systemd user service (Linux) / LaunchAgent com.user.gh-token-monitor(macOS). It polls api.github.com/user with the stolen token every 60s, and if the token is revoked (HTTP 40x), it runs rm -rf ~/.
You seem to be interpreting "please be careful when..." as "don't". I'm not sure how that interpretation makes any sense. Obviously they just mean, first kill the service (or better yet, shutdown the machine entirely) and then revoke the token...?
Only if the goal is to actually spread fear in a civilian population. It's not clear what the motivation is here besides "the worm spreads itself lol".
The dead man's switch reminds me of worms and viruses from my childhood, whose primary purpose was apparently just to wreak havoc rather than direct financial gain. It's a childish gimmick.
If an infected computer gets disabled after deactivating one stolen credential, it might slow down the victim from deactivating their other stolen credentials.
It is unfortunate, but this is evidence (IMO) that Trusted Publishing is still ~~not secure~~ not enough by itself to securely publish from CI, as an attacker inside your CI pipeline or with stolen repo admin creds can easily publish. This isnt new information, TP is not meant to guarantee against this, but migrating to TP away from local publish w/ 2fa introduces this class of attack via compomise of CI. (edit: changed "still not secure" to "still not enough by itself" bc that is the point I want to make)
Going to Trusted Publishing / pipeline publishing removes the second factor that typically gates npm publish when working locally.
The story here, while it is evolving, seems to be that the attacker compromised the CI/CD pipeline, and because there is no second factor on the npm publish, they were able to steal the OIDC token and complete a publish.
Interesting, but unrelated I suppose, is that the publish job failed. So the payload that was in the malicious commit must have had a script that was able to publish itself w/ the OIDC token from the workflow.
What I want is CI publishing to still have a second factor outside of Github, while still relying on the long lived token-less Trusted Publisher model. AKA, what I want is staged publishing, so someone must go and use 2fa to promote an artifact to published on the npm side.
Otherwise, if a publish can happen only within the Github trust model, anyone who pwns either a repo admin token or gets malicious code into your pipeline can trivially complete a publish. With a true second factor outside the Github context, they can still do a lot of damage to your repo or plant malicious code, but at least they would not be able to publish without getting your second factor for the registry.
I'd like to have touch to sign from a YubiKey or similar. The whole idea of trusting the cloud to manage credentials on your behalf seems like a mistake.
”TanStack maintainer Tanner Linsley said the attacker used an orphaned commit to gain access to the workflow run that stores the OIDC token, effectively bypassing the project’s existing publishing protections. He noted that two-factor authentication is enabled for everyone on the team”
The astral blog recently pointed out how they do release gates (manual approvals on release workflows) even with trusted publishing. And sadly, all of the documentation for trusted publishing (NPM/PyPi/Rubygems) doesn't even mention this possibility, let alone defaulting to it.
I have not read that blog post. But unfortunately (and I'd love to be wrong!) it doesn't matter for if a repo admin's token gets exfiled, because if you put your gates within Github, an admin repo token is sufficient to defang all of them from the API without 2fa challenge.
That is why I want 2fa before publish at the registry, because with my gh cli token as a repo admin, an attacker can disable all the Github branch protection, rewrite my workflows, disable the required reviewers on environments (which is one method people use for 2fa for releases, have workflows run in a GH environment whcih requires approval and prevents self review), enable self review, etc etc.
Its what I call a "fox in the hen house" problem, where you have your security gates within the same trust model as you expect to get stolen (in this case, having repo admin token exfiled from my local machine)
> We impose tag protection rules that prevent release tags from being created until a release deployment succeeds, with the release deployment itself being gated on a manual approval by at least one other team member. We also prevent the updating or deletion of tags, making them effectively immutable once created. On top of that we layer a branch restriction: release deployments may only be created against main, preventing an attacker from using an unrelated first-party branch to attempt to bypass our controls.
I tested approving a deployment via API last week w/ my gh cli token (well, had claude do it while I watched). Again, I really want to be wrong about this, but my testing showed that it is indeed trivial to use the default token from my gh cli to approve via API. (repo admin scope, which I have bc I am admin on said repo)
Nothing in this link [1] proves what I said, but it is the test repo I was just conducting this on, and it was an approval gated GHA job that I had claude approve using my GH cli token
I also had claude use the same token to first reconfigure the enviornment to enable self-approves (I had configured it off manually before testing). It also put it back to self approve disabled when it was done hehe
Both of these need `repo` scope, which you can avoid giving on org-level repos. For fine-grained tokens: "Deployments" repository permissions (write) is needed, which I wouldn't usually give to a token.
I'm looking forward to the analysis how the attacker managed to compromise CI. I was reading through the workflow and what immediately jumped out was a cache poisoning attack. Seems plausible, given https://github.com/TanStack/config/pull/381
edit: two hard things in computer science: naming things, cache invalidation, off-by-one errors, security. something something
Postinstall scripts are deadly.
Everyone should be using pnpm.
Crazy that an "orphan" commit pushed to a FORK(!) could trigger this (in npm clients). IMO GitHub deserves much of the blame here. A malicious fork's commits are reachable via GitHub's shared object storage at a URI indistinguishable from the legit repo. That is absolutely bonkers.
Once you run your app with the updated dependencies, that code is executed anyway. And root or non-root doesn't matter, the important stuff is available as the user running the application anyway.
This sort of mitigation seems like it makes sense in the short term, but it seems like it would only work as long as most people don't do it. If everyone has this set to seven days, it will take seven days plus three hours to get things yanked, and then there will be people who will set to 14 days...
1) Package owners will often realise they've been hacked quickly, since there are releases they never authorised. This gives them plenty of time to raise the alarm and yank the packages
2. Independent security researchers and other automated vulnerability scans will still be checking the latest releases even if users aren't using them
Yes it's not a perfect defense but it would help a lot.
This confused me too, until I realized that the article is about pnpm, not npm (pnpm reads .npmrc for some reason, despite not having the same options as npm)
On a related note, it seems to be impossible to find the documentation of min-release-age by googling it. Very annoying.
I just set this up for npm, here's the command that worked for me:
npm config set min-release-age 7
The '7' is days. This is the only format that worked for me, just a single integer number of days.
Confirmed by trying to install the latest version of React 19.2.6 (published 5 days ago as of the time of this comment). It failed with a comment confirming that it could not find such a version published before a week ago.
Npm's package-lock.json already handles pinning everything to exact versions, including subdependencies. Pinning exact versions in package.json doesn't affect your subdependencies.
Are you talking about in package.json? What's your threat model? That's what the lock file is for, which also pins transitive dependencies, which is just as crucial. Now what's actually insecure is if you don't commit the lockfile. and if you don't do `npm ci`.
I think `npx` might pull down new versions, too? I wish npm worked more like Elixir where updating the lock file was an explicit command, and everything else used the lock file directly.
Or help distributions do the manual process of packaging - which involves at least rudimentary security checks - so they can ship newer versions faster.
And then use distro packages.
(I'm not accepting distro fragmentation as counterargument. With containerization the distro is something you can choose. Choose one, help there, and use it everywhere.)
> it used to be that projects that pinned deps were called out as being less secure due to not being able to receive updates without a publish.
This is still the right advice for libraries. For security it doesn’t matter a whole lot anymore as package managers can force the transitive dependencies version, but it allows for much better transitive dependency de duplication.
For non-libraries it doesn’t matter as the exact versions get pinned in the package-lock.
- Python inline dependencies in PEP-0723, which you can pin with a==1.0, but can't be hash-pinned afaik.
- The bin package manager lets you pin binaries, but they aren't hash-pinned either.
- The pants build tool suggests vendoring a get-pants.sh script[0] but it downloads the latest. Even if you pass it a version, it doesn't do any checks on the version number and just installs it to ~/.local/bin
Or a vm per container, if you insist on containers. I've have a couple of relaxed weeks recently due to running everything on VMs rather than some random Kubernetes service.
It's been less than a month since I responded to a comment on a different thread arguing basically the same thing about C/C++ in a serious way. I've long since lost the ability to distinguish.
The Mini Shai-Hulud worm is actively compromising legitimate npm packages by hijacking CI/CD pipelines and stealing developer secrets. StepSecurity's OSS Package Security Feed first detected the attack in official @tanstack packages and is tracking its spread across the ecosystem in real time.
The malware uses a "prepare" hook to use bun to run the payload, an attack that ironically enough, bun is immune to. Enabling lifecycle scripts in dependencies by default in 2026 is just plain malpractice.
How likely is it that I have this installed if I'm not a JS developer? It seems like half of the programs on my work computer install their own JS runtime.
It sounds like you can check for `~/.local/bin/gh-token-monitor.sh` or if there's an extra macOS LaunchAgent (I use LaunchPad on macOS to manage my launchctl services). You can also check systemd on linux, but I'm less familiar.
1. _Multiple third-party companies_ can detect these obviously malicious packages in almost-real-time
2. NPM still not only publishes them, but also keeps distributing them for anything beyond 5 minutes.
Microsoft/GitHub/NPM can only keep repeating "security is our top priority" so many times. But NPM still doesn't detect these simple attacks, and we keep having this every week.
> Please be careful when revoking tokens. It looks like the payload installs a dead-man's switch at ~/.local/bin/gh-token-monitor.sh as a systemd user service (Linux) / LaunchAgent com.user.gh-token-monitor(macOS). It polls api.github.com/user with the stolen token every 60s, and if the token is revoked (HTTP 40x), it runs rm -rf ~/. (It looks like it might also have a bunch of persistence mechanisms. I haven't studied these closely.)
> making it the first documented case of a self-spreading npm worm that carries valid SLSA provenance attestations
I’m sorry, but what is the point of a provenance attestation that can be generated automatically by malware? I would think that any system worth its salt would require strong cryptographic proof tying to some hardware trust root, not just “yep, this was was built on a github actions runner that had access to an ENV key.” It seems like this provenance scheme only works if the bad guys are utterly without creativity.
> it installs that commit's declared dependencies (which include bun) and then runs its prepare lifecycle script
Again? How have lifecycle scripts not instantly been defaulted off? Yes breaking things is bad, but come on, this keeps happening, the fix is easy, and if an *javascript* build relies of dependendlcy of dependency's pulled build time script, then it's worth paying in braincells or tokens to digure it out and fix the biold process, or lately uncover an exploit chain. This isn't even a compiled language.
Can you explain further? TanStack has popped up in our apps and I don't know why I should not be falling for this or what exactly the "this" is that is being fallen for.
as someone who encountered this cargo culted at a number of start ups -- I beg to differ. React Query I will always pass on. the other lesser known hits of tanstack -- won't even consider.
My decision to abandon the JS ecosystem and language entirely continues to pay off. What a mess...
I am, however, concerned that this will pwn my workplace. We don't use Tanstack but this seems self-propagating and I doubt all of our dependencies are doing enough to prevent it.
Cargo is spiritually based on NPM so it's not much better.
Go Get is closer to always locking dependencies unless you explicitly upgrade them with a go get, so it's much much better in my view.
Yes, you can lock deps in NPM/Cargo/etc. but that's not the default. It is the default in Go.
In Go projects my policy for upgrading dependencies includes running full AI audit of all code changed across all dependencies, comes out to ~$200 in tokens every time but it gives those warm 'not likely to get pwned' vibes. And it comes with a nice report of likely breaking changes etc.
BTW a curated mirror of <whatever ecosystem> packages, where every package is guaranteed to have been analyzed and tested, could be an easy sell now. Also relatively easy to create, with the help of AI. A $200 every time is less pleasant than, say, $100/mo for the entire org.
Docker does something vaguely similar for Docker images, for free though.
People are already scanning npm constantly. You can limit yourself to pre-scanned packages by setting npm's minimum release age setting to 1 or 2 days (a timeframe that all the recent high-profile malicious package versions were unpublished within).
Note to self: the test suite for vetting a package should include setting the system date some time in the future, to check if an exploit is trying to sleep long enough to defeat the age limit.
It's insane to me you spend $200 on a report you likely rarely read in detail or double check for correctness, yet you're doing it to feel good about security.
If it runs in a harness that will alert me when something dodgy is detected I'm fine to stay at that level.
I don't read it in detail because reading in detail is precisely what I delegate to the harness. The alternative is that I delegate all this trust to package managers and the maintainers which quite clearly is a bad idea.
Whether the $$ pricetag is worth it is.. relative. Also in Go you don't update all that often, really when something either breaks or there is a legitimate security reason to do so, which in deep systems software is quite infrequent.
Funnily enough for frontend NPM code our policy was to never ever upgrade and run with locked dependencies, running few years old JS deps. For internal dashboards it was perfectly fine, never missed a feature and never had a supply chain close call.
What do you when a critical vulnerability gets discovered and you have to update a package? How many critical/high severity vulnerabilities are you running with in production every day to avoid supply chain attacks?
It is the default in both cargo and npm, but "npm install" stupidly enough still updates the lockfile, and you need "npm ci" to actually respect it. I think there's some flag to make install work sanely, but long-term I find the best approach is to use anything other than npm.
I ditched npm for yarn years ago because it had saner dependency resolution (npm's peer dependency algorithm was a constantly moving target), and now I've switched from yarn to bun because it doesn't run hooks in dependencies by default. It also helps that it installs dependencies 10x faster.
Even linux was subjected to an attack in xz utils. Granted it is much harder and they have a much better auditing problem (something npm should learn from). There really isn't a silver bullet here unfortunately. The industry as a whole needs to get more serious about this.
There's no silver bullet, but getting an exploit into xz took extraordinary effort, a long time, and bespoke code, because it needed to slip under the radar of actual humans reading the code. A shai hulud-style attack won't work with any reasonable Linux distro, like it does with npm.
Exactly, the only real way to escape this madness is if we move back to "Standard Libs" where your project only depends on 1-3 core libraries. For example, .NET and Java are almost entire 'kitchen sink' ecosystems. Arguably for simple projects, Go has a fairly large standard lib.
There are npm supply chain exploits in the news every other day. I'm honestly surprised that something as decentralized as Go Modules is more reliable, but here we are. The fact that we're not seeing these stories about e.g. Maven is not at all surprising, given the limited need for third party libraries and the culture of careful upgrades in the Java ecosystem. If npm proponents want the ecosystem to survive, they need to demand / create better and stop making excuses.
I highly recommend enforcing a minimum dependency release age of at least a week across all package managers used at your workplace. Most package managers support it now, and it will save you from the vast majority of these attacks.
Highly recommend using the minimum release age setting, though I think a week is probably overkill. Did any of the recent supply-chain attacks have a malicious version up for more than a day?
Maybe not, but how much of that was luck? I think it's only a matter of time until a similar compromise happens but nobody notices it for a few days, better safe than sorry.
Once again, Shai-Hulud wrecking havock in the Javascript and Typescript ecosystems via NPM.
One of the worst ecosystems that has been brought into the software industry and it is almost always via NPM. Not even Cargo (Rust) or go mod (Golang) get as many attacks because at least with the latter, they encourage you to use the standard library.
Both Javascript and Typescript have none and want you to import hundreds of libraries, increasing the risk of a supply chain attack.
> Both Javascript and Typescript have none and want you to import hundreds of libraries
There are plenty of very popular packages with zero dependencies like Hono or Zod. If you decide to blindly install something with hundreds of deps it's on you.
That said, I do agree the JS standard library should provide a lot more than it does now.
I wonder whether NPM has surpassed the costs of the billion dollar mistake, null references. NPM hasn't been around as long, but the industry is much bigger today than it was when systems languages were dominant.
The Standard C library is also very small. Even though there’s POSIX, for anything that’s not system programming, you will be using libraries.
The difference is that the usual C libraries don’t split the project into small molecules for no good reasons. You have to be as big as GTK to start splitting library in my opinion.
People have for years. The real question is do people enjoy not putting any thought into their super convenient JavaScript stack too much to actually do anything about it. Delaying updating to new packages assuming the vulnerability will be discovered in two days or whatever is putting a knee brace on a leg that needs to be amputated. Sooner or later there will be a vulnerability good enough to not be caught in a couple days, or a zero-day damaging enough that not updating immediately is a huge risk. Assuming they won’t be in anything critical enough to disastrously compromise your stack is wishful thinking at its finest.
The part that always gets me is I tend to only install a few packages like React and maybe some kind of data access layer. But you let that recurse down a few levels and suddenly you've installed a thousand packages, some of them hopelessly obsolete, some of them for patently stupid things that are 1 line of code, etc, etc. I.E. you can't choose to be thoughtful if the main entry points into the language are all built on a pile of garbage.
Now that npm supports --before, yarn supports npmMinimumAge, and pnpm supports minimumReleaseAge, it's quite possible to stay safe and avoid acciasional bleeding-edge upgrades. Stay a couple months into the past, give testers time to look at newer releases and vet their safety (or report an exploit attempt).
npm's immaturity is arguably demonstrated by the fact it is always catching up.
Please correct me if I'm wrong but signed packages are still impractical in NPM which is why supply chain attacks still work by editing existing versions or pushing new point releases without a signature.
Or if you put all of the credentials in GitHub actions which is even more trivially exploitable through the actions marketplace because it is just git with a thin proxy, you have an even wider attack vector
Please be careful when revoking tokens. It looks like the payload installs a dead-man's switch at ~/.local/bin/gh-token-monitor.sh as a systemd user service (Linux) / LaunchAgent com.user.gh-token-monitor(macOS). It polls api.github.com/user with the stolen token every 60s, and if the token is revoked (HTTP 40x), it runs rm -rf ~/.
https://github.com/TanStack/router/issues/7383#issuecomment-...
I don't understand why people were voting this comment down in the issue page
Maybe they have a non-standard interpretation of thumbs-down – as "thumbs-down to this fact" not "thumbs-down to you for pointing it out"
bots.
the GitHub bot law: the GitHub bot situation is way worse than you imagine even if you are aware of the GitHub bot law.
yes, a cheap parody on Hofstadter's law, but that's how bad it is
There is no such thing as please be careful when revoking tokens. What does that mean? Dont revoke them? Look at them carefully before revoking them?
And what? Just let the actor just keep using them to spread to other people?
Always rotate your tokens immediately if they're compromised.
If it hurts, well, that sucks. …but seriously, not revoking the tokens just makes this worse for everyone.
A fair comment would have been: “it looks like the payload installs a dead-mans switch…”
Asking the maintainers not to revoke their compromised credentials deserves every down vote it receives.
You seem to be interpreting "please be careful when..." as "don't". I'm not sure how that interpretation makes any sense. Obviously they just mean, first kill the service (or better yet, shutdown the machine entirely) and then revoke the token...?
if so, then this is actual terrorism of the software world!!
Only if the goal is to actually spread fear in a civilian population. It's not clear what the motivation is here besides "the worm spreads itself lol".
that dead man's switch surely smells like that tbh
The dead man's switch reminds me of worms and viruses from my childhood, whose primary purpose was apparently just to wreak havoc rather than direct financial gain. It's a childish gimmick.
If an infected computer gets disabled after deactivating one stolen credential, it might slow down the victim from deactivating their other stolen credentials.
Incredible. Mutually assured destruction.
The next five years are going to be truly WILD in the software world.
Air-gapped systems are gonna be huge.
One should always have had backups configured, but if this is what gets people to setup backups, so much the better.
@mistralai/mistralai npm package was also compromised as part of this worm https://github.com/mistralai/client-ts/issues/217
It has been pulled from the npm registry now.
It is unfortunate, but this is evidence (IMO) that Trusted Publishing is still ~~not secure~~ not enough by itself to securely publish from CI, as an attacker inside your CI pipeline or with stolen repo admin creds can easily publish. This isnt new information, TP is not meant to guarantee against this, but migrating to TP away from local publish w/ 2fa introduces this class of attack via compomise of CI. (edit: changed "still not secure" to "still not enough by itself" bc that is the point I want to make)
Going to Trusted Publishing / pipeline publishing removes the second factor that typically gates npm publish when working locally.
The story here, while it is evolving, seems to be that the attacker compromised the CI/CD pipeline, and because there is no second factor on the npm publish, they were able to steal the OIDC token and complete a publish.
Interesting, but unrelated I suppose, is that the publish job failed. So the payload that was in the malicious commit must have had a script that was able to publish itself w/ the OIDC token from the workflow.
What I want is CI publishing to still have a second factor outside of Github, while still relying on the long lived token-less Trusted Publisher model. AKA, what I want is staged publishing, so someone must go and use 2fa to promote an artifact to published on the npm side.
Otherwise, if a publish can happen only within the Github trust model, anyone who pwns either a repo admin token or gets malicious code into your pipeline can trivially complete a publish. With a true second factor outside the Github context, they can still do a lot of damage to your repo or plant malicious code, but at least they would not be able to publish without getting your second factor for the registry.
I'd like to have touch to sign from a YubiKey or similar. The whole idea of trusting the cloud to manage credentials on your behalf seems like a mistake.
”TanStack maintainer Tanner Linsley said the attacker used an orphaned commit to gain access to the workflow run that stores the OIDC token, effectively bypassing the project’s existing publishing protections. He noted that two-factor authentication is enabled for everyone on the team”
The astral blog recently pointed out how they do release gates (manual approvals on release workflows) even with trusted publishing. And sadly, all of the documentation for trusted publishing (NPM/PyPi/Rubygems) doesn't even mention this possibility, let alone defaulting to it.
I have not read that blog post. But unfortunately (and I'd love to be wrong!) it doesn't matter for if a repo admin's token gets exfiled, because if you put your gates within Github, an admin repo token is sufficient to defang all of them from the API without 2fa challenge.
That is why I want 2fa before publish at the registry, because with my gh cli token as a repo admin, an attacker can disable all the Github branch protection, rewrite my workflows, disable the required reviewers on environments (which is one method people use for 2fa for releases, have workflows run in a GH environment whcih requires approval and prevents self review), enable self review, etc etc.
Its what I call a "fox in the hen house" problem, where you have your security gates within the same trust model as you expect to get stolen (in this case, having repo admin token exfiled from my local machine)
https://docs.github.com/en/actions/how-tos/deploy/configure-... is the feature they use.
> We impose tag protection rules that prevent release tags from being created until a release deployment succeeds, with the release deployment itself being gated on a manual approval by at least one other team member. We also prevent the updating or deletion of tags, making them effectively immutable once created. On top of that we layer a branch restriction: release deployments may only be created against main, preventing an attacker from using an unrelated first-party branch to attempt to bypass our controls.
> https://astral.sh/blog/open-source-security-at-astral
From what I understand, you need a website login, and not a stolen API token to approve a deployment.
But I agree in principle - The registry should be able to enforce web-2fa. But the defaults can be safer as well.
I tested approving a deployment via API last week w/ my gh cli token (well, had claude do it while I watched). Again, I really want to be wrong about this, but my testing showed that it is indeed trivial to use the default token from my gh cli to approve via API. (repo admin scope, which I have bc I am admin on said repo)
Nothing in this link [1] proves what I said, but it is the test repo I was just conducting this on, and it was an approval gated GHA job that I had claude approve using my GH cli token
I also had claude use the same token to first reconfigure the enviornment to enable self-approves (I had configured it off manually before testing). It also put it back to self approve disabled when it was done hehe
[1] https://github.com/jonchurch/deploy-env-test/actions/runs/25...
You're right. Found the relevant docs+API calls:
https://docs.github.com/en/rest/actions/workflow-runs?apiVer...
Also for a Pending Deployment: https://docs.github.com/en/rest/actions/workflow-runs#review...
Both of these need `repo` scope, which you can avoid giving on org-level repos. For fine-grained tokens: "Deployments" repository permissions (write) is needed, which I wouldn't usually give to a token.
I was always confused at why people claimed trusted publishing would make any difference to this kind of supply chain attack.
I'm looking forward to the analysis how the attacker managed to compromise CI. I was reading through the workflow and what immediately jumped out was a cache poisoning attack. Seems plausible, given https://github.com/TanStack/config/pull/381
edit: two hard things in computer science: naming things, cache invalidation, off-by-one errors, security. something something
Almost all these recent compromises seem to involve either cache poisoning or prompt injection via untrusted variables.
Post Mortem: https://tanstack.com/blog/npm-supply-chain-compromise-postmo...
Postinstall scripts are deadly. Everyone should be using pnpm.
Crazy that an "orphan" commit pushed to a FORK(!) could trigger this (in npm clients). IMO GitHub deserves much of the blame here. A malicious fork's commits are reachable via GitHub's shared object storage at a URI indistinguishable from the legit repo. That is absolutely bonkers.
Once you run your app with the updated dependencies, that code is executed anyway. And root or non-root doesn't matter, the important stuff is available as the user running the application anyway.
How is this not a Github P0? Can anyone explain?
When I read that, I thought they must be using 'fork' wrong, and actually mean branch on the official repo, as that can't be right!?" Good lord.
they probably used the publish token in a pull-request-target workflow or something?
https://tanstack.com/blog/npm-supply-chain-compromise-postmo...
We (TanStack) just released our postmortem about this.
Reminder to secure your npm environments.
https://gajus.com/blog/3-pnpm-settings-to-protect-yourself-f...
Just a handful of settings to save a whole lot of trouble.
Wild claim that setting the minimum age to 7 days will result in me "never" getting a supply chain npm vuln.
There is a “fresh” in there
In this case it would have, because the compromised packages were pulled within 3 hours.
This sort of mitigation seems like it makes sense in the short term, but it seems like it would only work as long as most people don't do it. If everyone has this set to seven days, it will take seven days plus three hours to get things yanked, and then there will be people who will set to 14 days...
No, its still a very useful mitigation tool.
1) Package owners will often realise they've been hacked quickly, since there are releases they never authorised. This gives them plenty of time to raise the alarm and yank the packages
2. Independent security researchers and other automated vulnerability scans will still be checking the latest releases even if users aren't using them
Yes it's not a perfect defense but it would help a lot.
Isn't this article wrong about npm minumum release age. 1. The config is min-release-age. 2. For some reason they have chosen to make it days instead of minutes: https://docs.npmjs.com/cli/v11/using-npm/config#min-release-...
Completely unforced fragmentation of the dependency manager space imo
This confused me too, until I realized that the article is about pnpm, not npm (pnpm reads .npmrc for some reason, despite not having the same options as npm)
On a related note, it seems to be impossible to find the documentation of min-release-age by googling it. Very annoying.
I just set this up for npm, here's the command that worked for me:
npm config set min-release-age 7
The '7' is days. This is the only format that worked for me, just a single integer number of days.
Confirmed by trying to install the latest version of React 19.2.6 (published 5 days ago as of the time of this comment). It failed with a comment confirming that it could not find such a version published before a week ago.
And absolutely pin, pin, pin, ALL your dependencies.
If I see a package version dependency that looks like this: ^1.0.0 or even this: "*", then stop reading, pin it to a secure version immediately.
Npm's package-lock.json already handles pinning everything to exact versions, including subdependencies. Pinning exact versions in package.json doesn't affect your subdependencies.
Are you talking about in package.json? What's your threat model? That's what the lock file is for, which also pins transitive dependencies, which is just as crucial. Now what's actually insecure is if you don't commit the lockfile. and if you don't do `npm ci`.
I think `npx` might pull down new versions, too? I wish npm worked more like Elixir where updating the lock file was an explicit command, and everything else used the lock file directly.
Or help distributions do the manual process of packaging - which involves at least rudimentary security checks - so they can ship newer versions faster.
And then use distro packages.
(I'm not accepting distro fragmentation as counterargument. With containerization the distro is something you can choose. Choose one, help there, and use it everywhere.)
its so wild to have seen this advice reverse course over the past year.
it used to be that projects that pinned deps were called out as being less secure due to not being able to receive updates without a publish.
different times, different threat model I suppose
> it used to be that projects that pinned deps were called out as being less secure due to not being able to receive updates without a publish.
This is still the right advice for libraries. For security it doesn’t matter a whole lot anymore as package managers can force the transitive dependencies version, but it allows for much better transitive dependency de duplication.
For non-libraries it doesn’t matter as the exact versions get pinned in the package-lock.
I've been collecting things you can't pin:
- Python inline dependencies in PEP-0723, which you can pin with a==1.0, but can't be hash-pinned afaik.
- The bin package manager lets you pin binaries, but they aren't hash-pinned either.
- The pants build tool suggests vendoring a get-pants.sh script[0] but it downloads the latest. Even if you pass it a version, it doesn't do any checks on the version number and just installs it to ~/.local/bin
[0]: https://github.com/pantsbuild/setup/blob/gh-pages/get-pants....
I think we are at the point where everyone really needs to run each project in its own vm.
Given the recent lpe vulns docker 100% won’t cut it.
And containers were never meant primarily as a security boundary anyways
Or a vm per container, if you insist on containers. I've have a couple of relaxed weeks recently due to running everything on VMs rather than some random Kubernetes service.
Luckily, projects using more secure language ecosystems like C and C++ are spared this kind of problems :-)
No, instead the code that isn't from a dependency is what will cause you to get pwned
I think you missed the joke/sarcasm there.
It's been less than a month since I responded to a comment on a different thread arguing basically the same thing about C/C++ in a serious way. I've long since lost the ability to distinguish.
The Mini Shai-Hulud worm is actively compromising legitimate npm packages by hijacking CI/CD pipelines and stealing developer secrets. StepSecurity's OSS Package Security Feed first detected the attack in official @tanstack packages and is tracking its spread across the ecosystem in real time.
How did you guys detect it? Do you use it internally or do you monitor popular packages?
The malware uses a "prepare" hook to use bun to run the payload, an attack that ironically enough, bun is immune to. Enabling lifecycle scripts in dependencies by default in 2026 is just plain malpractice.
How likely is it that I have this installed if I'm not a JS developer? It seems like half of the programs on my work computer install their own JS runtime.
It sounds like you can check for `~/.local/bin/gh-token-monitor.sh` or if there's an extra macOS LaunchAgent (I use LaunchPad on macOS to manage my launchctl services). You can also check systemd on linux, but I'm less familiar.
related: CVE-2024-YIKES
https://news.ycombinator.com/item?id=48086082
Life imitates art
https://news.ycombinator.com/item?id=48086082#48087028
https://news.ycombinator.com/item?id=48101453
The next NotPetya will be an NPM package or Rust crate that no one has ever heard of, but everything depends on through transitive dependencies.
1. _Multiple third-party companies_ can detect these obviously malicious packages in almost-real-time
2. NPM still not only publishes them, but also keeps distributing them for anything beyond 5 minutes.
Microsoft/GitHub/NPM can only keep repeating "security is our top priority" so many times. But NPM still doesn't detect these simple attacks, and we keep having this every week.
> Please be careful when revoking tokens. It looks like the payload installs a dead-man's switch at ~/.local/bin/gh-token-monitor.sh as a systemd user service (Linux) / LaunchAgent com.user.gh-token-monitor(macOS). It polls api.github.com/user with the stolen token every 60s, and if the token is revoked (HTTP 40x), it runs rm -rf ~/. (It looks like it might also have a bunch of persistence mechanisms. I haven't studied these closely.)
Jesus, that's vindictive.
I could imagine this might also be to try cover its tracks. If it gets 40x it means it's been found, time to nuke everything it can.
At least it was only online for 1-2 hours at most, and it didn't affect react-query. But still a bunch of quite well-known packages.
This doesn't really feel sustainable, you're rolling the dice every time the dependencies are updated.
> it installs that commit's declared dependencies (which include bun) and then runs its prepare lifecycle script
Again? How have lifecycle scripts not instantly been defaulted off? Yes breaking things is bad, but come on, this keeps happening, the fix is easy, and if an *javascript* build relies of dependendlcy of dependency's pulled build time script, then it's worth paying in braincells or tokens to digure it out and fix the biold process, or lately uncover an exploit chain. This isn't even a compiled language.
If the payload couldn't execute at install time, it would at runtime? Disabling prepare scripts does not seem like an effective countermeasure.
Well at runtime one would hope they're not giving their JS app access to their home folder.
As Theo goes live…
Applying cooldowns is probably the easiest way to avoid picking up this packages. Stay safe.
TanStack? Jia Tan? Who is falling for this???
Can you explain further? TanStack has popped up in our apps and I don't know why I should not be falling for this or what exactly the "this" is that is being fallen for.
its a cult in react web dev circles. Just be glad that you never had to encounter devs who insist that everything must be on "tan" stack.
React Query is great. I’ve used his router and table component as well. IMO his stuff became popular on merit more than some cargo culting à la redux
as someone who encountered this cargo culted at a number of start ups -- I beg to differ. React Query I will always pass on. the other lesser known hits of tanstack -- won't even consider.
My decision to abandon the JS ecosystem and language entirely continues to pay off. What a mess...
I am, however, concerned that this will pwn my workplace. We don't use Tanstack but this seems self-propagating and I doubt all of our dependencies are doing enough to prevent it.
Abandon NPM in exchange for what? Cargo? Go get? Pip install?
Every package manager that does not analyze and run tests on the packages being uploaded (like Linux distros do) is vulnerable.
The community decided it's too much effort to vet code before publishing it so here we are.
(I'm not being stupid, even ten years ago there were arguments on HN about whether you should audit your dependencies)
I landed on the 'yes, you should know what code you are getting involved with' side.
> Abandon NPM in exchange for what? Cargo? Go get? Pip install?
pnpm, deno, or bun, none of which will run the malicious "prepare" hook in the first place unless specifically allowed.
Cargo is spiritually based on NPM so it's not much better.
Go Get is closer to always locking dependencies unless you explicitly upgrade them with a go get, so it's much much better in my view.
Yes, you can lock deps in NPM/Cargo/etc. but that's not the default. It is the default in Go.
In Go projects my policy for upgrading dependencies includes running full AI audit of all code changed across all dependencies, comes out to ~$200 in tokens every time but it gives those warm 'not likely to get pwned' vibes. And it comes with a nice report of likely breaking changes etc.
> comes out to ~$200 in tokens every time
BTW a curated mirror of <whatever ecosystem> packages, where every package is guaranteed to have been analyzed and tested, could be an easy sell now. Also relatively easy to create, with the help of AI. A $200 every time is less pleasant than, say, $100/mo for the entire org.
Docker does something vaguely similar for Docker images, for free though.
People are already scanning npm constantly. You can limit yourself to pre-scanned packages by setting npm's minimum release age setting to 1 or 2 days (a timeframe that all the recent high-profile malicious package versions were unpublished within).
Note to self: the test suite for vetting a package should include setting the system date some time in the future, to check if an exploit is trying to sleep long enough to defeat the age limit.
It's insane to me you spend $200 on a report you likely rarely read in detail or double check for correctness, yet you're doing it to feel good about security.
If it runs in a harness that will alert me when something dodgy is detected I'm fine to stay at that level.
I don't read it in detail because reading in detail is precisely what I delegate to the harness. The alternative is that I delegate all this trust to package managers and the maintainers which quite clearly is a bad idea.
Whether the $$ pricetag is worth it is.. relative. Also in Go you don't update all that often, really when something either breaks or there is a legitimate security reason to do so, which in deep systems software is quite infrequent.
Funnily enough for frontend NPM code our policy was to never ever upgrade and run with locked dependencies, running few years old JS deps. For internal dashboards it was perfectly fine, never missed a feature and never had a supply chain close call.
> running few years old JS deps
What do you when a critical vulnerability gets discovered and you have to update a package? How many critical/high severity vulnerabilities are you running with in production every day to avoid supply chain attacks?
> Yes, you can lock deps in NPM/Cargo/etc. but that's not the default. It is the default in Go.
How is it not the default in npm?
It is the default in both cargo and npm, but "npm install" stupidly enough still updates the lockfile, and you need "npm ci" to actually respect it. I think there's some flag to make install work sanely, but long-term I find the best approach is to use anything other than npm.
I ditched npm for yarn years ago because it had saner dependency resolution (npm's peer dependency algorithm was a constantly moving target), and now I've switched from yarn to bun because it doesn't run hooks in dependencies by default. It also helps that it installs dependencies 10x faster.
”npm install” does not update the lockfile in any current major version.
At least not if you haven’t edited your package.json manually.
Even linux was subjected to an attack in xz utils. Granted it is much harder and they have a much better auditing problem (something npm should learn from). There really isn't a silver bullet here unfortunately. The industry as a whole needs to get more serious about this.
There's no silver bullet, but getting an exploit into xz took extraordinary effort, a long time, and bespoke code, because it needed to slip under the radar of actual humans reading the code. A shai hulud-style attack won't work with any reasonable Linux distro, like it does with npm.
Exactly, the only real way to escape this madness is if we move back to "Standard Libs" where your project only depends on 1-3 core libraries. For example, .NET and Java are almost entire 'kitchen sink' ecosystems. Arguably for simple projects, Go has a fairly large standard lib.
This is exactly why I love Deno so much, it has a standard lib AND a security model that's secure by default.
Just writing the actual code that you are being paid to write
The only correct answer
Both Cargo and Go's package manager are a lot better. Can you name comparable security incidents they've had in the last 5 years?
Idk about Python, I refuse to use that language for other reasons.
It makes more sense to attack packages in NPM since it's by far the most popular package manager.
Yeah it's a dumpster fire, but I also don't think the other major ecosystems like say python's pypi are any safer structurally
There are npm supply chain exploits in the news every other day. I'm honestly surprised that something as decentralized as Go Modules is more reliable, but here we are. The fact that we're not seeing these stories about e.g. Maven is not at all surprising, given the limited need for third party libraries and the culture of careful upgrades in the Java ecosystem. If npm proponents want the ecosystem to survive, they need to demand / create better and stop making excuses.
I highly recommend enforcing a minimum dependency release age of at least a week across all package managers used at your workplace. Most package managers support it now, and it will save you from the vast majority of these attacks.
https://news.ycombinator.com/item?id=47582632
Highly recommend using the minimum release age setting, though I think a week is probably overkill. Did any of the recent supply-chain attacks have a malicious version up for more than a day?
Maybe not, but how much of that was luck? I think it's only a matter of time until a similar compromise happens but nobody notices it for a few days, better safe than sorry.
Ah shit, here we go again
Once again, Shai-Hulud wrecking havock in the Javascript and Typescript ecosystems via NPM.
One of the worst ecosystems that has been brought into the software industry and it is almost always via NPM. Not even Cargo (Rust) or go mod (Golang) get as many attacks because at least with the latter, they encourage you to use the standard library.
Both Javascript and Typescript have none and want you to import hundreds of libraries, increasing the risk of a supply chain attack.
At this point, JS and TS are considered harmful.
I don't really buy this. NPM is targeted because it's the largest attack surface with the biggest payoff for a successful attack.
Other ecosystems package managers are really no different in a lot of ways.
NPM's biggest fault is just it allows post/pre install scripts by default without user intervention.
> Both Javascript and Typescript have none and want you to import hundreds of libraries
There are plenty of very popular packages with zero dependencies like Hono or Zod. If you decide to blindly install something with hundreds of deps it's on you.
That said, I do agree the JS standard library should provide a lot more than it does now.
Python had these too, no ecosystem is safe.
I wonder whether NPM has surpassed the costs of the billion dollar mistake, null references. NPM hasn't been around as long, but the industry is much bigger today than it was when systems languages were dominant.
If cargo was as popular as npm, the same issues would surface.
The Standard C library is also very small. Even though there’s POSIX, for anything that’s not system programming, you will be using libraries.
The difference is that the usual C libraries don’t split the project into small molecules for no good reasons. You have to be as big as GTK to start splitting library in my opinion.
So when do we call out NPM as an easy supply chain vector and also Microsoft's ownership of NPM and their prioritisation of AI at any cost.
NPM is the windows of package managers right now.
People have for years. The real question is do people enjoy not putting any thought into their super convenient JavaScript stack too much to actually do anything about it. Delaying updating to new packages assuming the vulnerability will be discovered in two days or whatever is putting a knee brace on a leg that needs to be amputated. Sooner or later there will be a vulnerability good enough to not be caught in a couple days, or a zero-day damaging enough that not updating immediately is a huge risk. Assuming they won’t be in anything critical enough to disastrously compromise your stack is wishful thinking at its finest.
The part that always gets me is I tend to only install a few packages like React and maybe some kind of data access layer. But you let that recurse down a few levels and suddenly you've installed a thousand packages, some of them hopelessly obsolete, some of them for patently stupid things that are 1 line of code, etc, etc. I.E. you can't choose to be thoughtful if the main entry points into the language are all built on a pile of garbage.
Now that npm supports --before, yarn supports npmMinimumAge, and pnpm supports minimumReleaseAge, it's quite possible to stay safe and avoid acciasional bleeding-edge upgrades. Stay a couple months into the past, give testers time to look at newer releases and vet their safety (or report an exploit attempt).
npm's immaturity is arguably demonstrated by the fact it is always catching up.
Please correct me if I'm wrong but signed packages are still impractical in NPM which is why supply chain attacks still work by editing existing versions or pushing new point releases without a signature.
Or if you put all of the credentials in GitHub actions which is even more trivially exploitable through the actions marketplace because it is just git with a thin proxy, you have an even wider attack vector
--before doesn't save you globally, only min-release-age does, which is in npm since March iirc.