[jonchurch_]

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.

[ricardobeat]

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.

[Yokohiii]

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.

[KajMagnus]

How do you know the hash in advance?

[pas]

Perhaps pnpm trusts the local store?

[maxloh]

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.

[corvad]

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