BuildNot yet confirmed elsewhere1 publisher2 min readPublished
GhostAction's October workflow ran where September's mostly stalled, Socket reports
Two compromised maintainer accounts pushed a GhostAction workflow into 346 GitHub repositories on Oct. 8, according to Socket's research team. GitGuardian, which named the campaign, is still reviewing the wave against its own data.
The Engineer · Build desk
Key figures: 346 repositories hit on Oct. 8, per Socket; 294 repositories hit on the peak September day, Sept. 5, per GitGuardian; 772 public repositories hit between Aug. 31 and Sept. 30, per GitGuardian.
| Figure | Value | Note | Claim |
|---|---|---|---|
| Repositories hit Oct. 8, per Socket | 346 repositories | two automated sweeps lasting minutes | 1 |
| Peak September day, Sept. 5 | 294 repositories | GitGuardian's count | 13 |
| Public repos hit, Aug. 31 to Sept. 30 | 772 repositories | GitGuardian's count | 8 |
What happened
- The workflow, security-audit.yml, went into every repository the two accounts, kitao and henrywoo, could write to, including kitao/pyxel with 18,420 stars and uber/athenadriver.
- GitGuardian counted 772 public repositories across 373 users and organizations hit between Aug. 31 and Sept. 30.
- The exfiltration endpoint is the same bare IP address, 193.32.204.199, that GitGuardian documented in the September wave.
Why it matters
- exposure Exposure follows write access. A maintainer's stolen credentials put every repository that account can push to in range, whatever those repositories' own workflows reference.
- decision Teams have to choose what to hunt on. The workflow name changed three times, while the destination address was the same on Aug. 31 and Oct. 8.
- constraint Every October figure is Socket's, relayed by GitGuardian, which has not yet reconciled it with its own data. The count of 346 and the confirmed exfiltration could still move.
- precedent The technique dates to 2025 and still underlies Mini Shai-Hulud, so another rename or endpoint swap should be expected.
The September payload was narrow. It hardcoded the names of the secrets the attacker found referenced in each repository's legitimate workflows, then posted their values in one curl request [9]. The whole thing is a single job with one curl step, triggered on workflow_dispatch and push [17]. Nothing leaves unless that job runs, and according to GitGuardian most September runs stalled awaiting approval [5].
Socket's account of October removes both limits. The runs executed, and Socket confirms successful exfiltration [6]. The variant also reads the working tree and full git history for cloud credentials [4], so it no longer depends on a workflow naming the secret. A cloud key that was committed once and deleted since remains in history, and on Socket's description it remains in reach. That is our inference: the update does not reproduce the October workflow body.
The two counts may not be like for like. GitGuardian's 772 are public repositories [8], with a peak day of 294 on Sept. 5 [13]. Socket's 346 on Oct. 8, in two sweeps that lasted minutes [1], is 52 more than that peak [19] and about 45% of the month's total [18]. The comparison holds only if the 346 are public repositories too.
Filename rules will not catch this. The campaign has used github_actions_security.yml from Aug. 31 [11], security-check.yml in seven repositories on Sept. 7 [12] and security-audit.yml on Oct. 8 [2]. That is three names [20]. September commits also carried each victim's own identity, apparently via stolen credentials [14], so author filters fail as well. The constant is the destination, a bare IP reached over plain HTTP [10]. In our view that address is the best indicator today, and we'd expect it to rotate: the 2025 wave exfiltrated to domain names instead [10].
Rotation order can follow what September's workflows asked for. Of 2,577 targeted secrets, the largest groups were SSH private keys and deployment server credentials (446), Azure credentials (218) and DockerHub and GHCR registry credentials (142) [15]. We think any repository kitao or henrywoo could write to should have every cloud credential in its tree and history treated as exposed and rotated. Deleting the file from the current tree leaves history intact.
What to watch
- GitGuardian's promised update after it checks the Oct. 8 wave against its own data, including whether the 346 figure holds.
- Whether the exfiltration address moves off 193.32.204.199, as the 2025 domains did.
- Any disclosure of how kitao and henrywoo were compromised; that decides what else those accounts could reach.
Clarity's read
What the record supports and how the coverage leans. The claims behind it follow.
Reality
- Evidence66
- Adoption
- Insufficient
- Hype gap+6
- Incentives
- Insufficient
- Confidence64
Claim ledger
Ranked by verification strength, evidence, and original report placement.
- [1]
On Oct. 8, a new burst hit 346 repositories in two automated sweeps lasting minutes, according to analysis published by Socket's research team.
ReportedSupportedSource: Socket research team, as relayed in GitGuardian's Oct. 9, 2026 updateView cited source - [2]
Two compromised maintainer accounts, kitao and henrywoo, pushed a workflow named security-audit.yml into every repository they could write to, including kitao/pyxel (18,420 stars) and uber/athenadriver.
- [3]
The exfiltration endpoint in the October wave is the same 193.32.204.199 address documented in GitGuardian's earlier analysis.
- [4]
Socket reports that this variant sweeps the working tree and full git history for cloud credentials, not only GitHub Actions secrets.
- [5]
In the September wave, most runs stalled awaiting approval.
- [6]
The October runs executed, and Socket confirms successful exfiltration.
- [7]
GitGuardian says it is reviewing the new wave against its own data and will update the post.
- [8]
Between Aug. 31 and Sept. 30, 2026, the malicious workflow was pushed to 772 public repositories belonging to 373 GitHub users and organizations.
- [9]
Rather than dumping the entire environment, the September workflow hardcodes the names of the secrets the attacker found referenced in the repository's legitimate workflows and sends their values in a single curl POST request to the attacker's server.
- [10]
The 2025 wave used the domains bold-dhawan.45-139-104-115.plesk.page and carte-avantage.com; the 2026 wave sends stolen secrets over plain HTTP to a bare IP address, 193.32.204.199.
- [11]
The new wave that started around Aug. 31 injects a workflow file named github_actions_security.yml into the victim repo.
- [12]
On Sept. 7, a small variant appeared in 7 repositories, with the file named security-check.yml.
- [13]
About 400 repositories were hit from Sept. 2 to 5, with a peak of 294 on Sept. 5.
- [14]
As in 2025, every commit was made with the victim's own identity, using what appear to be stolen credentials.
- [15]
The September-wave workflows target 2,577 secrets; the most targeted are SSH private keys and deployment server credentials (446), Azure credentials (218), and DockerHub and GHCR container registry credentials (142).
- [16]
GitGuardian revealed GhostAction in September 2025; the technique was later reused during the Shai-Hulud campaigns and remains at the core of the Mini Shai-Hulud malware family, which is still used today.
- [17]
The September-wave workflow is a single job, send-secrets, triggered on workflow_dispatch and push, whose one meaningful step is a curl POST of the secret values.
- [18]
Socket's 346 repositories on Oct. 8 are about 45% of GitGuardian's 772-repository total for Aug. 31 to Sept. 30.
- [19]
The Oct. 8 burst of 346 repositories is 52 more than the largest single September day, 294 on Sept. 5.
- [20]
The campaign has used three distinct workflow filenames between Aug. 31 and Oct. 8.
Sources
1 independent publisher whose own reporting we read for this story.
- GhostAction Returns: 772 Repos Hit in New GitHub Actions Wave
blog.gitguardian.com
1 article · October 7, 2026
- dev.toGhostAction Returns: 772 Repos Hit in New GitHub Actions Wave
1 article · October 13, 2026
Topics and entities
Follow any of these and your For You feed starts watching them — no settings page required.