A new wave of the GhostAction supply chain campaign has turned stolen GitHub accounts into a credential-harvesting machine, planting malicious GitHub Actions workflows inside hundreds of public repositories and quietly funneling CI/CD secrets to attacker-controlled servers.
What happened
Between August 31 and September 30, 2026, the operation touched 772 public GitHub repositories and targeted 2,577 secrets across 373 GitHub users and organizations — cloud keys, SSH credentials, container registry logins, database passwords, and GitHub tokens among them.
The attacker doesn't register new accounts or stand up lookalike infrastructure. Instead, GhostAction rides in on GitHub credentials already stolen from the victim, then commits a workflow file directly into the compromised repository — typically named github_actions_security.yml, disguised behind an innocuous commit message like "Add Github Actions Security workflow." Because it looks like routine pipeline maintenance, it slips past a quick code review.
Once merged, the workflow waits for a normal push, scans the repository's existing configuration for secret references, and exfiltrates exactly those values to attacker infrastructure over an HTTP POST request — a deliberately narrow approach that favors precision over noise, targeting credentials useful for deployment, publishing, cloud management, or source-code access.
Researchers tracked the activity in three distinct bursts — 143 repositories on August 31, roughly 400 between September 2 and 5, and another 103 on September 15 — and found that in 92 cases, the attacker didn't plant a new file at all: they updated a workflow left behind from an earlier wave and pointed it at fresh collection infrastructure. As of October 5, only about 16% of the affected repositories had been fully cleaned in their public commit history, meaning a dormant malicious workflow could still fire the next time a developer pushes a legitimate commit.
Why it matters
The numbers show the campaign's reach outpaces its hit rate: most of the flagged workflow runs were held back from executing, and only a smaller subset — roughly two dozen secrets across thirteen repositories — were confirmed stolen. But the pattern underneath is the real warning. SSH keys and deployment credentials, cloud platform access, container registry logins, and tokens for package registries, chat platforms, and AI services were all in scope. That means a single compromised maintainer account can become a bridge into build systems, cloud infrastructure, package registries, and ultimately the software that downstream users install. The same pattern of hidden, persistent GitHub Actions abuse has surfaced in other recent supply-chain incidents, underlining that CI/CD pipelines are now a primary target, not a side door.
What to do
- Audit
.github/workflows/across your repositories for files you don't recognize, especially ones with generic "security" or "check" naming, and treat any unexpected addition as a live incident — not routine cleanup. - If you find a malicious workflow, don't stop at deleting it. Determine how the attacker got repository write access in the first place, revoke that credential, and review workflow run history and audit logs.
- Rotate every secret the compromised workflow could have reached, even ones that appeared masked in logs — masking doesn't prevent exfiltration.
- Enforce least-privilege
GITHUB_TOKENscopes, pin third-party Actions to a full commit SHA rather than a mutable tag, and require review on any change to workflow files. - Turn on phishing-resistant multi-factor authentication for every account with repository write access, and monitor outbound network traffic from CI runners for unexpected destinations.