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

Appreciate the tanstack postmortem, however the security issue as far as the rest of the npm ecosystem goes is still an ongoing concern, correct?

Is there evidence that any downstream packages that may have pulled/included tanstack packages should be considered safe?

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.

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.

So how many supply chain attacks do we need to actually change things? Feels like I read about new supply chain attacks every day at this point.

I think biggest concern here was cache poisoning.

Well, one of simplest mitigation is that `pull_request_target` jobs shouldn't have access to write to cache, they can read for performance, but not write.

To extrapolate rule, the `pull_request_target` shouldn't have any ways to invoke external side effects.

In most strict scenario, they shouldn't have access to network at all ... or only to GET <safeUrl> - where safeUrls are somehow vetted previously on main, derived from yarn.locks and similar manifests. Pita to setup, no wonder nobody does that.

> it's a known GitHub Actions design issue that requires conscious mitigation.

Okay it's a security issue, but just mitigate it as we won't fix it.

In a recent comment people asked me how come GitHub Action isn't a positive added feature since MS acquisition.

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"

  ~/.npmrc 
  min-release-age=7 # days
  ignore-scripts=true
  
  ~/Library/Preferences/pnpm/rc
  minimum-release-age=10080 # minutes
  
  ~/.bunfig.toml
  [install]
  minimumReleaseAge = 604800 # seconds

If you do need to override the global setting, you can do so with a CLI flag:

  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 0

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.

0: https://news.ycombinator.com/item?id=47582220

1: https://news.ycombinator.com/item?id=47513932

  Note that commands explicitly intended to run a particular script, such as 
  npm start, npm stop, npm restart, npm test, and npm run-script will still
  run their intended script if ignore-scripts is set, but they will not 
  run any pre- or post-scripts.

LLM probably designed the attack, LLM analyzes the attack and produces the postmortem.

Interesting days.

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.