The GitHub Actions Credential-Stealing Campaign: How Attackers Compromised 340+ Repositories

Researchers at StepSecurity disclosed that attackers compromised the GitHub account of Takashi Kitao, creator of the 18,400-star pyxel game engine, and used it to push malicious workflows into 27 repositories starting on a specific date. The attacker then moved to at least one other high-profile maintainer account, amplifying the damage across the open-source ecosystem. In total, the campaign infected over 340 repositories with workflows designed to harvest credentials. The attackers chose their targets strategically: popular projects with large numbers of forks and dependents, ensuring maximum downstream impact on projects that imported these repositories as dependencies.

The malicious workflows were designed to execute silently during normal CI/CD runs. They captured secrets, API tokens and environment variables that developers had stored in GitHub Actions secrets, and exfiltrated them to attacker-controlled servers. Because GitHub Actions are deeply integrated into most developers' release pipelines, compromised workflows ran with full access to repository write permissions, deployment credentials and third-party service tokens.

The exact method by which the attackers obtained credentials for these high-profile accounts has not been fully disclosed, but the likely vectors include credential reuse across platforms, phishing targeting maintainers, or exploitation of authentication weaknesses on related services. Open-source maintainers are frequently targets because their accounts unlock access to widely-trusted code repositories that tens of thousands of downstream projects depend on. A single compromised maintainer account becomes a pivot point for distributing malware at scale.

One critical factor: maintainer accounts often reuse passwords or have weaker multi-factor authentication (MFA) configurations than enterprise environments demand. The attacker may also have obtained credentials via a data breach on an unrelated platform that the maintainer reused for GitHub. Once inside, the attacker had the privileges to create and modify workflows without triggering immediate alerts to other repository maintainers or watchers.

GitHub Actions workflows are YAML-formatted automation files stored in the `.github/workflows/` directory of a repository. They define tasks that run automatically on events like pushes, pull requests or scheduled intervals. A malicious workflow can execute arbitrary code with access to all secrets stored in the repository's Actions environment. The attacker's workflow files were designed to blend in visually with legitimate CI/CD jobs, running credential extraction in the background while normal build and test processes continued.

The stolen credentials typically included:

• GitHub personal access tokens (PATs)
• Deploy keys for SSH access
• Third-party API keys (for cloud providers, container registries, monitoring services)
• OAuth tokens for external services
• Encryption keys and signing certificates

Once exfiltrated, these credentials become keys to further compromise: attackers can fork additional repositories, inject code into production deployments, or access cloud infrastructure credentials that developers had stored as secrets.

The attack succeeded because of a fundamental asymmetry in open-source trust: developers trust code from popular, well-established maintainers without reviewing every workflow change, and forked repositories often inherit workflows from their upstream sources. When a maintainer account is compromised, that trust relationship becomes a liability. Developers monitoring their own repository activity may not notice new workflows added to dependencies they've already imported. The attack also exploited the fact that GitHub Actions workflows can run on every single push or pull request, meaning the malicious code executed thousands of times before anyone noticed.

Furthermore, many developers do not regularly audit the workflows in their repository dependencies. Workflow files are often treated as "part of the repository" rather than executable code that deserves security scrutiny. This creates a blind spot: a malicious workflow can sit dormant in a forked repository for weeks before the downstream project pulls in the latest upstream changes.

According to security vendor incident reports and Tor Project research into software distribution attacks, credential-harvesting campaigns targeting open-source infrastructure have become routine. The attack surface is enormous: with millions of repositories on GitHub and thousands of widely-used projects, a single compromised maintainer account can affect millions of developers downstream. Law-enforcement and industry reports indicate that attackers prioritize open-source projects because the lack of central security oversight means compromises can persist longer before detection. This matters to ordinary developers because a vulnerability in a project you depend on can silently expose your API keys and deployment credentials without any warning.

The incident also illustrates how GitHub's model of rapid, automated deployment can become a liability when workflows are not treated as code. Unlike traditional pull request reviews that might catch suspicious code additions, workflow file changes sometimes slip through without scrutiny, especially in large organizations where multiple people have push access.

If you maintain a GitHub repository or depend on open-source projects, take these steps to reduce your exposure:

1. Enable branch protection rules and require pull request reviews before workflow changes are merged
2. Use GitHub's workflow approval feature to require manual approval for new or modified workflows
3. Rotate all secrets stored in GitHub Actions, especially deploy keys and cloud provider credentials
4. Audit all workflows in your repository and any forks you maintain, paying special attention to recent changes
5. Enable GitHub's secret scanning feature to detect exposed credentials before they cause damage
6. Use signed commits and require commit signature verification to prevent attackers from pushing code without a cryptographic key
7. Review the maintainer accounts that have write access to your repository and remove unnecessary permissions
8. Monitor GitHub's security audit log for unusual activity, such as unexpected workflow additions or secrets access

For maintainers of popular projects, consider using separate, restricted accounts for routine maintenance and reserve admin credentials for rare, high-risk operations. Store admin credentials offline or in a hardware security key, and use them only when absolutely necessary.

What is a GitHub Actions workflow?

A GitHub Actions workflow is an automated CI/CD file (written in YAML) stored in your repository that runs code or scripts in response to repository events, such as a push or pull request. Workflows execute on GitHub-hosted or self-hosted runners and have access to repository secrets and permissions.

How do I check if my repository has been affected?

Review the `.github/workflows/` directory in your repository and examine the commit history of workflow files. Look for workflows you do not recognize or recent changes by accounts you do not trust. Cross-reference the commit date with the attack timeline disclosed in security announcements from StepSecurity or GitHub.

Can GitHub Actions workflows access my private credentials?

Yes. Any workflow in your repository can access secrets stored in the GitHub Actions environment, including deploy keys, API tokens and environment variables marked as secrets. This is why maintainer account compromise is so dangerous: a malicious workflow can exfiltrate these credentials with a single command.

Should I stop using GitHub Actions because of this attack?

No. GitHub Actions is secure if used correctly. The attack succeeded because of compromised maintainer credentials, not a flaw in GitHub Actions itself. Use the protection steps listed above, such as branch protection rules, workflow approval, and regular audits of your workflows and access controls.

What should I do if my GitHub account was compromised?

Change your password immediately, enable or strengthen two-factor authentication, rotate all personal access tokens, and review your account activity log. If your account has push access to shared repositories, notify the repository owners so they can audit workflows and audit the commit history.

Source: The Hacker News