GhostAction GitHub Attack: Check Your Repos (2026)

A campaign called GhostAction has compromised roughly 1,900 GitHub accounts and planted a credential-stealing workflow in more than 30,000 repositories. If you maintain anything on GitHub — especially if you got a mysterious new workflow file called security-audit.yml or github_actions_security.yml — you need to check your repos this weekend. Not next week. This weekend.

This is a practical guide: what the GhostAction GitHub attack is, how the malicious workflow works, how to check whether your repositories are affected in about ten minutes, what to do if you find it, and how to make sure it can’t happen to you again. Everything below was verified against reporting from The Hacker News, GitGuardian, StepSecurity, and Socket on October 17, 2026.

The numbers: three waves and counting

GhostAction isn’t a one-off incident. GitGuardian first named the campaign in September 2025, and it has never actually stopped. Here’s the timeline:

Wave	Scope	What was targeted
September 2025 (first reported)	817 repositories across 327 GitHub users	3,325 secrets exfiltrated, including PyPI, npm, and DockerHub tokens
August 31 – September 30, 2026	772 public repositories belonging to 373 users and organizations; 2,577 secrets targeted	SSH private keys (446), Azure credentials (218), DockerHub/GHCR logins, database credentials, AWS keys, FTP, Google Cloud, GitHub tokens, bot tokens, Cloudflare/npm/PyPI/AI provider keys
October 8–9, 2026 (the big spike)	30,000+ repositories across ~3,000 users and organizations, via ~1,900 compromised accounts	Attempted extraction of 3,174 secrets from public repositories’ CI

A detail that should worry you: in 92 cases in the August–September wave, the attacker didn’t add a new workflow at all. They updated a malicious workflow that was already sitting in the repository from an earlier wave. GitGuardian’s own data shows that as of October 5, only 124 of the 772 repositories from that wave — about 16% — had been effectively cleaned. And of 3,669 workflow runs collected across 605 repositories, GitHub held most for approval; 499 still executed in 32 repositories, and 336 completed successfully, exfiltrating 26 secrets from 13 repositories.

The October spike has a grim pattern too: some of the victims had already been hit in earlier waves. The attackers are returning to previously breached accounts on the assumption that exposed secrets were never rotated. In many cases, that assumption was correct.

How GhostAction actually works

The scariest part of this attack is how boring it is. There is no GitHub Actions vulnerability being exploited. GitHub hasn’t been breached. The attack starts with a stolen credential and uses your own legitimate infrastructure against you.

Step 1: Steal the maintainer’s credential

The attacker obtains a maintainer’s GitHub credentials — most likely a leaked personal access token (PAT) pulled from infostealer logs or credential dumps, according to StepSecurity’s October 9 analysis. From GitHub’s point of view, everything that follows looks like the legitimate maintainer doing routine work.

Step 2: Reconnaissance first, stealing second

Before committing anything, the attacker scans the repository’s existing workflow files for ${{ secrets.NAME }} references — every secret the project actually has configured. Those exact secret names get templated into the malicious payload. When the workflow runs, GitHub substitutes the real values, and a curl -X POST sends them to a hard-coded IP address (193.32.204[.]199) over plain HTTP. No encryption, no subtlety.

Step 3: Commit something that looks like hygiene

The file is usually named security-audit.yml or github_actions_security.yml, committed with the message “Add Github Actions Security workflow”. The name is the disguise: during a quick code review it reads as routine automation hygiene, exactly the kind of commit you’d skim past.

Step 4: Run and exfiltrate

The workflow waits for a normal repository push. When it runs — typically triggered by someone else’s legitimate commit, not the injection itself — it ships the secrets to the attacker’s server. StepSecurity confirmed the exfiltration by pulling the Actions run log for one infected repository: the curl POST completed and the attacker’s server responded OK roughly four seconds after the workflow started.

The October wave’s upgrades

The new payload does everything the old one did, plus two significant upgrades:

