What happened
GhostAction was first documented in September 2025, but the materially new wave expanded collection into complete Git histories. On October 8, 2026, StepSecurity says two compromised maintainer accounts pushed the malicious workflow into 345 repositories: 27 through the kitao account and 318 through the henrywoo account. The injected file was security-audit.yml, and the workflow used git log -p –all to scan every branch and commit history for 13 credential patterns before sending findings over plain HTTP to 193.32.204[.]199. The collection targeted configured GitHub Actions secrets and credentials for cloud, source-control, SaaS and AI providers that remained recoverable from source files or prior commits.
StepSecurity counted about 378 repositories with the malicious workflow active on a default branch on October 9, 2026. In uber/athenadriver, Blacktree reports that the collection server acknowledged a workflow request within four seconds. Sunday, October 11, 2026 reporting clarified that deleting the workflow alone does not close credentials recoverable from Git history. Published repository totals vary because researchers counted different periods and states, including injected repositories, still-active workflows and earlier campaign activity; Security.io therefore uses the directly documented 345-repository sweep for the current-wave baseline. Attribution posture: The cited sources do not establish whether the October wave was the original GhostAction operator or a copycat.
Why this matters now
The October wave changes the response boundary from the current repository configuration to every credential ever committed to reachable history. Deleting the malicious workflow or rotating only named Actions secrets does not address cloud, source-control, package-registry or AI-provider keys recovered from earlier commits. Security teams need to join repository, identity, secrets-management and cloud evidence rather than treating the event as an isolated source-code change.
Maintainer identity is the control failure. The malicious workflow was committed under trusted accounts and reached default branches without the warning signals defenders expect from an unknown contributor or untrusted pull request. Organisations consuming open-source projects also need to examine whether releases, packages or build inputs changed after the maintainer compromise, while avoiding unsupported assumptions that GitHub’s platform itself was breached.
The decision for security leaders
Treat repository history as an active secret store until proved otherwise. Rotation scope should be based on historical exposure and credential privileges, not whether a key appears in the current branch.
Require application-security, cloud and identity teams to share one incident record linking repository findings to credential revocation, cloud audit logs, package-publishing activity and downstream automation. This prevents each team from closing only its local symptom.
Strengthen software-supply-chain trust with protected workflow paths, required review for default-branch changes, constrained GITHUB_TOKEN permissions and runner-egress allowlists. Maintainer status should not bypass controls protecting executable workflow definitions.
Evidence of closure
- Repository search results identify and disposition every security-audit.yml instance.
- Credential records prove revocation and replacement of every historically exposed secret.
- Cloud and registry logs contain approved findings for post-exposure credential use.
- Workflow protections require reviewed changes to executable default-branch definitions.
The Security.io assessment
The evidence supports maintainer-account compromise, malicious workflow execution and outbound collection behaviour. It does not establish a compromise of GitHub’s underlying platform, and it does not prove that every targeted repository yielded usable credentials.
Scale estimates remain unsettled because sources count different units and periods. That uncertainty should not delay local action: security-audit.yml and 193.32.204[.]199 provide concrete search points, while the named compromised accounts define an initial repository boundary.
The broader lesson is that trusted developer identity can become a distribution mechanism. Repository cleanup is incomplete until stolen authority and historical credentials are invalidated and subsequent use is checked in cloud, registry and source-control logs.
Questions for the morning meeting
- Can security search every organisation-owned repository and fork for security-audit.yml and its exfiltration address?
- Which credentials have ever appeared in reachable Git history, even if deleted from current files?
- Are workflow-file changes protected by review and runner-egress controls?