Your GitHub Repo Got a Fake Security Audit That Stole Your API Keys

Someone Pushed a "Security Audit" to Your Repo, and It Robbed You

It looked completely routine. A commit called "Add security audit workflow" landed in your repository, adding a file at .github/workflows/security-audit.yml. Nothing alarming. Security tooling lands in repos all the time.

That file was not a security audit. It was a heist.

Between October 7 and 8, 2026, attackers compromised more than 500 GitHub accounts and used them to push that malicious workflow to tens of thousands of repositories. The file looked legitimate. The commit message sounded responsible. And once it ran, every secret your repository had ever touched was already gone.

How Does the Attack Actually Work?

GitHub Actions workflows run automatically when you push code. They have access to your repository's secrets, the API keys, cloud credentials, and tokens you store in GitHub's encrypted settings panel. That access is by design. Deployment pipelines need it.

This workflow abused that access completely.

Once triggered, it silently collected every GitHub Actions secret in scope: AWS key pairs, OpenAI API keys, Anthropic API keys, OpenRouter credentials, and anything else you had stored. It then transmitted all of it over plain HTTP to an attacker-controlled IP address.

No alerts. No error logs. Just a workflow run that looked like a normal CI job.

Here is the part that should stop you cold. The workflow also ran git log -p --all. That command walks the entire commit history of your repository, including branches, including deleted commits, including content you removed years ago. If you ever accidentally committed an API key in 2021 and deleted it in a panic the same afternoon, this workflow found it. Git does not forget. The workflow used that fact as a weapon.

Who Got Hit?

Two confirmed high-profile victims have been named publicly. Uber's athenadriver repository was compromised through a hijacked maintainer account. So was kitao/pyxel, a Python game library with over 18,000 GitHub stars. Both attacks came through legitimate accounts that had been taken over, which is why the commits looked trustworthy.

At the time of first reporting, 378 repositories still carried the live malicious workflow. No malicious package releases have been confirmed yet, but that window may be narrow.

This attack has a name and a history. Researchers track it as GhostAction. A prior wave of GhostAction exfiltrated 3,325 secrets from 817 repositories. The October 2026 wave is substantially larger, both in the number of compromised accounts used and in the number of repositories targeted.

The git-history mining capability appears to be new to this wave. That changes the threat model significantly. Rotating your current credentials is not enough if you have years of commit history that may have held credentials at some point.

What You Should Do Right Now

1. Check your repositories immediately. Look for .github/workflows/security-audit.yml or any recently added workflow file you do not recognize. If you find one, delete it and treat every secret in that repository as compromised.

2. Rotate every exposed credential. Revoke and regenerate AWS keys, OpenAI keys, Anthropic keys, and any other API credentials stored as GitHub Actions secrets in affected repositories. Do this before anything else.

3. Audit your entire git history. Run git log --all --full-history -- '**/*.env' '**/*.key' and similar searches on your repositories. If you ever committed credentials and deleted them, assume they were captured. Rotate those credentials too.

4. Enable hardware-backed 2FA on your GitHub account. A passkey or a hardware security key would have stopped the account compromises that enabled this attack. GitHub supports both. SMS-based 2FA offers much weaker protection.

5. Review your organization's repository permissions. Limit which repositories have access to your most sensitive secrets. Use environment-scoped secrets where possible so a single workflow cannot reach everything.

6. Check for unauthorized OAuth applications and personal access tokens. A compromised account may have installed persistent access beyond the workflow itself. Go to GitHub Settings, then Applications, then Authorized OAuth Apps, and review everything there.

7. If you use AWS, check CloudTrail. Look for API calls from unusual IP addresses or at unusual times in the days following October 7. Stolen keys get used fast.

The Systemic Truth Behind This Attack

Most founders and creators store secrets in GitHub because GitHub tells them to. The secrets manager is built in, documented, and easy. It feels secure because it is encrypted at rest and hidden in the UI. What it cannot protect against is a workflow that runs with legitimate access and quietly phones home.

The git history piece reveals something deeper. You have always been told to delete sensitive commits and move on. The operational reality is that git history is essentially permanent until you force-rewrite it, and most repositories never undergo that process. Attackers have known this for years. This wave built automation around it.

The question is not whether your infrastructure is secure today. The question is whether a secret you thought was gone has been quietly waiting in a commit hash from three years ago.

Do this now:

• Search all your repositories for unexpected workflow files added October 7 or later
• Rotate AWS, OpenAI, Anthropic, and any other secrets stored in affected repos
• Audit git history for previously committed credentials
• Enable a passkey or hardware key on your GitHub account
• Review authorized OAuth apps and personal access tokens in GitHub settings

Sources

• cybersecuritynews.com
• socket.dev