Full git-history secret hunting. The workflow checks out the repo with full history (fetch-depth: 0) and runs a regex sweep across the working tree and every commit, tag, and branch, looking for 13 credential patterns: AWS keys, GitHub and GitLab tokens, AI provider keys, cloud and SaaS credentials. The earlier waves only took configured Actions secrets. This version also finds the AWS key you committed and deleted eighteen months ago — because deleting a file doesn’t remove it from git history.
AWS key pairing. Later payload variants collect a couple of lines of surrounding context for each detected AWS access key ID, which helps the attacker find the matching secret access key.

The two high-profile hits

Two compromised maintainer accounts show how fast this moves. On October 8, using the account of Takashi Kitao, author of the 18,400-star game engine pyxel, the attacker pushed the workflow to 27 repositories starting at 13:20 UTC. Eight hours later, the account of Henry Wu (henrywoo), the original author of Uber’s athenadriver, pushed the same workflow to 318 repositories in 16 minutes (21:10–21:26 UTC).

For the pyxel repositories, the recon step had identified the exact secrets worth stealing: CARGO_REGISTRY_TOKEN, PERSONAL_ACCESS_TOKEN, PYPI_PASSWORD, and PYPI_USERNAME — publishing credentials for packages tens of thousands of developers install. Socket reported that, as of October 9, it had identified more than 500 GitHub accounts that committed the malicious workflow to tens of thousands of repositories since October 7, and code searches found 378 repositories with a live malicious workflow on the default branch.

StepSecurity’s assessment is worth reading in full: “The absence of abuse so far is not evidence that the credentials are safe.” As of October 9, no malicious package releases had been observed using the compromised publishing credentials. That is a statement about what has been observed — not a guarantee about stolen npm, PyPI, or registry tokens that are still valid.

What GitHub did — and why it isn’t enough

On October 9, GitHub began blocking the known malicious workflow from executing. GitGuardian’s tracking shows that additional waves using the same payload appeared on October 10 and October 12 — but because of GitHub’s blocking, those waves couldn’t extract secrets through the workflows.

That sounds like good news, and it is, partially. Here’s what it isn’t:

The compromised credentials are still valid. Blocking the workflow addresses the symptom. The stolen PAT that pushed the workflow still exists, still has write access, and can commit a new workflow under a new filename the moment the old one gets flagged. Deleting the malicious file without revoking the credential is cosmetic.
Secrets exfiltrated before October 9 are gone. The October 8–9 batches ran. If your workflow ran during that window, your secrets are in someone else’s database, and no blocking action changes that.
Unrotated secrets from earlier waves are still being targeted. The repeat-victim pattern shows the attackers are betting — correctly — that many compromised secrets were never rotated after the September 2025 or August–September 2026 waves.

The fix has to include revoking the key, not just deleting the file. That is the single most important line in this guide.

Am I affected? The 10-minute repo check

Check every repository you own or maintain, including organizations you’re a member of. Check every branch and every fork — the malicious commits were pushed to default branches and forks alike.

1. Search your repos for the two filenames

In each repository’s local clone:

git log --all --oneline --diff-filter=A -- \
  '.github/workflows/security-audit.yml' \
  '.github/workflows/github_actions_security.yml'

If that returns commits you didn’t write, you’re affected. Also search for the suspicious commit message across all history:

git log --all --oneline --grep="Github Actions Security"

2. List the workflows GitHub knows about

If you use the GitHub CLI:

gh api repos/OWNER/REPO/actions/workflows \
  --jq '.workflows[] | [.name, .path, .state] | @tsv'

Anything named like a security audit that you didn’t create is a red flag. Then list recent runs of suspicious workflows:

gh run list --workflow security-audit.yml --limit 20

3. Check the Actions runs and the audit log

In the GitHub web UI: repository → Actions → look for runs of a workflow you don’t recognize, especially around October 7–9, 2026. Then check Settings → Security log / Audit log for pushes you didn’t make — including the security-audit.yml commits, which were made under the compromised maintainer’s own identity.

4. Check branches and forks

The malicious file can exist on a non-default branch:

git fetch --all
for b in $(git branch -r --format='%(refname:short)'); do
  git ls-tree -r --name-only "$b" -- .github/workflows/ \
    | grep -Ei 'security-audit|github_actions_security' \
    | sed "s/^/$b: /"
