A Fake Security Audit Workflow Is Stealing Secrets From GitHub Repositories: The Attack and the Cleanup in 8 Steps
Hijacked GitHub accounts are pushing a workflow disguised as a security audit that sends repository secrets and cloud keys to an attacker. Here is how it works and how to clean up.
A credential-theft campaign is using stolen GitHub accounts to slip a booby-trapped workflow into repositories. The file looks like a routine security check. What it actually does is collect every secret it can find and send it to the attacker.
Ravie Lakshmanan laid out the research from StepSecurity, Socket and GitGuardian at The Hacker News. We used that report to put together the walkthrough below.
How the attack plays out
- The attacker gets in as a real maintainer. The likely source is a leaked personal access token from infostealer logs or credential dumps.
- The attacker looks for secrets first. Existing workflow files are scanned to learn which named secrets the repository has.
- A fake audit lands on the default branch. It is a workflow called “Security Audit” (security-audit.yml) or “GitHub Actions Security” (github_actions_security.yml), and it is committed under the victim’s own identity.
- The workflow runs on almost anything. It triggers on manual dispatch and on any push to any branch or tag, and it checks out the full git history.
- It collects credentials in four ways. It grabs the named secrets, scans the current files for 13 credential patterns, searches the whole git history for the same patterns (catching keys that were committed and later deleted), and pairs up AWS access key IDs with their secret keys.
- Everything goes out in plain text. The data is sent with curl over unencrypted HTTP to a hard-coded IP address, 193.32.204[.]199.
How big it has become
StepSecurity tracked the account of the author of pyxel, a game engine with about 18,400 stars, pushing the workflow to 27 repositories. Eight hours later the account of Henry Wu, original author of Uber’s athenadriver, pushed it to 318 repositories in 16 minutes. By October 9, Socket had counted more than 500 GitHub accounts committing the workflow to tens of thousands of repositories since October 7. Targets include CI/CD secrets, cloud keys, GitHub and GitLab tokens, and API keys for AI services such as Anthropic, OpenAI and OpenRouter.
Researchers tie the activity to GhostAction, a campaign first seen in September 2025. GitGuardian reported that between August 31 and September 30, 2026, it pushed the workflow to 772 public repositories belonging to 373 users and organizations. So far, no malicious package releases have been published with stolen publishing credentials.
The cleanup, continued
- Search your repositories and forks for either workflow file, going back to August 31, 2026. If you find one, assume the repository’s secrets are compromised.
- Revoke, rotate and remove. Revoke the GitHub credential that pushed it, rotate every secret the repository could reach, delete the workflow from all branches, and check forks. Socket warns that forks carrying the file can trigger the theft on later pushes if Actions are enabled, and that private forks and mirrors are the most exposed.
What this means for your company
You don’t have to be a software company to be affected. If a developer, contractor or vendor keeps code for your website, apps or automation on GitHub, your cloud and payment keys may sit in those repositories or their history.
- Find out where your code lives and who holds admin access to it, including outside developers.
- Replace long-lived personal access tokens with short-lived, narrowly scoped credentials, and require multifactor sign-in on every code hosting account.
- Require review for workflow changes and protect your default branch, so a single stolen account can’t push straight to it.
- Turn on secret scanning and treat any key that was ever committed as exposed, even if it was later deleted.
- Protect developer machines with endpoint protection, since stolen tokens usually start with infostealer malware.
Need help auditing your code repositories, rotating exposed keys or locking down developer access? Reach out to Layer 7 Data Solutions to discuss how we’ve helped companies similar to yours.
About The Author
