The GhostAction Attack: How 3,300+ Secrets Were Stolen from GitHub Repositories
A large-scale campaign abused GitHub Actions to exfiltrate 3,325 secrets from 817 repositories and 327 users. Learn how it worked and how to secure CI/CD pipelines.
The GhostAction Attack: How 3,300+ Secrets Were Stolen from GitHub Repositories
The GitHub ecosystem was recently hit by one of its largest compromises in years: the GhostAction attack. This campaign, uncovered by researchers at GitGuardian, exposed a gap many teams still treat as someone else's problem: secrets sitting in CI/CD.
Here's a breakdown of what happened and what your team needs to know.
What was the GhostAction attack?
Attackers launched a large-scale campaign to inject malicious GitHub Actions workflows into hundreds of repositories. By disguising their code as routine security updates, they tricked users into running scripts that exfiltrated sensitive secrets from their development environments.
The scale of the breach is staggering:
- 3,325 secrets were compromised.
- 817 repositories were affected.
- 327 users had their credentials stolen.
The stolen secrets included high-value tokens for PyPI, npm, and Docker Hub, as well as keys for cloud services like AWS and Cloudflare.
How did the attack work?
The investigation began with an incident in the FastUUID project. An attacker, using the alias "Grommash9," submitted a pull request with the description "Add Github Actions Security workflow."
Instead of improving security, the workflow contained a malicious script. When triggered by a push or manual run, it extracted secrets from the CI/CD environment and sent them via an HTTP request to a remote server controlled by the attacker. To avoid suspicion, the script included harmless-sounding commands like "Prepare Cache Busting," but its true purpose was data theft.
Although the project maintainers and PyPI responded quickly (revoking the commit and placing the project in read-only mode), the investigation revealed this was just one piece of a much larger puzzle. The same attacker had injected identical workflows into hundreds of other public and private repositories.
The real danger: a supply-chain nightmare averted
The most significant threat was the potential for a massive supply-chain attack. With stolen tokens for npm, PyPI, and Docker Hub, attackers could have published malicious versions of popular packages and container images. Anyone who downloaded these compromised dependencies would have been infected.
While a large-scale malicious release was prevented this time, the active use of some stolen credentials has already been confirmed, including AWS keys and database passwords.
The key takeaway for developers and security teams
The GhostAction attack proves that CI/CD pipelines, once seen as simple build tools, are now a primary target for attackers because they hold access to your most valuable secrets.
This incident shows that attackers are becoming more sophisticated. They analyze legitimate workflows to identify the names of secrets used, then create fake scripts to steal those exact credentials.
How to protect your organization
- Audit your workflows: treat your
.github/workflowsfiles with the same scrutiny as your application source code. - Scrutinize pull requests: be wary of pull requests from unknown contributors, especially those modifying CI/CD configurations.
- Implement secret scanning: proactively scan your repositories and CI/CD logs for exposed credentials. Don't wait for a breach to find out you've been compromised.
Securing your CI/CD pipeline is essential for protecting your code, your customers, and your company.
Why workflow files are now a secret store
GitHub Actions is convenient because it already has the tokens your release needs. That is also why it is a target. A workflow that looks like a security improvement can POST those tokens off-box on the next push. The GitGuardian write-up is worth reading end to end if you run public or private Actions at any scale.
If you only scan application source and skip .github/workflows, you are looking at the wrong layer for this class of theft. Pair repository scanning with a review of which secrets each job is allowed to read. Short-lived OIDC tokens beat long-lived PATs sitting in repo secrets.
What to do this week
- Search commit history for workflow names like "Github Actions Security."
- Rotate anything that lived in those jobs: npm, PyPI, Docker Hub, cloud keys.
- Turn on PR scanning so a leaked token in a workflow file is not the first time you hear about it. Setup is on the getting started page. How we score noise is on methodology.
Puaro will not magically catch a malicious workflow that never contains a secret string. It will catch the keys that workflow was built to steal, if those keys ever land in git, a PR, or a log your scanner can see.
Treat workflow YAML like production code: review it, pin actions by SHA, and drop long-lived PATs from secrets.* where OIDC can issue a token for one job. That is slower than pasting a classic token into repo settings. It is also how you stop the next lookalike "security" workflow from mailing your npm token to a host you do not own.
If a secret did leave the repo, rotation is the fix, not a better dashboard. Scan so the next one does not wait for a researcher blog to name it.