done

And don’t forget your forks — mirrors of infected repos carried the workflow too.

5. Scan history for leaked credentials

Even if you never see the malicious workflow, check whether any secrets lived in your history (the October payload reads it directly):

# Quick check for AWS keys in all history
git log -p --all -S 'AKIA' | head -100

For a proper scan, run gitleaks or trufflehog against the full history, and review Security → Secret scanning alerts on each repo — GitHub’s own scanner may already have flagged something.

You found it. Now what? (in this order)

Treat the presence of either file as a compromise, not a cleanup task. Do these in order:

Revoke the GitHub credential first. Go to Settings → Developer settings → Personal access tokens and revoke any token you don’t recognize or can’t account for. Then Settings → Sessions and revoke unknown sessions, and review OAuth app authorizations. If an organization is involved, do this for every maintainer with write access. This is the step people skip — and it’s the one the attack survives on.
Rotate every secret the workflow could reach. Start with the exact secret names the recon step would have found (list your repo’s ${{ secrets.* }} references and rotate all of them), then cloud credentials — AWS keys in particular — plus npm/PyPI/DockerHub tokens, AI provider API keys, GitHub and GitLab tokens, and SSH deploy keys. Treat everything exposed to the repository as burned, including credentials that were deleted from current files but ever lived in the history.
Delete the malicious workflow from all branches. Not just main. Remove the file everywhere it was committed, including forks you control. Git history will still record that it existed — that’s fine, what matters is that no live ref carries it.
Check forks and mirrors. If others forked your repo after the injection, the workflow traveled with it. Contact the fork owners or open issues on the affected forks.
Review Actions run logs. Confirm whether the workflow actually ran on your repos. A run that completed is a confirmed exfiltration event — rotate accordingly and review anything that secret could access (published packages, cloud resources, production databases).
Check package release history. If publishing credentials (npm, PyPI, crates.io tokens) were exposed, verify no unauthorized releases were published. StepSecurity found none as of October 9 — but verify your own projects directly.
Search network logs for traffic to 193.32.204[.]199 if you run your own runners or CI infrastructure.

How to make this not happen to you

None of this is exotic. GhostAction works because the stolen credentials have far more power than they need. Tighten the basics:

Use fine-grained PATs with short expiry. Classic PATs are all-or-nothing and live forever. Fine-grained tokens can be scoped to specific repositories with specific permissions, and set expiry to days, not months. A stolen 7-day token is a far smaller blast radius than a stolen “no expiration” one.
Enable 2FA for everyone, and require it on your orgs. Organization Settings → Security → require two-factor authentication. The initial credential theft in this campaign came from infostealer logs and credential dumps — 2FA doesn’t fix that, but it raises the cost of turning a stolen password into a session.
Protect .github/workflows/ with CODEOWNERS. Add .github/workflows/ @your-org/security-team to your CODEOWNERS file and enable “Require review from Code Owners” in branch protection. Then a compromised account pushing a workflow directly to the default branch gets blocked or at least flagged.
Turn on secret scanning with push protection. Repository Settings → Code security → enable secret scanning and push protection. It stops your secrets from entering history in the first place — and the October payload reads history directly.
Audit workflow changes regularly. The commit message “Add Github Actions Security workflow” looked plausible. Train your review eye on .github/workflows diffs the way you’d train it on dependency changes.
Rotate secrets on a schedule, not just after incidents. The repeat-victim pattern in this campaign exists because secrets compromised in 2025 were still valid in 2026. Assume any secret that has ever been exposed is compromised.

The takeaway

GhostAction is not a GitHub vulnerability. It’s a credential problem that weaponizes your own CI. The workflow filename is the least important detail — the important details are the stolen token that committed it and the secrets that were never rotated. Check your repos today, revoke anything you can’t account for, and make your tokens short-lived and fine-grained. That closes the door this campaign has been walking through since September 2025.

GhostAction GitHub Attack: How to Check If Your Repos Are Compromised (2026)