Introduction
In under 48 hours, the third wave of the GhostAction campaign compromised more than 500 GitHub maintainer accounts to inject a malicious workflow into tens of thousands of repositories. October 8, 2026 will be remembered as the moment this persistent campaign crossed a threshold: beyond the usual CI/CD secrets, it now targets the entire git history of compromised projects.
How the Attack Works
The injected file is named .github/workflows/security-audit.yml — an intentionally reassuring name designed to mimic legitimate security practices. Associated commits carry messages such as "Add security audit workflow" or "Update security audit workflow," carefully worded to blend in with everyday contributions.
Once the workflow is in place, it runs on every code push with no branch filtering. Its first action is to map the repository's existing GitHub Actions secrets — automated reconnaissance that signals tooled orchestration, not manual intervention. It then retrieves the full git history using the fetch-depth: 0 parameter, an option that pulls every commit on every branch, including stale branches and orphaned references. All collected data is exfiltrated in plaintext to a hardcoded IP address via a simple HTTP POST request.
When Git History Becomes an Attack Surface
Previous GhostAction waves were limited to secrets declared in GitHub Actions. The October 2026 wave retains that capability and adds a critical new dimension: a regex scan across the entire versioned codebase — both the working tree and the complete commit history.
The patterns target thirteen credential categories: long-lived and temporary AWS access keys (STS), AWS secret keys, session tokens, Anthropic, OpenAI, and OpenRouter API keys, GitHub and GitLab tokens, Google/Firebase/GCP keys, Slack tokens, and SendGrid keys. The technical nuance lies in AWS key handling: when a key ID is detected, the workflow captures the two lines above and below to reconstruct the ID/secret pair — whether it lives in a .env file, a Terraform block, or an AWS credentials file. The reason is straightforward: maintainers often believe these credentials were permanently deleted, when in fact they persist silently in git history.
Socket Research confirmed the successful exfiltration of 3,325 secrets. Among the repositories hit in the October 8 burst were kitao/pyxel (18,420 stars) and uber/athenadriver, both compromised through maintainer accounts whose access had been hijacked.
Immediate Steps for Your Teams
The first priority is rotating all potentially exposed credentials — not just those in the most recent commit, but every key that has ever passed through the repository's git history since its creation. The command git log -p --all will surface every occurrence, including across deleted branches.
For exposed AWS keys, a CloudTrail audit covering the full window of exposure is essential before any revocation: a compromised key leaves usage traces that must be identified to accurately assess the true scope of the breach.
On the prevention side, three measures are non-negotiable: enable secret scanning with push protection on all GitHub repositories, restrict direct write permissions on default branches, and monitor for the appearance of .github/workflows/security-audit.yml files across your repository alerts. The network indicator to block immediately: 193.32.204[.]199.
GhostAction reflects a broader trend that security leaders can no longer afford to ignore: CI/CD pipelines have become the entry point of choice for large-scale credential theft campaigns. The attack surface is no longer limited to what your workflows expose today — it encompasses everything your codebase has ever contained.