alt Hacker NewsThe 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.
Replies
maxloh • today at 6:23 AM
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 • today at 3:46 AM
Yes, but the exploit was with Github Actions not something that pnpm really prevented.
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.