The GitHub Actions Credential-Stealing Campaign: What Happened and How to Protect Your Code

A malicious GitHub Actions workflow is not a piece of code sitting in a repository waiting to be discovered. It is executable code that runs automatically when certain events occur—on every push, pull request, or scheduled trigger. Once injected into a repository by a compromised maintainer account, the workflow has legitimate access to that project's secrets: API keys, deployment credentials, cloud provider tokens, and authentication materials. The attacker does not need to trick developers into running something manually. The workflow executes in the repository's CI/CD environment as a trusted process.

In the pyxel case, researchers documented how the attacker gained control of Takashi Kitao's GitHub account and used that trust to push a malicious workflow to 27 repositories. From there, the pattern likely repeated across other compromised accounts. Each workflow was designed to exfiltrate credentials during the build process—stealing secrets that projects had intentionally configured for deployment, testing, or integration with third-party services. The victims did not have to run the malicious code themselves. They only had to merge a pull request from a trusted maintainer or rely on workflows already present in their repositories.

Open-source maintainers manage projects with hundreds or thousands of dependent packages downstream. A single compromised account becomes a pivot point for lateral movement through the entire ecosystem. The attacker does not need to break into each repository individually. They only need to compromise one well-known maintainer's GitHub account, and they inherit access to all repositories under that account's control.

The pyxel project, with 18,400 stars, is widely used as a dependency in other projects. Compromising the maintainer's account meant the attacker could inject workflows not just into pyxel itself but into related projects and forks under the same account. The compromise likely went undetected for a time because pull requests and commits from a verified maintainer account appear legitimate at first glance. Code reviewers trust maintainers. CI/CD systems trust them. The attack exploits that earned trust.

Maintainers typically reuse credentials across services: email accounts, password managers, SSH keys, and GitHub personal access tokens. A single breach—a phishing email, a malware-infected development machine, or credential stuffing from an unrelated service—can hand the attacker access to the entire account. From there, the attacker operates with the maintainer's full permissions and historical reputation.

GitHub Actions workflows have built-in access to repository secrets through the `secrets` context. These are environment variables that projects define specifically for CI/CD use: AWS keys, npm tokens, container registry credentials, deployment SSH keys. A malicious workflow can read these secrets and send them to an attacker-controlled server in a single HTTP request or exfiltrate them as part of a log file that the attacker can then parse.

The attack does not require any new exploit or bypass. The workflow syntax itself, as documented by GitHub, allows a developer to write a step that reads `secrets.DEPLOY_KEY` or `secrets.REGISTRY_TOKEN` and transmits it. A malicious workflow simply does what legitimate workflows do, but with intent to steal. The CI/CD runner, running in GitHub's infrastructure or on a self-hosted runner, executes the workflow with full access to those secrets.

This is why credentials stolen this way are particularly valuable to attackers. They are fresh, active, and tied directly to production systems. A developer's stolen password might grant access to their personal account. A stolen CI/CD credential grants access to deployment infrastructure, cloud accounts, or package repositories where the project publishes builds.

According to security vendor incident reports and supply chain research, compromised maintainer accounts are one of the highest-leverage attack vectors in open-source because a single compromise can affect thousands of downstream projects simultaneously. This matters because your project's dependencies are not passive code—they are trust relationships, and breaking one breaks all the others downstream.

Law enforcement and vendor tracking data indicate that credential-stealing campaigns targeting CI/CD infrastructure have increased significantly, focusing specifically on exfiltrating deployment credentials rather than inserting obfuscated malware. This shift matters to your team because stolen credentials can be used silently for months before detection, whereas injected code often triggers security alerts.

GitHub's own security documentation warns that account compromise is one of the highest-risk scenarios for open-source projects, and GitHub Actions workflows are a known attack surface. This matters because it means the risk is well-understood among defenders, but many projects still do not implement basic mitigations.

Academic research on open-source ecosystem vulnerabilities shows that maintainer burnout, weak authentication practices, and limited security tooling across projects create structural conditions that attackers exploit. This matters because the attack is not the result of a zero-day or a sophisticated exploit—it works because fundamental security practices are inconsistent across the ecosystem.

Malicious workflows often behave differently from legitimate ones. They may export environment variables, make unexpected network requests, or include steps with unusual logging behavior. Detecting them requires a change in perspective: treat workflow files the same way you would treat any production code.

If you maintain or use repositories affected by this campaign, consider these steps:

1. Review all workflow files in your repositories (.github/workflows/*.yml) and check the commit history to see who made recent changes and when.
2. Check whether recently added workflows include steps that read `secrets.*` and immediately transmit data (via curl, wget, or environment variable exfiltration).
3. Compare workflow file timestamps against your own activity logs. If a workflow was added when you were not actively working, it is a sign of account compromise.
4. Check your GitHub account login history and active sessions. If you see logins from unfamiliar IP addresses or times, revoke all sessions and reset your credentials.
5. For every credential that could have been exposed, revoke it on the downstream service (AWS, npm, container registry, deployment SSH key, etc.) and rotate to a new one.

GitHub Actions itself does not currently require approval for workflow changes by default. Some organizations use branch protection rules and required code review to slow down malicious commits, but these mitigations are not universal.

You cannot prevent your dependencies' maintainers from being compromised, but you can reduce the damage if it happens. Start with credential scope: do not give CI/CD pipelines credentials that grant access to production systems if a build-time tool does not actually need them. Use GitHub's environment protection rules to require approval before deployments, not just before builds.

Implement pull request reviews even for maintainers on projects with multiple committers. A second pair of eyes reviewing workflow changes catches the most obvious malicious patterns. For self-hosted runners, isolate them on separate networks and rotate their credentials regularly.

For open-source project owners, enable GitHub's branch protection rules, require signed commits where feasible, and consider using GitHub's fine-grained personal access tokens instead of classic tokens. These tokens can be scoped to specific repositories and operations, limiting what a compromised token can do. Use a separate account or token for CI/CD automation, not your primary development account.

If you maintain a project, start by treating your repository's workflow files as security-critical code. The workflows that run in your CI/CD environment have the same risk profile as your production code—sometimes higher, because they run before your code is even deployed. Audit your repository's recent workflow changes and check the commit history for unexpected activity.

If you use dependencies from projects that may have been affected by this campaign, rotate any credentials that could have been exposed through their CI/CD pipelines. Check whether those projects have published security advisories or incident reports and follow their remediation guidance. The campaign demonstrates that supply chain trust is fragile, but it is not binary. You can reduce the blast radius by compartmentalizing credentials, using short-lived tokens, and monitoring what your dependencies actually do.

Source: The Hacker News