Join the discussion
Write your take first — we'll ask for email only when you're ready to publish.
- Hacker News
- Why do we do all these efforts making our build systems hermetic and we end up just using a global mutable cache across branches where the caller picks the key? Failure of industry as a whole. Actually insane.by arianvanp
- Wow. Another huge package got compromised. I'm going to repost my PSA[0][1] that I posted after Axios and LiteLLM were compromised. The bit about lifecycle scripts apply too:
PSA: npm/bun/pnpm/uv now all support setting a minimum release age for packages. I also have `ignore-scripts=true` in my ~/.npmrc. Based on the analysis, that alone would have mitigated the vulnerability. bun and pnpm do not execute lifecycle scripts by default. Here's how to set global configs to set min release age to 7 days: ~/.config/uv/uv.toml exclude-newer = "7 days"
If you do need to override the global setting, you can do so with a CLI flag:~/.npmrc min-release-age=7 # days ignore-scripts=true ~/Library/Preferences/pnpm/rc minimum-release-age=10080 # minutes ~/.bunfig.toml [install] minimumReleaseAge = 604800 # seconds
I should add one extra note. There seems to be some concern that the mass adoption of dependency cooldowns will lead to vulnerabilities being caught later, or that using dependency cooldowns is some sort of free-riding. I disagree with that. What you're trading by using dep cooldowns is time preference. Some people will always have a higher time preference than you.npm install <package> --min-release-age 0 pnpm add <package> --minimum-release-age 0 uv add <package> --exclude-newer "0 days" bun add <package> --minimum-release-age 0by postalcoder - Those should be defaults in npm.by butz
- pip also supports relative dependency cooldowns starting in v26.1:
~/.config/pip/pip.conf
[install] uploaded-prior-to = P3D
by SethMLarson - I hate to spam this but Ive seen this misconception on bun repeatedly in each of these incident threads. It should really be noted that bun _does_ run lifecycle scripts for the top 500 most popular packages by default. You can opt out of this but its not the default config. Its much better than the npm strategy but I think it would be much better if there was a way to explicitly acknowledge you want this default whitelist applied (eg scriptPolicy = allow, deny, or allow popular only)by JamesSwift
- +1 to this. I am glad to have enabled these back in March before the last two waves hit. In addition to that, make sure you have a lockfile committed to your repo and be mindful of adding new dependencies. Use `pnpm install --frozen-lockfile` to avoid surprises.
If you don't have min-release-age set, remember that you can still pull in affected packages via indirect dependencies.
And ideally pin your package manager version too.
by ricardobeat - The last time I looked at this, using ignore-scripts = true with npm results in "npm run xyz" getting blocked as well, is that still the case?by 63stack
- 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
by getcrunk - it's not going to help if you share a cache across security boundaries. That is what happened here and seems to be driving a spate of github action related problems.by zmmmmm
- 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.by 9cb14c1ec0
- Devcontainers (I know it's not a full VM, but it's most prominent version of this "isolated development environment" concept) wouldn't fully protect you against this. Github credentials are automatically pulled into the container. If you are using other cloud services that need to be accessed within the container, this cred stealer will grab their creds too.
It would limit the blast radius, which at least is an improvement.
by omcnoe - Luckily, projects using more secure language ecosystems like C and C++ are spared this kind of problems :-)by einpoklum
- QubesOS had the right idea. You want layers and layers of security, with multiple VMs at the root.by Gigachad
- So in summary:
- a writable shared global cache is made available to PRs opened from forks by randomers.
- that cache is reused in the deploy pipeline
- deploys can be made with a single authentication factor, stored on the CI server
- the repository apparently does nothing to check for malicious deploys, delegating that to 3rd parties to do after the code is in the wild.
- by default the package manager runs random code when a package is updated
What a world we live in.
by padjo - And the gotcha has been known about since 2014:
> This is the class of attack documented by Adnan Khan in 2024. It's not a TanStack-specific bug; it's a known GitHub Actions design issue that requires conscious mitigation.
While it seems the maintainers kinda went-out-of-their way to enable this - GitHub could easily have at least turned of cache-sharing between fork jobs and the main jobs...
by olejorgenb - > Unpublish was unavailable for nearly all affected packages because of npm's "no unpublish if dependents exist" policy. We have to rely on npm security to pull tarballs server-side, which adds hours of delay during which malicious tarballs remain installable
Per https://docs.npmjs.com/policies/unpublish:
> If your package does not meet the unpublish policy criteria, we recommend deprecating the package. This allows the package to be downloaded but publishes a clear warning message (that you get to write) every time the package is downloaded, and on the package's npmjs.com page. Users will know that you do not recommend they use the package, but if they are depending on it their builds will not break. We consider this a good compromise between reliability and author control.
I don't even know what to say here, npm.
by ezekg - Some sort of middle ground should have been found where the unpublished package is still accessible as an archive or something. I'd much rather get my package broken than get hackedby nabogh
- The baffling part is why it takes hours for the npm security team to unpublish packages that contain malware, as attested by multiple independent sources? That should be able to happen in minutes.by igregoryca
- I do not envy the position the npm team are in. They removed the ability to unpublish packages as a response to the left-pad incident[1] because it wasn't desirable for individual developers to break downstream dependencies by pulling their package maliciously.
Of course the side effect is that now it's much harder to pull packages for legitimate reasons :/
by sophiabits - Am I understanding this attack vector correctly: Did tanstack have anything misconfigured on their github or make any mistakes that led to this happening? This is the second time, at least, the github actions cache has been seemingly detrimental to massive and widespread supply chain compromise; what is going on over there?by 827a
- At least my naive brain wonders if blocking force pushes to main would have stopped this as it is a setting in Github these days, unless I am misunderstanding the final attack vector since it seems it was force pushed.by corvad
- The fundamental mistake here seems to have been not fully understanding the threat model of the pull_request_target action trigger.
pull_request_target jobs run in response to various events related to a pull request opened against your repo from a fork (e.g, someone opens a new PR or updates an existing one). Unlike pull_request jobs, which are read-only by default, pull_request_target jobs have read/write permissions.
The broader permissions of pull_request_target are supposed to be mitigated by the fact that pull_request_target jobs run in a checkout of your current default branch rather than on a checkout of the opened PR. For example, if someone opens a PR from some branch, pull_request_target runs on `main`, not on the new branch. The compromised action, however, checked out the source code of the PR to run a benchmark task, which resulted in running malicious attacker-controlled code in a context that had sensitive credentials.
The GHA docs warn about this risk specifically:
> Running untrusted code on the pull_request_target trigger may lead to security vulnerabilities. These vulnerabilities include cache poisoning and granting unintended access to write privileges or secrets.
They also further link to a post from 2021 about this specific problem: https://securitylab.github.com/resources/github-actions-prev.... That post opens with:
> TL;DR: Combining pull_request_target workflow trigger with an explicit checkout of an untrusted PR is a dangerous practice that may lead to repository compromise.
The workflow authors presumably thought this was safe because they had a block setting permissions.contents: read, but that block only affects the permissions for GITHUB_TOKEN, which is not the token used to interact with the cache. This seems like the biggest oversight in the existing GHA documentation/api (beyond the general unsafety of having pull_request_target at all). Someone could (and presumably did!) see that block and think "this job runs with read-only permissions", which wasn't actually true here.
- https://tanstack.com/blog/npm-supply-chain-compromise-postmo...
We (TanStack) just released our postmortem about this.
by crutchcorn - thank you for maintaining this inspiring ecosystem.by swyx
- (We changed the URL from https://github.com/TanStack/router/issues/7383 to that above.)by dang
- I didn't see a key section of a COE: "What are we doing to make sure this can't happen again?"
Apologies if I missed it. There's some discussion of things under what could have gone better, but prevention is key, and the reports not done without it.
by ____tom____ - @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.
- 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.
by chrisweekly - 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.
- It's extremely rare that I install a dependency without executing code from it shortly after. I think postinstall scripts are unfortunate and an anti-pattern, but I don't realistically think that their removal would do very much to avoid these kinds of attacks.by mort96