A fresh GhostAction supply-chain campaign compromised 346 GitHub repositories after attackers took control of two maintainer accounts and planted a fraudulent security-audit workflow. Once triggered, the GitHub Actions job stole automation secrets and searched both current files and historical commits for credentials, demonstrating how one compromised developer identity can fan out across an entire project portfolio.

Security researchers at Socket linked the October 8 activity to repositories writable by the accounts “henrywoo” and “kitao.” The affected set included the popular Pyxel project, which has more than 18,000 GitHub stars, and Uber’s AthenaDriver repository.

A security audit that quietly exports credentials

The attackers added a file named .github/workflows/security-audit.yml, commonly using commit messages such as “Add security audit workflow” or “Update security audit workflow.” Its benign label helped the modification resemble ordinary repository maintenance. In reality, the job collected valuable data and transmitted it via an HTTP POST request to the attacker-controlled address 193.32.204[.]199.

GitHub Actions workflows frequently receive credentials so they can publish packages, access cloud services or update other repositories. GhostAction targeted secrets referenced by legitimate project jobs, including personal access tokens and credentials for PyPI and crates.io. A stolen publishing token could allow an adversary to distribute a malicious update under the identity of a trusted package.

The latest variant also searched repository content and the complete Git history. It requested a full clone with fetch-depth: 0, then looked for patterns associated with AWS access keys and session tokens, GitHub and GitLab tokens, Google and Slack credentials, SendGrid secrets and API keys for prominent AI services. Old commits matter because deleting a secret from the current branch does not remove it from previous revisions.

Automation multiplied the blast radius

Socket counted 318 affected repositories in the henrywoo namespace, including 279 forks, another 27 under kitao, and the AthenaDriver project. Commits appeared in short bursts and reached inactive repositories that had not changed for years, suggesting automated discovery and modification rather than manual selection.

The campaign follows earlier GhostAction waves. Researchers previously documented hundreds of compromised repositories and thousands of targeted secrets. The expansion into Git-history scanning shows that the operators are improving their collection methods and seeking credentials that maintainers may have forgotten.

No malicious PyPI or crates.io release tied to this latest wave had been identified when the activity was reported. That is reassuring but not proof that stolen credentials went unused. Cloud keys, repository tokens and service credentials can support quieter objectives, while package-publishing access might be held for later exploitation.

Deleting the workflow is not remediation

Any repository in which the malicious workflow executed should be treated as a possible credential exposure. Maintainers need to remove the job, but they must also revoke and replace every secret it could read. GitHub sessions, personal access tokens, SSH keys, OAuth grants and package-registry credentials tied to the hijacked account deserve review.

• Inspect Actions history for unexpected security-audit jobs and failed runs.
• Search commits for the known workflow paths and suspicious commit messages.
• Review egress logs for traffic to 193.32.204[.]199.
• Scan every branch, tag and historical commit for exposed credentials.
• Audit package and container releases for unauthorized versions.

Cloud providers and third-party services should be checked for activity performed with the exposed keys. Where possible, responders should determine the workflow’s exact run time and correlate it with API logs, package publication and changes to repository settings.

Protect workflow changes as production code

Repository owners can reduce this class of risk by requiring review for changes under .github/workflows, enforcing protected branches and limiting Actions permissions. Secrets should be narrowly scoped, short-lived where possible and unavailable to jobs that do not require them. GitHub secret scanning and push protection can catch some hardcoded credentials before they become permanent history.

Organizations should also review what a maintainer account can modify. Hundreds of repositories under one identity turn a single phishing or token-theft event into a scalable compromise. Hardware-backed multi-factor authentication, periodic session review and rapid offboarding are essential, but authorization still needs least privilege.

GhostAction’s lesson is that CI/CD configuration is executable infrastructure. A workflow presented as a harmless audit can obtain trusted credentials, access years of code history and open a route into downstream ecosystems. It deserves the same review discipline, ownership and monitoring as the software it builds.