A fake security audit with a real credential-theft payload
Research published on October 9, 2026 describes a new wave of GhostAction, a campaign that uses compromised GitHub maintainer accounts to insert malicious GitHub Actions workflows into repositories. The important development is not just its reach: the payload now searches repository files and Git history for cloud, AI-service, and other credentials, alongside its established theft of named Actions secrets.
The Hacker News reported the activity on October 9, drawing on investigations by StepSecurity and Socket. For engineering teams, the immediate lesson is that removing a secret from the latest version of a file does not revoke it or erase older reachable copies.
What researchers confirmed
StepSecurity's October 9 investigation describes an October 8 burst involving the compromised accounts of Pyxel creator Takashi Kitao and athenadriver author Henry Wu. Their access allowed malicious workflow commits in personal repositories and an organization-owned project, uber/athenadriver.
The initial counts differ slightly: StepSecurity reports 345 repositories, while Socket reports 346, separately counting the Uber-owned repository. These figures describe a closely examined subset, not the full campaign. In an October 9 update, Socket reported more than 500 GitHub accounts committing the workflow to tens of thousands of repositories since October 7. Those broader figures are Socket's reported findings, not a count of repositories independently verified here or of confirmed credential thefts.
StepSecurity examined an athenadriver Actions log and reported that the attacker's collection server acknowledged a request. Socket also documented successful malicious workflow runs. However, successful execution or a received request does not establish that every targeted secret existed, remained valid, or was later abused: the workflow also sends a repository identifier even when it finds no credentials.
The original account-compromise method remains uncertain. Socket did not observe initial access; StepSecurity describes a leaked personal access token as a plausible explanation, not a confirmed cause. This is an abuse of compromised identities and CI permissions, not a newly disclosed GitHub CVE with a software patch.
Why Git history changes the response
The malicious workflows use reassuring names such as Security Audit and Github Actions Security. Researchers found files including .github/workflows/security-audit.yml and .github/workflows/github_actions_security.yml committed under legitimate maintainer identities.
The newer variant combines two collection paths:
- Actions secrets: secret names identified in existing workflows are embedded into the injected workflow, which attempts to collect their values when execution permissions allow access.
- Committed credentials: the payload checks the working tree and fetched Git history for patterns associated with AWS, Anthropic, OpenAI, OpenRouter, GitHub, GitLab, and other services. It also captures nearby text around AWS key identifiers to look for matching secret keys.
The analyzed code fetches full history, but its collection includes output limits and pattern-matching limitations. It should not be described as guaranteed recovery of every historical credential. Defenders should nevertheless investigate all potentially exposed history rather than assume an old or deleted key was safe.
Both paths send data to the same hard-coded address over plain HTTP. Because this does not require a DNS lookup, domain-only monitoring is insufficient. The workflow can be triggered by pushes or manually, making retained copies on other branches and forks relevant during cleanup.
Downstream risk, not proof of poisoned releases
Publishing credentials can allow an attacker to release code under a trusted project's identity. Pyxel's injected workflow explicitly targeted publishing-related secrets, according to both research teams.
That creates a serious supply-chain risk, but it is important not to overstate the evidence. As of their October 9 reports, the researchers had not observed malicious package releases resulting from the compromised publishing credentials they examined. A compromised repository does not automatically mean every previously released package or downstream installation is malicious.
Similarly, an exposed AI or cloud API key creates access and spending risks within that key's permissions; it is not, by itself, evidence that a provider's platform was breached.
What maintainers should do now
The following is defensive guidance based on the research, not a claim that every repository is affected:
- Contain execution and preserve evidence. If an unauthorized workflow is found, suspend its execution and pause affected releases. Preserve the workflow, commit identifiers, Actions logs, and relevant audit records before removing the malicious files from all affected branches. Do not manually run a suspicious workflow to test it.
- Close the account entry point. Revoke the compromised credential and investigate other sessions, tokens, grants, and keys associated with the account. Review every repository that identity could write to, including organization-owned projects. Strengthen account access with phishing-resistant MFA.
- Rotate both classes of exposed secrets. Replace accessible Actions secrets and revoke still-valid credentials found in potentially exposed repository history. Coordinate rotation with service owners. Deleting a file or rewriting Git history is not a substitute for revocation.
- Look beyond the repository. Review package and container registry releases, cloud audit logs, AI-service usage, and billing for the exposure window. Investigate unexpected releases, IAM changes, new keys, and unusual service consumption.
- Inspect forks and mirrors. Check inherited workflow files before enabling Actions or synchronizing from affected upstreams. A workflow file in a fork does not prove that it ran or had access to upstream secrets; establish the actual execution context.
- Harden workflow changes. Require reviewed changes to workflow files, enforce branch rules, restrict bypass privileges, limit secret exposure, and monitor runner egress. Secret scanning and push protection help reduce committed-key exposure. Short-lived federated credentials can reduce reliance on stored cloud keys, but still require tightly scoped trust policies.
Defensive indicators
Use these as investigation leads, with workflow content and execution evidence providing context:
- Reported collection address:
193.32.204[.]199(defanged); StepSecurity reports campaign use of ports 80 and 3000. - Workflow names:
security-audit.ymlandgithub_actions_security.ymlunder.github/workflows/. - Payload markers:
AKIA_CTX_STARTandAKIA_CTX_END. - Suspicious change pattern: unexpected security-audit workflow additions under a maintainer's identity, particularly rapid commits across multiple repositories.
A benign workflow can share a generic filename, so the name alone is not proof of compromise. Review historical changes as well as current files; the researchers recommend looking back to August 31, 2026 for related activity. Default-branch code searches alone can miss forks, other branches, deleted files, or unindexed content.
Bottom line: treat an unauthorized workflow as an identity and credential incident, not merely an unwanted YAML file. Secure the account, establish what executed, revoke exposed access, and verify downstream activity before resuming releases.
Sources
- The Hacker News: Credential-Stealing GitHub Actions Workflows Planted in Tens of Thousands of Repositories, October 9, 2026.
- StepSecurity: GhostAction Returns, October 9, 2026. Primary workflow and execution-log analysis.
- Socket: New GhostAction Wave Hits Hundreds of Repos, Expanding Beyond CI/CD Secrets to Cloud Credentials, October 9, 2026, including its same-day scope update.
Prepared October 10, 2026 from the cited October 9 reporting. Campaign counts and remediation status may change as investigations continue.
