GhostAction Hijacks 790 GitHub Repositories to Harvest Cloud and AI API Keys

A credential-theft campaign tracked as GhostAction has slipped malicious GitHub Actions workflows into roughly 790 repositories. The workflows collect cloud credentials, package-publishing tokens and API keys for AI services, then send them to attacker-controlled infrastructure. The attackers didn't need a zero-day: they took over trusted developer accounts and used the CI pipeline exactly as it was designed to work.

What happened

Once an attacker can push to a maintainer's repositories, they add a workflow that runs when code is pushed or when someone triggers it by hand. The workflow then runs with whatever secrets the project gives its CI.

The latest version of the workflow does more than read selected Actions secrets:

• It searches the repository for credential-like strings. These include AWS access keys and tokens for GitHub, GitLab, Google, Slack, SendGrid, OpenAI, Anthropic and OpenRouter.
• It digs through Git history. It clones with fetch-depth: 0, so a key that was deleted from the current code but still sits in an old commit is fair game.
• It grabs surrounding context. Near AWS key IDs it collects adjacent lines, which can expose a matching secret key or account details, not just a single string.
• It sends the haul out over plain HTTP. The traffic comes from a CI runner, so it can look like a routine build step unless someone reviews workflow changes and outbound network traffic.

The 790 figure is the number of validated repositories that could still be recovered publicly as of 9 October 2026. It does not mean every one of those repositories leaked a secret or that each leak was misused. Other researchers have published different counts for different time windows: about 772 repositories between late August and the end of September, and roughly 346 repositories tied to two compromised accounts during a burst on 8 October. Because those counts overlap, they shouldn't be added together. The affected repositories ranged from active projects and forks to repositories that had been dormant for years. That pattern points to automated discovery of everything a hijacked account can write to.

Investigators say some of the malicious workflows ran successfully. As of 9 October, they had not found malicious PyPI or crates.io releases linked to this latest burst.

Why it matters

CI/CD secrets are among the most valuable credentials an organisation has. One cloud key or publishing token can lead into production infrastructure, package registries that downstream users trust, or paid AI accounts that can be drained or abused. The Git-history step matters most: many teams assume that deleting a hard-coded key from the code fixes the problem. It doesn't. Unless the key was revoked, anyone who can read the history can still use it.

Deleting the malicious workflow is not remediation. A workflow that ran once may already have sent your secrets out, and removing the file doesn't revoke a stolen GitHub token, cloud key or publishing key.

What to do

1. Hunt for unexpected workflows. Check .github/workflows/ across your organisation for files you didn't write, especially recently added ones with generic security- or CI-sounding names. Look for workflows that make raw HTTP POSTs or use curl to send data to unfamiliar hosts.
2. Preserve evidence before you clean up. Keep the workflow files, run logs, commits and audit-log entries from the affected period.
3. Revoke and rotate. Revoke the access the attacker used to make the changes, then rotate every secret the workflow could reach. That includes keys that appear only in old commits.
4. Check what the secrets could reach. Review package releases, deployments and cloud activity for the affected window.
5. Harden Actions. Give workflows least-privilege tokens, require review for workflow changes, add approval gates for sensitive jobs, and restrict outbound network access from runners where you can.
6. Block and watch the reported indicators (defanged): collection and scanning infrastructure at 193.32.204[.]199, and the suspicious domain my-github[.]com. Note that researchers flagged this domain as high priority but have not proven that the GhostAction operators registered it. Look-alike GitLab domains in the published lists are watch items only. They are not confirmed campaign infrastructure.

Secrets buried in repositories and their history are the raw material for campaigns like this. Our team's AI-assisted code review scans source code and full Git history for exposed credentials, risky CI/CD workflow configurations and vulnerable dependencies, so that leaked keys are found and rotated before an attacker finds them.

Source: this article summarises reporting by Cyber Security News, based on research by OpenSourceMalware, with additional figures from GitGuardian, Socket and StepSecurity.