PyPI Token Exfiltration Campaign via GitHub Actions Workflows
4 points by ubernostrum
4 points by ubernostrum
This occurred because people were storing long-lived PyPI access tokens in GitHub for use in publishing workflows, and accidentally leaked or exposed those tokens.
As a reminder, the preferred approach is the Trusted Publishing flow, whose entire point is to let you trust a third-party CI/CD provider with publishing permissions, because it’s built around issuing an on-demand, short-lived, narrow-scoped access token. That way, even if you do manage to accidentally leak it, it expires so quickly an attacker is limited in how much damage they can do (if they can even react quickly enough to do anything at all).
Unfortunately this doesn’t work with smaller forges/CI services, such as codeberg.
If you’re self-hosting your own instance of one of those you don’t need Trusted Publishing (since the point of TP is to give you confidence about trusting a third party with package publishing credentials).
For a SaaS CI/CD offering, there’s documentation on how to get added as a supported option. They’ve added several since the initial launch of Trusted Publishing.
As is the feature needs to be added to forgejo following which codeberg might be motivated into handling the admin side.
Took me some reading to figure out what actually happened! It seems to be a reverberation of a previous attack, where GitHub credentials were stolen. As a result, attacker, impersonating a maintainer with commit access, just added a commit to the master branch with secrets exfiltrating workflow, which naturally had access to all secrets.