GhostAction campaign targets GitHub CI/CD secrets via compromised accounts

A renewed wave of the GhostAction supply chain attack compromised approximately 1,900 GitHub user accounts between October 8 and 9, 2026. Security researchers at GitGuardian observed the threat actors targeting more than 30,000 repositories across 3,000 users and organizations in an effort to extract sensitive credentials from continuous integration environments.

What happened

The campaign, first identified in September 2025, relies on attackers gaining write access to legitimate developer repositories. They achieve this by using stolen Personal Access Tokens (PATs) or credentials harvested from infostealer malware logs. Once inside, the attackers inject malicious GitHub Actions workflow files into the targeted repositories. These files are often disguised with deceptive names such as "security-audit.yml" or "github_actions_security.yml" to avoid immediate suspicion during casual code reviews.

The primary objective is the large-scale theft of secrets stored in CI/CD pipelines. This includes cloud provider credentials, package registry tokens for services like npm, PyPI, and DockerHub, and API keys for artificial intelligence providers. The recent spike in activity represents a significant escalation, with the attackers attempting to extract 3,174 secrets from public repositories. Gaetan Ferry and Guillaume Valadon from GitGuardian noted that the compromise of 1,900 accounts was the direct cause of this widespread attempt.

This new phase of GhostAction appears more experimental and manual than previous iterations. The payload has evolved through multiple versions since August 31, 2026. The first version introduced a feature to scan git history for secrets, using regular expressions to identify AWS key IDs, GitHub and GitLab tokens, and other cloud API keys. Subsequent variants improved this capability by capturing context around AWS key IDs to pair them with their corresponding secret access keys, increasing the likelihood that the stolen data would be usable.

Key details

• Scale of impact: The October 8-9 spike targeted over 30,000 repositories belonging to 3,000 users and organizations.
• Account compromise: Approximately 1,900 GitHub accounts were compromised using stolen PATs or credentials from infostealer logs.
• Secrets targeted: Attackers attempted to extract 3,174 secrets, including cloud credentials, package tokens, and AI API keys.
• Payload evolution: The malicious workflow evolved to include git history scanning, with later versions capturing context around AWS keys to facilitate full credential theft.
• Deployment method: Malicious workflows were pushed under deceptive names like "security-audit.yml" to blend in with legitimate maintenance tasks.
• Mitigation timing: GitHub began preventing the malicious workflow from running on October 9, stopping subsequent waves on October 10 and 12 from extracting new secrets.

Background

GitHub Actions is a popular automation platform that allows developers to define workflows for building, testing, and deploying code directly within their repositories. These workflows often require access to sensitive information, such as database passwords or cloud service keys, which are stored as "secrets" within the repository settings. While convenient, this centralization makes CI/CD pipelines a high-value target for attackers. If an attacker can modify the workflow definition, they can execute scripts that exfiltrate these secrets to external servers.

Supply chain attacks like GhostAction exploit the trust inherent in software development ecosystems. By compromising a single developer account, attackers can propagate malicious code to every project that person maintains. This is particularly dangerous because the malicious code originates from a trusted source, making it harder for automated security tools or peer reviewers to detect. The use of infostealer malware to harvest initial credentials highlights the importance of endpoint security alongside platform-specific protections.

Why it matters

For teams that manage their own software infrastructure, this incident underscores the fragility of credential management in CI/CD pipelines. Many organizations rely on long-lived secrets that are rarely rotated. The fact that a subset of victims in this new wave had been compromised in previous attacks suggests that attackers are banking on unrotated secrets remaining valid. If your team does not regularly rotate API keys and tokens, a single breach can have long-lasting consequences, allowing attackers to maintain access even after the initial vulnerability is patched.

Furthermore, the evolution of the GhostAction payload demonstrates that attackers are actively adapting to defensive measures. The addition of git history scanning means that simply removing a secret from the current codebase is insufficient if it exists in the commit history. Teams must assume that any secret ever committed to a repository is potentially exposed. This requires a shift in strategy from reactive cleanup to proactive secret management, including the use of short-lived tokens and rigorous access controls for repository modifications.

What you can do

• Rotate all CI/CD secrets immediately: Assume any secret stored in a GitHub repository may have been exposed if your account was part of the affected user base or if you use similar patterns.
• Enable branch protection rules: Require pull request reviews and status checks before merging changes to main branches to prevent unauthorized workflow modifications.
• Audit git history for secrets: Use tools to scan your entire commit history for leaked credentials, not just the current head of the branch.
• Implement least-privilege access: Restrict who can push workflow files and manage secrets in your repositories, reducing the blast radius of a compromised account.
• Use short-lived credentials: Where possible, replace long-lived API keys with temporary tokens that expire automatically, limiting the window of opportunity for attackers.
• Monitor for unusual workflow activity: Set up alerts for changes to workflow files, especially those with names resembling security audits or maintenance tasks.