GitHub Actions: credential theft in thousands of repositories

If your company has code on GitHub and uses Actions to automate tests or deployments, this news affects you directly. Security researchers have documented an active credential theft campaign that has managed to inject a malicious workflow into more than 340 repositories. The vector was not a GitHub vulnerability, but rather the compromise of two maintainer accounts of high-profile open source projects.

According to the analysis published by The Hacker News, one of those accounts belongs to Takashi Kitao, author of the game engine pyxel, a project with more than 18,400 stars. From that account, the attacker pushed a malicious workflow to 27 repositories starting at 13:20 UTC. The other compromised account was used to extend the same pattern to a much larger number of repositories. The result: a huge attack surface, because any project that inherits or reuses those workflows can execute unwanted code on its continuous integration infrastructure.

What exactly is stolen

GitHub Actions workflows are YAML files that run on GitHub-hosted runners or on your own infrastructure. To work, they often need secrets: deployment tokens, API keys, container registry credentials, or cloud access keys. A tampered workflow can read those environment variables and exfiltrate them to an external server without anyone reviewing the code at a glance.

The potential damage goes beyond the affected repository. If the stolen token has permissions over other repositories in the organization, the attacker can move laterally, modify code, publish fake versions, or even access production environments. In an SME, where the same account often concentrates permissions for several projects, the impact can be disproportionate.

Why this matters to an SME

It is tempting to think that this only affects large open source projects. It is not so. Many SMEs use GitHub Actions for everyday tasks: running tests, building Docker images, deploying to staging, or syncing documentation. And many do so by copying workflows from public repositories without auditing every line. That habit, combined with broad permissions and long-lived secrets, is exactly what this campaign exploits.

Moreover, the attack pattern is silent: there is no flashy exploit, but rather a change in a configuration file that runs on the next push. If no one reviews the modifications in .github/workflows, the theft can go unnoticed for days. It is the same logic we already saw in the risk of AI agents that inherit credentials: automation amplifies the reach of a leaked secret.

Concrete recommendations for your team

You do not need to dismantle your CI/CD. You need to treat it as part of the attack surface. These are the measures we recommend at ForgeNEX:

1. Audit who can modify workflows. Review your organization's permissions on GitHub. Not everyone needs write access to the main branch or to the workflows folder.
2. Set the permissions of the GITHUB_TOKEN. By default it can be too broad. Limit it to the minimum necessary per repository and per job.
3. Use protected environments and manual approvals for deployments that touch production. A malicious workflow should not be able to reach production without human review.
4. Rotate secrets and use OIDC instead of long-lived static credentials whenever your cloud provider allows it.
5. Review changes in .github/workflows as if they were production code. A diff in a YAML can be as critical as a change in business logic.
6. Enable security alerts and review Actions execution logs. A workflow that triggers at an odd hour or contacts an unknown domain is a warning sign.

The campaign also reminds us of something we often repeat: security cannot lag behind deployment speed. If your team adopts AI and automation at a good pace, credential and permission review must keep the same pace. It is not about slowing down, but about knowing what each piece of your pipeline can touch.

A workflow is code that runs with your secrets. Treat it as such.

At ForgeNEX we help SMEs review their integration and deployment chain, from secret management to permission configuration on GitHub. If you do not know which workflows run in your organization or with which credentials, that is the first point worth reviewing this week.

Source: The Hacker News. Analysis and adaptation: ForgeNEX.