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.

▲

fabian2k 4 hours ago | parent | next [-]

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.

	▲	an hour ago \| parent [-]
		[deleted]

▲

jonchurch_ 2 hours ago | parent | prev | next [-]

The compromised action here was using pnpm.

They poisoned the github action cache, which was caching the pnpm store. The chain required pull_request_target on the job to check bundle size, which had cache access and poisoned the main repo’s cache

The malicious package that was publisjed will compromise local machines its installed in via the prepare script, though.

▲

yetanotherjosh 3 hours ago | parent | prev [-]

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.

▲

ZeWaka 3 hours ago | parent [-]

they probably used the publish token in a pull-request-target workflow or something?

▲

ghost_pepper 3 hours ago | parent [-]

yes, they used pull_request_target for a benchmarking suite. github has a huge warning saying to never use pull_request_target to run user code, but this is just going to keep happening

	▲	riknos314 2 hours ago \| parent [-]
		> github has a huge warning saying to never use pull_request_target to run user code This is an area where documentation is necessary but not sufficient. Github needs to add some form of automated screening mechanism to either prevent this usage, or at the very least quickly flag usages that might be dangerous.