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?

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

> 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.

"pull_request_target" vs "pull_request" is also bad naming. At least give it a dangerous name so people know there's a dangerous quirk to it when reading their config.

And a labeling action which requires `pull_request_target`: https://github.com/actions/labeler#create-workflow

These types of features are not worth it and need to be removed from the marketplace.

If git in general would enforce pretending to not know about orphans, it would always need to know what you were meaning to consider the boundary, and/or you would end up waiting for useless duplicate network traffic. The fact that on GitHub, such references are visible irrespective of specified repo is not a bug, its a feature. Its the tools (including but not limited to: GitHub Actions) that cause dangerous misunderstanding in appearing to let you specify something they then never actually enforce.

specified: repo location, slightly-difficult-to-preimage hash

intended meaning: use this hash if and only if it is accessible from the default branch of that repo

actual meaning: use this hash. start looking at this location. I do not care whether it is accessible through that location by accident, by intent of merely its uploader, or by explicit and persisting intent of someone with write access to the location.

In some cases, you can also use forks to read commits from private forks[0], but GitHub considers these linked commit networks working as intended.

[0]: https://trufflesecurity.com/blog/anyone-can-access-deleted-a...

This is a very worthy article. I have an impression that I've read it before 2024, but maybe that was a different article describing the same mess with how github exposes private repos.

Because GitHub only cares about AI.

And maintaining high level of service availability!

With zero down time!

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.

Yes, but the exploit was with Github Actions not something that pnpm really prevented.

I think it was an afterthought in the design. CI cache should be scoped per-user, or at least per-group.

If a workflow run by a maintainer (with access to secrets) can pull a cache tarball uploaded by a random user on GitHub, then it’s a security black hole. More incidents like this are inevitable.

Those are two different attack vectors. The exploit they used on Github Actions would work for either npm or pnpm. But the replication part using postinstall scripts, once it is installed on another machine, would be stopped by pnpm.

What I'm curious about is: how can you poison the cache in CI, if the lockfile has an integrity hash for each package?

Did the incoming PR modify pnpm-lock.yaml? If so, that would an obvious thing to disallow in any open-source project and require maintainer oversight.

From what I understand they've wrote the poisoned payload directly to the file system where they've expected another package exists. You only need to know what hash is going to be created.

How do you know the hash in advance?

Perhaps pnpm trusts the local store?

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.

You should sandbox where you run the code. The thing is, it's very hard for me to know how to sandbox an install script, but it's actually quite easy (and my responsibility as the app dev) to know how to sandbox my tests/ application.