GhostAction returns: stolen maintainer credentials push a fake security-audit workflow into the victims' own GitHub repositories, which now harvests credentials from the entire git history
GhostAction: fake security workflows now harvest whole git histories; rotating Actions secrets is not enough
Defender actions
- Run an organisation-scoped GitHub code search in every organisation your teams and suppliers administer for workflow files under .github/workflows that present themselves as a security audit, a security check or an Actions security workflow and were added since 2026-08-31; any hit means assume breach: revoke the credential that committed it and rotate every secret found anywhere in the repository's git history, not only the configured Actions secrets.
Analysis
StepSecurity reports that on 2026-10-08 the GhostAction GitHub Actions credential-theft campaign used the accounts of two open-source maintainers to push a workflow disguised as a security improvement to 345 repositories in two automated sweeps, among them an Uber-owned repository that one maintainer could still write to (StepSecurity, 2026-10-09); Socket's independent analysis counts 346 (Socket, 2026-10-09). The operator holds a maintainer's GitHub credential, which StepSecurity assesses as most plausibly a personal access token leaked through infostealer logs or credential dumps, then commits a workflow titled to look like a security audit straight to the default branch under the victim's own identity, unsigned and without a pull request; that push runs it, and nothing in an audit log looks anomalous unless the content is read (StepSecurity, 2026-10-09). GitGuardian says the technique was later reused in the Shai-Hulud campaigns and remains at the core of the Mini Shai-Hulud malware family (GitGuardian, 2026-10-07).
The newer payload sends the named Actions secrets and every cloud, AI-provider and SaaS credential pattern found in the working tree and the entire git history to a hardcoded address over plain HTTP, so no DNS lookup occurs (StepSecurity, 2026-10-09). StepSecurity saw the attacker's server acknowledge the request four seconds into the run at the Uber-owned repository (StepSecurity, 2026-10-09); neither it nor Socket has seen a malicious package release from the stolen credentials yet (Socket, 2026-10-09; StepSecurity, 2026-10-09). A Socket update line claims more than 500 accounts and tens of thousands of repositories since 7 October without a method, against 346 for the 8 October burst in its own body and 378 live-workflow repositories across all waves in StepSecurity's code search of 2026-10-09, so the larger figure stays unconfirmed (Socket, 2026-10-09; StepSecurity, 2026-10-09).
Triage: the audit-log pattern separates this from a team adding a scanning workflow: no pull request, unsigned commits across many repositories, and a manual dispatch right after creation (StepSecurity, 2026-10-09).
Cited evidence
confirms the exfiltration completed successfully: the attacker's server acknowledged receipt four seconds after the workflow started
Nothing in an audit log looks anomalous unless the workflow content itself is inspected
The approval gate is worth singling out: it is the single control observed stopping this campaign's exfiltration this week.
Socket has observed no malicious package versions published to PyPI or crates.io as a result of this activity at the time of writing.
Rotating the secrets exfiltrated by the malicious workflow is not enough. The GitHub credential that allowed the injection in the first place must be found and revoked too, or someone else will use it again.
Sources3
AI-generated · no human review · this permalink is the shareable record for the finding · verify operationally critical claims against the linked primary source.