GhostAction's secret-stealing workflows reached 30,000 repos through hijacked developer accounts, researchers say
GhostAction attackers used roughly 1,900 hijacked GitHub accounts to plant credential-stealing workflows in over 30,000 repos. No GitHub Actions flaw was involved, so defence means rotating exposed keys and reviewing who edits workflows.
The Engineer · Build desk
Funnel of the August and September GhostAction campaign, per GitGuardian: 3,669 workflow runs recorded across 605 repositories, 499 of them executed, and 336 completed successfully.
In workflow runs
The last stage as a share of the first: 9.2% computed
| Stage | Value | Claim |
|---|---|---|
| Runs recorded | 3,669 workflow runs | 17 |
| Runs executed | 499 workflow runs | 17 |
| Completed successfully | 336 workflow runs | 17 |
What happened
- The largest wave hit on October 8 and 9: GitGuardian says the attackers got into repositories owned by roughly 3,000 users and organizations and went after 3,174 secrets.
- The malicious jobs targeted CI/CD secrets, cloud access keys and AI provider API keys.
- The attackers disguised the workflows as standard security jobs, using file names such as security-audit.yml and github_actions_security.yml.
- An earlier August and September wave put malicious workflows in 772 public repositories across 373 users and organizations, GitGuardian found.
Why it matters
- Who's exposed exposure A key deleted from a repository months ago is still exposed if it was valid when the history scan ran, so rotation has to cover old commits as well as current code.
- What it limits constraint Deleting the malicious workflow does not close an incident. An account that still has write access can push another one, so revoking its credentials is part of cleanup.
- Who has to decide decision With no published total for stolen credentials, each team has to work out from its own audit records and run histories which secrets a malicious job could reach.
Next story · Security · Oct 9
GhostAction uses hijacked maintainer accounts to plant a secret-stealing 'Security Audit' workflowConfirmed2 publishers
The injected files referenced secrets that legitimate builds already used. When the jobs ran, they could collect those credentials and send them to an attacker-controlled server [8].
How the attackers got the credentials is not settled. A StepSecurity analysis from October 9 names personal access tokens harvested from credential dumps as the most likely source, but the initial compromise has not been confirmed [20]. Rotating PATs covers that likely vector.
The 30,000 figure counts repositories reached [1]. GitGuardian wrote, "This payload was deployed in multiple phases," and described a push to about 160 previously targeted victims followed 20 minutes later by a deployment into 28,000 new repositories across October 8 and 9 [11][12].
The run-level numbers come from the earlier, smaller campaign. In August and September, 499 of 3,669 recorded workflow runs executed, about 14% [17][18]. Of those 499, 336 completed successfully, about 67% [19], and they exfiltrated 26 secrets from 13 repositories [17]. The source says GitHub's approval controls stopped most of the bad workflows [4]. For those ratios to transfer to October, the same gating would have to hold across the 28,000 new repositories [12].
Restricting CI secrets helps against the first variant and only partly against the second. The October variant went beyond the secrets workflows referenced. It pulled the full history with `actions/checkout@v4` and `fetch-depth: 0`, then searched both the current files and past commits for AWS keys, GitHub and GitLab personal access tokens, Google and Firebase keys, and Anthropic, OpenAI and OpenRouter API tokens [9]. Later versions also grabbed the lines around each match, so an AWS key ID could be matched up with its secret access key [10]. The source's remediation list covers revoking, rotating and auditing, with nothing on narrowing CI secrets. In our view, secret scoping narrows what a stolen token can read at run time, and a key already committed is out of its reach.
The cleanup record is thin. Attackers recycled 92 older workflows left behind from earlier attacks, including infrastructure active since September 2025 [4]. By October 5, only 124 of 772 affected repositories, 16%, had been cleaned up [5].
What to watch
- A confirmed source for the stolen tokens. StepSecurity calls PATs from credential dumps the likely route, but the initial compromise is unconfirmed.
- A GitGuardian count of distinct credentials that reached the attackers. Today the only October figure is the 3,174 secrets targeted.
- Whether cleanup of the 772 affected repositories moves past 124, since attackers reused 92 older workflows.
Clarity's read
What the record supports and how the coverage leans. The claims behind it follow.
Reality
- Evidence70
- Adoption
- Not scored
- Hype gap+15
- Incentives
- Not scored
- Confidence72
Perspective Coverage
3 publishers- Builder
- Builder 38%
- Operator
- Operator 52%
- Investor
- Investor 10%
Claim ledger
Ranked by verification strength, evidence, and original report placement.
- [1]
Hackers accessed roughly 1,900 GitHub accounts and used them to slip credential-stealing workflows into more than 30,000 repositories.
- [2]
GitGuardian tracked GhostAction as it intensified, with the biggest push on October 8 and 9, when the attackers reached repositories belonging to about 3,000 users and organizations and tried to extract 3,174 secrets.
- [3]
The malicious GitHub Actions jobs targeted CI/CD secrets, cloud access keys, and AI provider API keys.
- [4]
GitHub's approval controls stopped most of the bad workflows, but attackers recycled 92 older ones left behind from earlier attacks, including infrastructure active since September 2025.
- [5]
By October 5, only 16% of the affected repositories, 124 out of 772, had been cleaned up.
- [6]
GhostAction used stolen developer credentials to modify workflows directly, with no vulnerability in GitHub Actions itself.
- [7]
The attackers added disguised workflows of standard security jobs, using names like security-audit.yml or github_actions_security.yml.
- [8]
The malicious workflow files referenced secrets already used by legitimate builds, which let the malicious jobs collect those credentials when they ran and send them to an attacker-controlled server.
- [9]
The October variant went beyond the secrets explicitly referenced by workflows, using actions/checkout@v4 with fetch-depth: 0 to scan the working tree and Git history for AWS keys, GitHub and GitLab PATs, Google and Firebase keys, and API tokens from Anthropic, OpenAI and OpenRouter.
- [10]
Later versions of the payload captured surrounding lines to pair AWS key IDs with their corresponding secret access keys.
- [11]
"This payload was deployed in multiple phases,"
- [12]
GitGuardian described an initial push to about 160 previously targeted victims and, 20 minutes later, a far larger deployment into 28,000 new repositories across October 8 and 9.
- [13]
GitHub audit records and PAT activity can help identify which accounts modified .github/workflows/, while Actions run histories show which jobs executed and what secrets they could access.
- [14]
Any compromised account still holding write access needs to have its credentials revoked, even if the malicious workflow has already been removed.
- [15]
Cloud keys, deployment credentials, registry tokens, and AI provider API keys potentially exposed during the attack need to be revoked or rotated, including those deleted from the codebase months ago but still valid when the attackers scanned Git history.
- [16]
During the August and September campaign, GitGuardian identified malicious workflows in 772 public repositories across 373 users and organizations.
- [17]
Of the 3,669 workflow runs recorded across 605 repositories in the August and September campaign, only 499 executed, and 336 completed successfully and exfiltrated 26 secrets from 13 repositories.
- [18]
About 14% of the 3,669 recorded August and September workflow runs executed (499 of 3,669, 13.6%).
- [19]
About 67% of the 499 executed runs completed successfully (336 of 499, 67.3%).
- [20]
StepSecurity's October 9 analysis points to personal access tokens pulled from credential dumps as the likely source of the stolen credentials, but the initial compromise has not been confirmed.
- [21]
The total number of stolen credentials remains unknown. GitGuardian counted 3,174 secrets targeted for extraction and confirmed some exfiltration during the October campaign, but did not determine how many distinct credentials reached the attackers.
Sources
2 independent publishers whose own reporting we read for this story.
- scworld.comGhostAction campaign escalates, targeting over 30,000 GitHub repositories
1 article · October 16, 2026
- thehackernews.comGhostAction Compromises About 1,900 GitHub Accounts, Targets Over 30,000 Repositories
1 article · October 15, 2026
- thenewstack.ioHackers hijacked 1,900 GitHub accounts. Then they went after 30,000 repos.
1 article · October 15, 2026