GhostAction Returns: Fake 'Security Audit' Workflows Steal CI Secrets

On 8 October 2026, two hijacked GitHub maintainer accounts pushed a workflow called a "security audit" to more than 340 repositories in a single day. The workflow read the repository's secrets, scanned the code and full git history for keys, and posted everything to a bare IP address over plain HTTP. GitGuardian links it to GhostAction, a campaign first documented in September 2025, and says an earlier 2026 wave had already hit 772 repositories between 31 August and 30 September.

What's affected

This is not a vulnerable package. It is a malicious commit to your own repository, made with a stolen credential. Public reporting gives these figures:

• 8 October: StepSecurity reports the workflow was pushed to 27 repositories under Takashi Kitao's account from 13:20 UTC, then to 318 repositories under Henry Wu's henrywoo account between 21:10 and 21:26 UTC.
• By 9 October: Socket said more than 500 GitHub accounts had committed the workflow to tens of thousands of repositories since 7 October.
• 13 October update: GitGuardian counts more than 30,000 targeted repositories across about 3,000 users and organizations, from roughly 1,900 compromised accounts.
• 31 August to 30 September: GitGuardian's count for the previous wave is 772 public repositories belonging to 373 users and organizations, with 2,577 secret names targeted.

The files and commit messages to look for:

According to The Hacker News summary of the research, the October workflow triggers on workflow_dispatch and on any push to any branch or tag, checks out full history, and runs one "Audit" step. That step dumps the repository's named secrets, searches the working tree and git history for 13 credential patterns covering AWS, AI providers, source control and SaaS keys, pairs AWS key IDs with their secret keys, and sends the result with curl to 193.32.204.199.

GitGuardian reports that GitHub began preventing the malicious workflow from running on 9 October, and that waves on 10 and 12 October extracted no secrets. Runs that executed before that point did leak data.

How to check if you're exposed

Search every branch, not only the default one, for the workflow files and commit messages:

# In each repository clone
git fetch --all --prune
git log --all --oneline -- .github/workflows/security-audit.yml \
  .github/workflows/github_actions_security.yml .github/workflows/security-check.yml
git log --all --oneline --grep='Github Actions Security workflow' --grep='security check workflow' -i
git grep -n '193.32.204.199' $(git rev-list --all) -- .github/ 2>/dev/null | head

Across a GitHub organization, use the code search UI or the gh CLI to find the files on default branches:

ORG=your-org-name
gh search code --owner "$ORG" --filename security-audit.yml
gh search code --owner "$ORG" '193.32.204.199'

Then check Actions run history for workflows named "Security Audit", "Github Actions Security" or "Security Check" that you never created, and look at forks and mirrors of your repositories. Socket warns that forks can inherit the file through synchronization.

What to do now

1. Revoke the credential that made the commit. Find the account or token in the commit metadata and the audit log. Rotating repository secrets alone leaves the attacker able to come back.
2. Rotate every secret the workflow could read. That means all repository and organization secrets available to the repository, plus any key that appears anywhere in the git history. GitGuardian advises rotating even values that look harmless, such as hostnames and usernames, because they were collected alongside the keys.
3. Delete the workflow from all branches and forks. A file left on a stale branch still runs on push.
4. Restrict who can add workflows. Require pull request review on default branches with rulesets, add a CODEOWNERS rule for .github/workflows/, and set the default GITHUB_TOKEN permission to read only.
5. Kill long-lived personal access tokens. The likely entry point, per the reporting, is a leaked token from infostealer logs. Move to fine-grained tokens with expiry, or to GitHub Apps, and enforce SSO for organization access.
6. Clean history where secrets were committed. Rotation comes first. Rewriting history afterwards stops the next scan from finding them again.

Why it matters

GhostAction does not need a vulnerable dependency or a clever exploit. It needs one valid credential with push access, and a CI system that will run whatever YAML lands on a branch. Naming the file "security audit" is aimed at the human who skims a notification and moves on.

The secrets-in-history scan is the part to take seriously. Many teams rotated a key years ago but never removed it from git history, and some never rotated at all. GitGuardian found that only 124 of the September wave's repositories, about 16 percent, had been cleaned in public history by 5 October. If an attacker gets read access to your history, assume they get every key that was ever committed.

Try it yourself

Pick your busiest repository and run a secrets scan over the full history, not just the current tree. Note how many findings are in commits older than a year, and whether each one has been rotated. That list is what a GhostAction-style workflow would have sent out.

Click through it at your own pace, or open it full screen.

Quick check

Sources

• GitGuardian: GhostAction returns
• The Hacker News: GhostAction credential-stealing GitHub Actions workflows