Fake GitHub Security Audits Hunt Credentials in Old Commits
A workflow promising a security audit can become a route out for a project's credentials. Researchers at Socket reported on October 9 that attackers planted a fake audit in 346 GitHub repositories during an October 8 attack wave. The workflow targeted both secrets available to build jobs and credentials preserved in old commits, including keys developers had removed from their current files.
GitHub Actions is the service developers use to automate builds, tests and deployments from workflows stored alongside their source code. Socket calls this campaign GhostAction. Its newly reported variant makes the risk especially concrete for repository maintainers: a change presented as a security improvement can use that same automation to search for credentials and send them away.
The audit is executable code
A GitHub Actions workflow is a text configuration file that describes jobs and their steps. According to GitHub's documentation, those steps can execute scripts when repository events occur. That means reviewing a new workflow requires looking at what its commands do, as well as its name.
StepSecurity's investigation describes files named security-audit.yml committed under compromised maintainers' identities. The examined workflow ran on pushes and could also be started manually. It collected named Actions secrets, searched the checked-out files and Git history for credential patterns, and sent the result to an external address in an unencrypted web request.
StepSecurity says it examined a run from the affected uber/athenadriver repository in which the receiving server acknowledged the request. That is evidence for a specific observed transmission. It doesn't establish that every repository carrying the file exposed a usable credential, or that stolen keys were subsequently abused.
Socket's 346-repository count includes 279 forks, copies of other projects under one affected account. A fork carrying the file is different from a job that actually ran. Socket warns that inherited workflows can become active when Actions is enabled and subsequent pushes trigger them.
Yesterday's deleted key can still matter
The new payload's history search is the consequential addition. StepSecurity's code analysis shows it collecting earlier changes as well as current files and looking for cloud and service credentials. Its targets include Amazon Web Services keys and keys for artificial intelligence services. Removing a credential from today's source doesn't answer whether an older commit still exposes it.
Consider a hypothetical team that accidentally commits a development service key, then deletes it in the next commit without revoking it. The latest files look clean. A workflow that reads the earlier change can still recover the key. This is an example of the risk the researchers describe, not a reported case involving that team.
GitHub's sensitive-data guidance starts with revoking or rotating an exposed credential. Rewriting history is a separate operation with coordination costs and limitations: copies can survive in clones or forks. One implication is that a clean-looking repository and an unusable leaked key are separate recovery goals.
Inspect the workflow and close its access
For maintainers checking their own projects, StepSecurity supplies search indicators including the history-collection marker AKIA_CTX_START and the filename security-audit.yml. Start with recent additions under .github/workflows and inspect their contents. A plausible filename alone cannot distinguish a legitimate audit from this payload.
If the malicious code is present, the response needs to cover its access as well as its removal. Socket recommends revoking compromised account access, removing the injected workflow, inspecting its run history and rotating exposed credentials. Check the secrets explicitly referenced in the file and credentials found in repository history; those are different sources of exposure.
For prevention, GitHub recommends limiting workflow credentials to the permissions they need and using designated code owners to review workflow changes. Environment secrets can require a reviewer's approval before a job receives them. These controls need to be configured around the way the repository accepts and runs changes.
GitHub also documents OpenID Connect, a way for a workflow to authenticate directly to a supporting cloud provider without storing a long-lived cloud credential. That reduces one category of stored secret. It doesn't remove the need to review the code that requests access or the permissions that access grants.
The initial account-entry method remains unresolved: Socket says it did not observe how the attacker obtained the maintainer credential. Its October 9 report also says it had seen no resulting malicious package versions on the Python and Rust package registries it examined. For a maintainer who finds the payload, the immediate question is still which runs occurred and which credentials those runs could reach.
Sources
Socket: October 9 GhostAction investigation
StepSecurity: workflow code and run-log analysis
GitHub: how Actions workflows run