Summary
- Socket observed malicious workflow commits in 346 repositories on 8 October.
- A 9 October update identified over 500 implicated accounts and tens of thousands of repositories.
- Attackers targeted both GitHub Actions secrets and credentials embedded in source and Git history.
Attackers have expanded the GhostAction supply chain campaign to steal credentials from cloud platforms and AI services, using compromised GitHub maintainer accounts to insert malicious automation workflows into open-source and company repositories.
Socket published an investigation on 9 October 2026 into an 8 October wave involving two compromised accounts. The initial activity placed a file named security-audit.yml inside 346 repositories: 318 associated with henrywoo, 27 under kitao, and one Uber-owned repository to which a compromised contributor retained write access.
The file’s name and GitHub Actions location suggested routine security automation, but its function was to extract secrets. It collected GitHub Actions credentials available to workflows and searched the checked-out project and full Git history for additional cloud, SaaS and AI service credentials. Results were sent to an attacker-controlled IP address over an unencrypted HTTP connection.
The technique extends a previously documented GhostAction pattern in which attackers obtained write access to repositories and introduced malicious workflows. The October campaign broadened the target from CI/CD environment secrets to credentials mistakenly committed to project code or retained in earlier revisions. Removing a secret from a current file does not necessarily remove it from the historical commits available to an attacker.
The two initial automated sweeps occurred within minutes. Socket described activity against projects of different ages and sizes, including dormant repositories, suggesting bulk use of inherited contributor access rather than selection based solely on the projects’ current popularity or activity. The presence of an organisation-owned repository highlights how contributor permissions can bridge personal and corporate project boundaries.
Socket subsequently updated its findings, reporting that more than 500 GitHub accounts had committed the malicious workflow into tens of thousands of repositories since 7 October. The larger figure is a later investigative update, not a reinterpretation of the original 346-repository observation. Impact should be counted cautiously because repository exposure, workflow execution, and confirmed extraction are distinct stages.
Socket said the malicious workflows had run successfully in affected repositories and identified a confirmed successful run targeting publishing credentials in the pyxel project. As of its 9 October report, the company had not observed resulting malicious package releases to PyPI or crates.io. The absence of an observed package compromise does not make exposed credentials harmless, but it limits what can be claimed about downstream software contamination.
GitGuardian and StepSecurity separately documented the return of the campaign and the underlying workflow mechanism. Their investigations support the account of automated credential harvesting, although the studies use slightly different repository counts and observational cut-offs. Those figures should not be added together as though they refer to separate attacks.
Long-lived contributor permissions and secrets accessible from automated build systems widened the possible exposure to software maintainers and downstream users. Remediation requires more than deleting a malicious workflow: credentials potentially accessed or published during the exposure period need to be reviewed and rotated, and compromised accounts and permissions investigated.
The episode also shows why a workflow labelled as a security audit must be evaluated by what it does, rather than by its name. Its position inside a trusted repository gives code execution a legitimate appearance while allowing it to reach credentials and histories unrelated to any authentic audit task.
Socket’s revised scale estimate requires particular care. The two accounts it initially examined introduced the workflow into 346 repositories on 8 October, while its later survey identified activity involving more than 500 GitHub accounts and tens of thousands of repositories since 7 October. Neither repository count is a confirmed total of stolen secrets. The research identifies successful workflow execution in some cases, but the extent of downstream credential misuse is not established by repository presence alone.
