GhostAction campaign targets 30,000 GitHub repositories

GhostAction expands its GitHub supply-chain campaign

The GhostAction credential-theft campaign targeted more than 30,000 GitHub repositories across 3,000 users and organizations on October 8 and 9, 2026. GitGuardian said the activity followed the compromise of about 1,900 GitHub user accounts and attempted to extract 3,174 secrets from public repositories’ continuous-integration environments.

GhostAction is a supply-chain attack against developer infrastructure on GitHub. First identified in September 2025, the campaign relies on compromised legitimate developer accounts to insert malicious GitHub Actions automation workflows into repositories.

Attackers have obtained repository write access through stolen Personal Access Tokens or credentials collected from infostealer logs and dumps. With a hijacked maintainer account, they can push workflow files under misleading names such as security-audit.yml and github_actions_security.yml.

Workflow files seek CI/CD and cloud credentials

The campaign is designed to steal secrets available to CI/CD jobs, including cloud credentials, package-registry tokens for npm, PyPI and DockerHub, and API keys for AI providers. A new wave observed from August 31 was more experimental and manual than earlier activity, with the payload changing over time, GitGuardian said.

An early version of the new payload added secret scanning of Git history. As Socket and StepSecurity outlined, its detection expressions cover AWS key IDs, GitHub and GitLab tokens, AI-related secrets and cloud API keys. A later version captures roughly two lines of surrounding context for each AWS key-ID match, helping associate a key ID with its corresponding secret access key.

The final identified variant can retrieve that secret context during the Git-history scan. This progression matters because exposed credentials may persist in old commits even when they are absent from a repository’s current files.

GitHub stopped later workflow executions

GitGuardian said the payload was rolled out in stages: it first reached 160 previously observed victims, then was pushed 20 minutes later to 28,000 new repositories between October 8 and 9. Further waves using the same payload appeared on October 10 and October 12.

GitHub began preventing the malicious workflow from running on October 9, so those later waves could not extract secrets. GitGuardian also found that some victims in the latest burst had been compromised during the September 2025 and August 2026 waves, indicating that unrotated secrets remained useful to the attackers.

For businesses using GitHub Actions, the practical implication is to review workflow changes and repository write access, rotate exposed or long-lived credentials, and limit the permissions available to automation tokens and CI/CD jobs.