GitHub Actions Credential-Stealing Workflows: The Supply Chain Attack Explained

The campaign exploited a vulnerability in the trust model of open-source development: maintainers with legitimate access to popular repositories. Attackers compromised at least two high-profile accounts, including that of Takashi Kitao, author of the widely-used pyxel game engine (18,400 stars on GitHub). Once in control, the attackers pushed malicious GitHub Actions workflow files into over 340 repositories. The workflow files appeared legitimate at first glance because they were committed from verified maintainer accounts, bypassing the initial skepticism that would greet a workflow from an unknown contributor. The injected workflows ran during pull requests and pushes, executing arbitrary code with access to the repository's secrets and environment variables.

GitHub Actions workflows are configuration files (.yml files in the .github/workflows directory) that automate tasks like testing, building and deploying code. They run automatically when triggered by repository events, and they have legitimate access to the repository's stored secrets: API keys, deployment credentials, OAuth tokens and database passwords. An attacker who controls a workflow has a direct path to these credentials. In the compromised repositories, the malicious workflows silently exfiltrated secrets to attacker-controlled servers, giving the threat actors credentials they could then use to access production systems, compromise downstream services or sell on the dark web. The attack was particularly effective because the workflows were committed by trusted accounts; most developers don't review the internals of a maintainer's CI/CD pipeline unless something breaks.

This campaign reveals why attackers focus on open-source maintainers. A single compromised account with write access to a popular library gives attackers access to the machines of thousands of developers who depend on that library, plus their organizations' internal systems. The attacker didn't need to compromise 340 separate systems; they compromised two maintainer accounts and let the repository network do the rest. Any developer or CI/CD system that pulled code from an infected repository during the window of compromise would have had the malicious workflow present in their local clone or would have executed it during a build. This type of attack bypasses perimeter security, endpoint detection and network monitoring because the malicious code arrives in the supply chain as legitimate source code, not as an external intrusion.

Most organizations and individual developers do not regularly audit the GitHub Actions workflows in their dependencies. Workflows are often hidden in subdirectories (.github/workflows) and don't appear in a typical code review; a developer pulling a new commit might see changes to source code but not notice that a workflow was added or modified. Secrets stored in GitHub are masked in logs, but that masking is not perfect, and attackers can exfiltrate them through DNS queries, webhook callbacks or side-channel communication that doesn't log the credential itself. StepSecurity and other researchers discovered the campaign through monitoring for suspicious workflow patterns and outbound credential transmission, not through standard alerts. Many smaller teams lack the tooling to detect this class of attack in real time.

According to incident reports and security research into GitHub Actions abuse, malicious workflows have become a recurring vector in open-source compromise (security-vendor incident reports show a steady increase in GitHub-based supply chain attacks over the past two years). The attack demonstrates that repository access control alone is insufficient; an attacker with commit rights can inject code that runs with secrets access. This matters because it shows that credential theft is now a routine outcome of account compromise, not a secondary risk. GitHub's security model assumes that if you own a repository account, you should be able to add workflows and that those workflows deserve access to the repository's stored secrets. But this trust model breaks down when accounts are compromised through phishing, password reuse or credential stuffing. Finally, the scale of this campaign (340 repositories from two compromised accounts) suggests that many affected developers may not even know their repositories or CI/CD systems were infected if the malicious workflow was later removed by the maintainer or GitHub itself.

If you maintain or depend on open-source projects, auditing your GitHub Actions workflows is no longer optional.

1. Navigate to the .github/workflows directory in each of your repositories.
2. Review the commit history of each workflow file for unexpected changes or commits from unusual times.
3. Check for workflows that make outbound network calls to unfamiliar domains or that export secrets to environment variables.
4. Look for workflows that clone repositories from non-standard sources or that run scripts from URLs.
5. Compare the workflow versions in your local branches against the remote main branch to catch deletions or rollbacks.
6. Rotate any secrets that were stored in repositories affected by this campaign, even if the malicious workflow has been removed.
7. Enable branch protection rules that require code review and approval for workflow file changes.
8. Consider using GitHub's token permissions feature to restrict what workflows can access.

The broader lesson is that open-source security is a shared responsibility. Maintainers should treat their GitHub accounts with the same rigor as production credentials: enable multi-factor authentication, use SSH keys instead of HTTPS tokens, and audit which machines have repository write access. Organizations that depend on open-source code should scan their dependency trees for repositories with unusual activity, maintain an inventory of which external workflows are running in their build pipelines and alert on unexpected credentials being requested by CI/CD processes. Developers should not assume that a workflow is safe just because it was committed by a maintainer; workflows should be reviewed in pull requests like any other code change. Tools like Dependabot, SLSA provenance verification and Software Bill of Materials (SBOM) generation can help, but they are not substitutes for active monitoring and rotation of secrets.

Credential theft via compromised GitHub Actions workflows is not a hypothetical risk; it is an active, scalable attack that leverages the trust dynamics of open-source development. The fact that over 340 repositories were infected from just two accounts shows how efficiently attackers can distribute malicious code when they control a trusted distribution channel. The attack also illustrates why secrets rotation, access reviews and workflow auditing must become routine practices, not afterthoughts. Start today by listing all the GitHub repositories you own or depend on, then checking the .github/workflows directory for any workflows you do not recognize or that have been recently modified. If you find something suspicious, treat it as a potential breach: rotate affected credentials immediately and investigate whether the secrets were accessed.

Source: The Hacker News