GhostAction campaign injects credential-stealing workflows into thousands of GitHub repos
Attackers compromised high-profile maintainer accounts to push malicious GitHub Actions that exfiltrate secrets from repositories and git history.
A massive supply chain attack known as GhostAction has compromised hundreds of GitHub accounts, injecting malicious continuous integration workflows into tens of thousands of repositories. The campaign, which escalated significantly in early October 2026, targets developer credentials by masquerading as routine security audits within popular open-source projects.
What happened
Cybersecurity researchers identified that attackers gained access to the accounts of two prominent open-source maintainers: Takashi Kitao, creator of the pyxel game engine, and Henry Wu, author of Uber’s athenadriver. Using these trusted identities, the threat actors pushed a malicious workflow file named either "security-audit.yml" or "github_actions_security.yml" into the default branches of hundreds of repositories. The injection occurred rapidly, with 318 repositories affected in just a 16-minute window on October 7, 2026.
The malicious workflow is designed to trigger on any push or manual dispatch. Once activated, it performs a deep scan of the repository, checking not only the current working tree but also the entire git history for sensitive data. It specifically looks for thirteen patterns associated with cloud providers, AI services, and package registries. The extracted credentials are then sent via plain HTTP to an attacker-controlled IP address, 193.32.204.199. This method allows the attackers to harvest secrets that may have been committed in the past and subsequently deleted from the current codebase.
As of October 9, 2026, security firm Socket reported that more than 500 GitHub accounts had committed this malicious workflow since October 7. The campaign has impacted 817 repositories across 327 users, resulting in the exfiltration of 3,325 secrets. These stolen credentials include tokens for PyPI, npm, DockerHub, AWS, Anthropic, OpenAI, and various other SaaS platforms. In some instances, such as the "kuafuai/DevOpsGPT" repository, attackers also embedded cryptocurrency mining software into Docker images.
Key details
- Attack vector: Compromised maintainer accounts were used to inject malicious GitHub Actions workflows directly into repositories.
- Malicious files: The payloads are named "security-audit.yml" or "github_actions_security.yml" and trigger on unfiltered pushes or manual dispatches.
- Data exfiltration: The workflow scans the working tree and full git history for 13 specific credential patterns, sending results to 193.32.204.199 over plain HTTP.
- Scale: Over 500 GitHub accounts have been implicated, affecting tens of thousands of repositories and exposing 3,325 secrets so far.
- Fork risk: Downstream forks, especially private ones, inherit the malicious workflow and remain at risk if GitHub Actions are enabled.
- Targeted secrets: Stolen data includes AWS keys, AI provider API keys, DockerHub tokens, and SSH private keys.
Background
GitHub Actions is a continuous integration and continuous deployment (CI/CD) platform that allows developers to automate software workflows directly within their repositories. These workflows can access "secrets," which are encrypted environment variables stored in the repository settings. Typically, these secrets include API keys, database passwords, and authentication tokens required for building and deploying software. While GitHub encrypts these secrets at rest, they are decrypted and made available to the workflow runtime during execution.
Supply chain attacks like GhostAction exploit the trust inherent in open-source ecosystems. When a well-known maintainer’s account is compromised, their contributions are implicitly trusted by downstream users and automated systems. By injecting a workflow that appears to be a legitimate security tool, attackers can bypass suspicion. The use of fetch-depth: 0 in the malicious workflow ensures that the entire history of the repository is downloaded, allowing the script to find secrets that were removed from recent commits but still exist in older versions of the code.
Why it matters
For teams that self-host software or manage their own CI/CD pipelines, this incident highlights the fragility of dependency chains. Even if your internal infrastructure is secure, relying on external open-source components introduces risk. If a library you depend on is compromised, its malicious workflows can execute in your environment if you fork the repository or use it in a way that triggers Actions. The exposure of AI provider keys is particularly concerning, as these can lead to significant financial loss through unauthorized API usage.
Furthermore, the attack demonstrates that deleting a secret from your current codebase is not sufficient to protect it. Because the malicious workflow scans the entire git history, any credential ever committed to the repository is vulnerable. This means that historical hygiene is just as critical as current security practices. For IT leads and DevOps engineers, this necessitates a review of not just active dependencies, but also the historical integrity of the repositories they interact with.
What you can do
- Scan for malicious workflows: Check all repositories for files named "security-audit.yml" or "github_actions_security.yml" added since August 31, 2026.
- Revoke and rotate credentials: If you find the malicious workflow, assume compromise. Immediately revoke all GitHub tokens, AWS keys, and API secrets associated with the affected repositories.
- Audit git history: Use tools to scan your entire git history for accidentally committed secrets, not just the current head commit.
- Review forked repositories: If you have forked any of the affected repositories, check them for the malicious workflow and disable GitHub Actions until they are cleaned.
- Enable branch protection: Restrict who can push workflow files to your default branches to prevent unauthorized modifications.
- Monitor outbound traffic: Configure network policies to detect unusual outbound HTTP requests from your CI/CD runners to unknown IP addresses.



