New GhostAction Wave Hits Hundreds of Repos, Expanding Beyond CI/CD Secrets to Cloud Credentials

What it is

The GhostAction workflow file .github/workflows/security-audit.yml, deployed via compromised GitHub maintainer accounts (henrywoo, kitao) to 346 repositories on October 8, 2026. It is a GitHub Actions job disguised as a security audit, triggered on any push to any branch or tag plus manual workflow_dispatch, that exfiltrates credentials to 193.32.204[.]199.

How it works

The workflow runs five variables that populate a single exfiltrated payload:

• grepped — scans the working tree (excluding .git) for 13 credential regex patterns.
• gl — runs git log -p --all to pull raw patch text from every branch and tag, including ones no longer reachable from the default branch.
• hist — matches the same 13 patterns against that history buffer.
• ctx — captures two lines on either side of every AWS access key ID (AKIA/ASIA) in the working tree.
• hctx — same AWS context capture, but against full history.

The fetch-depth: 0 setting is what enables this: a normal checkout only fetches the current shallow branch, but depth zero pulls every branch/tag so git log -p --all can read deleted or rewritten commits. The AWS context capture matters because a key ID alone authenticates nothing — the 40-character secret key that pairs with it is typically found one or two lines away in .env, credentials files, or Terraform configs, so this reconstructs full usable key pairs rather than orphaned IDs. Results are delimited with AKIA_CTX_START/AKIA_CTX_END markers in the exfiltrated body.

The 13 patterns cover AWS (AKIA[0-9A-Z]{16}, ASIA[0-9A-Z]{16}, secret/session tokens), Anthropic (sk-ant-), OpenAI (sk-proj-), OpenRouter (sk-or-), GitHub PATs (ghp_, github_pat_), GitLab (glpat-), Google/Firebase (AIza...), and SendGrid (SG\....\....).

Separately, the original GhostAction technique (line 15 of the file) scans existing workflows for named Actions secrets and renders that exact list into the payload before committing — this is why Pyxel's copy names CARGO_REGISTRY_TOKEN, PERSONAL_ACCESS_TOKEN, PYPI_PASSWORD, PYPI_USERNAME specifically.

What to do

Triage by reading line 15 of the injected file: a populated secret list means Set A (named Actions secrets) is exposed; [ -n "" ] empty means Set B (grep-based) only — treat both as present if unsure.

If Actions secrets were named: rotate every one listed; for a PyPI/crates.io setup, issue new PyPI credentials and a new crates.io token, and revoke (not rotate) any personal access token. Check PyPI/crates.io release history for unexpected versions during/after the exposure window.

If the repo was grepped: run git log -p --all yourself, including unreachable objects, to find what was exposed historically. Rotate anything found in any of the 13 categories, even if no longer in the current tree. For AWS keys, review CloudTrail for new IAM users, access keys, or unexpected regions.

In all cases: remove the workflow file, revert the commit (including on org-owned repos), treat the compromised account as fully breached (revoke sessions/PATs/OAuth grants/SSH keys, enforce phishing-resistant MFA), audit org logs for the push window, hunt for egress connections to 193.32.204[.]199 and block it, enable secret scanning with push protection, and require approval for workflow runs from outside collaborators. Fork owners from the affected namespaces should check for the workflow file before enabling Actions.

Caveats

Socket states it did not observe how the maintainer credentials were originally obtained, and as of the time of writing had seen no malicious package versions published to PyPI or crates.io as a result of this wave.