GhostAction: 345 repositories in two sweeps, 81% forks; "tens of thousands" has no count behind it

Three vendors, three counts: 345, 772, and "tens of thousands" with no number

StepSecurity's post GhostAction Returns, dated 9 October 2026, counts 345 repositories that a workflow named like a security audit was pushed to in two automated sweeps on 8 October: 27 through one compromised maintainer account and 318 through another (derived: 27 plus 318, which StepSecurity prints as 345). Of the 318, 279 were forks, so forks were at least 80.9% of the 345 (derived). Socket's report counts 346. GitGuardian's post counts 772 public repositories, belonging to 373 users and organisations, over the 31 days from 31 August to 30 September. And one update line at the top of Socket's report says more than 500 accounts committed the workflow to "tens of thousands of repositories" since 7 October. That line gives no number, no list and no method, and the time printed on it is an unfilled placeholder. The Hacker News put the phrase in its headline.

These are not rival measurements of one thing. One counts pushes made on one day, one counts public repositories over a month, and one counts nothing a reader can check. Between 345 and the lowest reading of "tens of thousands", which is 10,000, the factor is 29; at 20,000 it is 58 (derived). A fourth count, from StepSecurity's own GitHub code search, found 378 repositories with the workflow live on a default branch on 9 October: that measures what is still sitting there, not what was hit. Even inside one source the units split. GitGuardian counted 2,577 secrets that its September-wave workflows named, and saw 26 secrets leave, from 13 repositories: a factor of 99 (derived).

Who counted what, as each source prints it. Figures marked derived are ours. Read on 10 October 2026. Each vendor sells security products and has an interest in a large number.

Source (and what it sells)	What it counts	What it does not say
StepSecurity, 9 Oct (runner and workflow security software)	345 repositories pushed to on 8 Oct in two sweeps: 27 at 13:20 to 13:44 UTC, 318 at 21:10 to 21:26 UTC. The 318 are 39 source repositories and 279 forks. One run log shows the server acknowledged the data.	How many of the 345 ran. Whether any of the 27 are forks.
StepSecurity code search, 9 Oct	378 repositories with the workflow live on a default branch; 182 carry the history-sweep marker and 88 the named-secrets marker. Default branches only, forks excluded; "approximate" and drifting daily.	Forks. Index lag. How many have been cleaned.
Socket report, 9 Oct, 12:07 UTC (software supply chain security)	346 repositories on 8 Oct: 318 under one account (39 source, 279 forks), 27 under the other, and one organisation-owned repository that account could write to, listed apart.	A split of the 27. How many runs succeeded.
Socket update line, added after 12:07 UTC	More than 500 accounts, "tens of thousands of repositories" since 7 Oct.	A number, a list, a method, whether forks count, or the time: the line prints "[HH:MM] UTC".
GitGuardian, 7 Oct, updated 9 Oct (secrets detection)	772 public repositories, 373 users and organisations, 31 Aug to 30 Sept. 2,577 secrets named in the workflows; 26 seen leaving, from 13 repositories; 124 repositories (16.1%, derived) cleaned by 5 Oct.	Private repositories or forks. Anything after 30 Sept except one update citing Socket.
The Hacker News, 9 Oct (news)	Headline "tens of thousands"; text "over 340 repositories".	Any source for either figure beyond the two vendors.

A fork carrying the file is not a run

Socket and StepSecurity both say the 279 forks under the second account each carry the workflow file. GitHub's documentation on events that trigger workflows says: "Workflows don't run in forked repositories by default. You must enable GitHub Actions in the Actions tab of the forked repository." So a fork carrying the file does nothing until someone enables Actions on that fork. Socket says as much: "If Actions are enabled, subsequent pushes can trigger credential harvesting." Neither vendor says how many of the 279 had Actions enabled, and neither says whether any of the 27 repositories in the first sweep are forks.

That matters for the unit. In StepSecurity's count, at least 80.9% of the 345 are forks (279 of 345, derived), and 87.7% of the second account's 318. A fork is a copy of another repository, history included, so a run on a fork would sweep the history its upstream's authors committed, which is where Socket says "committed credentials are actually found". It would not reach the upstream's Actions secrets (our inference: those belong to the upstream repository). The value of a fork to the attacker is therefore the history and the map: Socket notes that every run reports a repository identifier whether or not credentials were found, so the operator holds "a map of reachable execution contexts".

Two further limits. StepSecurity's code search excludes forks, so it says the 279 sit on top of its 378. And Socket says downstream forks and mirrors are at risk if they inherit the file, either when created or by synchronising with an affected upstream. An organisation that forked a project from one of the compromised accounts should check the fork, not only its own repositories.

The timeline, and a rate no person could keep

Timeline from the vendors' pages. Times are UTC; BST is one hour ahead. Page timestamps come from each page's metadata. Durations are derived.

When	What	Source
Mon 31 Aug, about 14:00	First burst of the September wave: 143 repositories that day. Three bursts (31 Aug, 2 to 5 Sept, 15 Sept) hold about 646 of the 772 (83.7%, derived).	GitGuardian
4 and 5 Sept	The current destination shows in honeypot records on 4 Sept and in the earliest infected repository StepSecurity analysed, on 5 Sept.	StepSecurity
Thu 8 Oct, from 13:20	First sweep, 27 repositories. StepSecurity: 13:20 to 13:44, first commit 13:20:36 on the best-known repository, workflow started by hand at 13:36 and 13:42. Socket: a four-minute window, 13:40 to 13:44.	StepSecurity, Socket
Thu 8 Oct, 21:10 to 21:26	Second sweep, 318 repositories (Socket: 21:10:15 to 21:26:32). The last was committed at 21:25:54 and its run was acknowledged by the server at 21:26:04.	StepSecurity, Socket
Fri 9 Oct, 12:07	Socket publishes with 346 repositories and "hundreds" in its title (publication time from its metadata).	Socket
Fri 9 Oct, 15:49	GitGuardian's post last modified; its update cites Socket's 346 and says it is reviewing the new wave.	GitGuardian
Fri 9 Oct, 17:55	Socket's page last modified. The "tens of thousands" line was added after 12:07 and by now (our inference from the two stamps).	Socket
Sat 10 Oct, from 07:36	This reading; the three vendor pages were read again near the end.	This briefing

From the first push at 13:20 to the start of the second sweep at 21:10 is 7 hours 50 minutes (470 minutes, derived), which StepSecurity rounds to eight hours. The second sweep put the file into 318 repositories in 16 minutes, about 20 a minute (derived); on Socket's seconds, 977 for 318, that is one repository about every 3 seconds. Socket calls the burst "tool-driven rather than hand-performed" and notes that decade-dormant repositories were swept alongside active ones, which fits enumeration and not selection. StepSecurity says the commits carried the victim's own identity, were unsigned and went straight to the default branch, so nothing in an audit log looks wrong unless the workflow's contents are read.

The two vendors do not agree on the first sweep's length: 24 minutes at StepSecurity's 13:20 to 13:44, or four at Socket's 13:40 to 13:44. Both fit if one repository was committed alone at 13:20 and the other 26 at 13:40 to 13:44, but neither source says so (our reading). From the first push to Socket's post is 22 hours 47 minutes; from the end of the second sweep it is 14 hours 41 minutes (derived). Both sweeps were over, by the vendors' dates, before either report was written.

"Tens of thousands": one sentence, no number

In the pages we read, the claim exists in one place: the update paragraph at the top of Socket's report. It says Socket "has identified more than 500 GitHub accounts that committed the malicious workflow to tens of thousands of repositories since October 7, 2026, including several organization-owned ones". Below it, Socket's own title, description and body still say "hundreds" and 346. The update's time reads "[HH:MM] UTC", an unfilled template slot, so the moment of the count is not stated. The Hacker News repeats the sentence in its headline and its description, and its text says "over 340". Our searches found no other report of the 8 October wave that gives a count.

What the sentence implies depends on arithmetic that does not settle it. If "tens of thousands" means at least 10,000 across 500 accounts, that is at least 20 repositories per account; at 20,000 it is 40 (derived). GitGuardian's September wave averaged 2.1 repositories per owner (772 over 373, derived), and the 8 October pair about 172 each (345 over 2, derived), mostly forks. So the figure is possible if a few hundred accounts each held dozens of forks, and equally consistent with a far smaller number: the sentence states no unit and does not say whether forks are included.

Take it at face value for a moment. GitGuardian's September ratio is 3.34 secrets named per repository (2,577 over 772, derived), so 20,000 repositories would be about 66,800 named secrets (derived; an illustration, not an estimate). It would not hold for a population dominated by forks, which are copies carrying the upstream's history and not its Actions secrets (our inference). What a reader can conclude is narrow: Socket says it holds a count larger than the one it published, the claim is the vendor's own, and there is no method to check. A board paper should carry "Socket says more than 500 accounts, count unpublished", not "tens of thousands of repositories".

Against 2025: the unit changed, and so did the base

GitGuardian's September 2025 report is the baseline: 817 repositories, 327 users and 3,325 secrets. Its 2026 post counts 772 repositories, 373 users and organisations and 2,577 secrets. The temptation is to read 2,577 against 3,325 as a smaller theft. The two are not the same measure. The 2025 report describes the 3,325 as leaked and exfiltrated; the 2026 post says the workflows "target" 2,577 secrets, meaning the names written into them, and separately counts the 26 it saw leave.

GitGuardian's two reports side by side. Secrets per repository and the cleaned shares are derived.

Measure	September 2025 report	Autumn 2026 report
Repositories	817 (about 900 in its 2026 retrospective table)	772 public repositories, 31 Aug to 30 Sept
Users or owners	327 users	373 users and organisations
Secrets	3,325, described as leaked and exfiltrated	2,577 targeted: the names written into the workflows
Secrets per repository	4.07	3.34
Seen leaving	Not separated from the 3,325	26 secrets from 13 repositories, in 336 completed runs
Cleaned	100 of 817 already reverted at disclosure (12.2%)	124 of 772 by 5 Oct (16.1%)

Two points follow. First, the 2025 figure has itself moved: GitGuardian's 2026 retrospective table gives about 900 repositories for September 2025, about 10% above the 817 printed then (derived), so the baseline is not fixed either. Second, secrets per repository fell from 4.07 to 3.34, a ratio of 0.82 (derived), which says the typical victim's workflow named fewer secrets, not that less was stolen. The October sweep of 345 repositories would add 44.7% to the 772 if it fell in the same window; it does not, and GitGuardian has not counted it.

Did it run? The count that matters, and the one setting that stopped it

A repository count measures injection. Theft needs the workflow to run. GitGuardian matched its September repositories to their Actions run records: of 3,669 runs it collected across 605 repositories, only 499 executed (13.6%, derived), in 32 repositories (5.3% of the 605, derived). GitGuardian says GitHub held most runs for approval. Because the workflow triggers on every push, GitGuardian says those runs were mostly caused by legitimate commits made after the injection and not by the injection itself. In total 336 runs completed successfully, "exfiltrating 26 secrets from 13 repositories". Set against 772 repositories and 2,577 named secrets, that is 1.7% and 1.0% (derived).

October looks different. GitGuardian's 9 October update says: "Unlike the September wave, where most runs stalled awaiting approval, these runs executed." StepSecurity's evidence is two repositories. In the organisation-owned one, the run log shows the checkout of every branch and tag, then a reply from the attacker's server four seconds after the run began. In the best-known repository of the first sweep, the workflow ran five times, all successful, twice started by hand from the compromised session. Socket says only that the workflow "has run successfully in affected repositories". So what is shown is two repositories with confirmed runs among the 345, and no published count of the rest.

StepSecurity also reports the one thing that stopped it. A repository infected since early September was re-triggered on 7 October by an empty commit and a small edit to its readme, from a compromised account. Both runs stalled in an "action_required" state because, StepSecurity says, the repository requires approval for workflow runs, and "the exfiltration did not execute". It calls the approval gate "the single control observed stopping this campaign's exfiltration this week". Treat that as an observation to test, not a guarantee. The GitHub pages we read, on repository Actions settings, describe approval for workflow runs on pull requests from forks, with a user with write access approving. They do not explain why a push by a compromised account stalled, and StepSecurity does not say which setting or role applied. In the organisation-owned repository's run log, the workflow's token had read-only access to repository contents, so the workflow could not itself push or publish: the harm depends on the secrets it reads.

Friendly names: a "security audit" file and a "GhostAction" actor

The file is named like a security audit, and the commit message said it was adding one. That is the whole disguise, and it worked because a name is not a control. Nobody who reads a list of changed files and sees a security workflow has been shown what the workflow does. The earlier briefing on GitHub Actions that were disabled and came back made the same point from the other side: a label on a repository, or a tag that points at it, says nothing about what is behind it. Defenders should read what a new workflow runs and where it sends data, not what it is called.

The second friendly name is "GhostAction". It names a template: a workflow with named secrets written into it, committed under the victim's identity. GitGuardian's history for that template runs from about 900 repositories in September 2025, to about 75 between October and December 2025 and in March 2026, to about 250 in November 2025 and in March and April 2026, to 772 in August and September 2026, each with a different destination. In 92 cases the attacker did not add a file but edited a workflow already there, repointing it at the new destination. That is evidence of one template in continuous use, not of one operator.

GitGuardian is direct about the limit. It found 13 victim repositories that had also been used for mining through Actions, from at least four distinct mining campaigns, and concludes the stolen GitHub credentials "are not exclusive to its operator": tokens, infostealer logs and credential dumps are traded and reused. It examined a miner planted in a project of about 6,000 stars, found it differed in almost every respect from the workflow, and wrote: "We are not convinced." The Hacker News states that "the threat actors altered" that project to embed the miner. Where the article and the vendor's page disagree, this briefing follows the vendor's page. The practical consequence is GitGuardian's: removing the workflow without finding and revoking the GitHub credential that allowed the push leaves the door open for the next holder of that token.

Who counted, and what each sells

All three vendors are treated the same way here. StepSecurity sells runner and workflow security software, its post ends with advice on its own product, and it benefits when a campaign looks large and live. Socket sells software supply chain security, and its update line is the biggest figure in the story with the least behind it. GitGuardian sells secrets detection, counts only public repositories it can see, and benefits when exposed secrets look numerous. None of that makes a count wrong. It is the reason each count is reported with its unit, its dates and its method, or the absence of one, and none is taken from the news article. Where the vendors share data they agree: the same two accounts, the same second window to the minute, 39 and 279 for the split, and no malicious package release seen.

What is established, and what is not, from the three vendor pages, the news article and GitHub's own pages. Our reading, 10 October 2026.

Claim	What the sources establish	What they do not
The workflow went into hundreds of repositories on 8 October	Both vendors list 345 or 346, from two accounts, from commit data.	How many ran. How many forks have Actions enabled.
Credentials were taken	One run log shows the server replying; five successful runs in another repository; Socket and GitGuardian say exfiltration succeeded.	Which secrets, how many, or that any was used.
Packages were poisoned	StepSecurity and Socket saw no malicious release from the stolen publishing credentials as they wrote (Socket: on PyPI and crates.io).	That the credentials are safe, which StepSecurity says outright.
One actor is behind it	One template; one destination since early September (StepSecurity first saw it in use on 5 Sept).	A single operator. GitGuardian is not convinced about the miner, and says tokens are traded.
The way in was a leaked token	StepSecurity: "most plausibly" a leaked personal access token from infostealer logs or credential dumps.	Socket "did not observe how". No token or leak is identified.
GitHub has acted	Nothing found: GitHub's blog search for the name was empty and its changelog for 1 to 9 Oct has no entry on the campaign.	Whether the two accounts are secured, or the workflows removed.
It is a vulnerability	No: the CISA catalogue (version 2026.10.08, 1,739 entries) has no entry for it, and an NVD keyword search for the name, over CVEs published from 1 August 2026, returned none.	Anything about exploitation of a software flaw; none is described. The method is stolen credentials.

What UK organisations can lean on, and where it stops

Start with what is in the pipeline. GitGuardian's count of the 2,577 secrets the September workflows named is a picture of what developers keep in Actions secrets: SSH keys and deployment server credentials (446), Azure credentials (218), DockerHub and GHCR registry credentials (142), database credentials (112), AWS access keys (106), FTP credentials (92), Google Cloud and Firebase credentials (80) and GitHub tokens (66). Those eight kinds are 1,262 of the 2,577 (49.0%, derived); the rest include bot tokens for chat services and keys for Cloudflare, npm, PyPI and AI providers. The October payload goes further, into history: it looks for 13 credential patterns in the working tree and in every branch and tag, including keys from three AI providers (Anthropic, OpenAI and OpenRouter), and pairs AWS key identifiers with their secrets. Our reading of what they reach: SSH keys open servers, cloud keys open storage and databases, registry credentials reach what runs in production, and database credentials reach data stores, the likeliest route to personal data. A secret committed in 2019 and deleted the next day is still in the history, and rotating today's Actions secrets does not touch it.

No NCSC notice on GhostAction was found in the pages read. What the NCSC has published still applies. Its guidance on securing your development environment (published 20 February 2019) says to consider the environment compromised, because an attacker "will inherit the same level of permissions and access as that developer", and that multi-factor authentication and "a multi-person review process as part of your deployment pipeline" limit the onward damage. Its blog Software supply chain attacks: check your dependencies (4 June 2026) lists maintainer account compromise as a technique and tells defenders to rotate exposed credentials and enforce multi-factor authentication on developer and registry accounts. The Software Security Code of Practice asks vendors to protect the build environment against unauthorised access (principle 2.1) and to control and log changes to it (2.2). None of the three mentions this campaign.

What Cyber Essentials v3.3 (April 2026) says, and does not say, that bears on this campaign. We searched the full text for secret, API key, token, git, repository, source code, CI/CD, pipeline and credential.

Topic	What the requirements say	What they do not say
Multi-factor authentication	"authentication to cloud services must always use MFA"	Anything about tokens, API keys or CI secrets used by software; the text is about users. GitHub says a personal access token has the capabilities of its owner, within its scopes.
Scope	"Cloud services cannot be excluded from scope." Accounts the organisation owns are in scope even when a supplier uses them.	Repositories, source code, build pipelines or git history. Bespoke and custom components of web applications are out of scope, with a pointer to the Code of Practice.
Secrets	Nothing.	The words secret, API key, repository, source code, CI/CD and pipeline do not appear. "Token" appears only for hardware tokens as an MFA factor.
Suppliers	Accounts you own that a supplier uses are in scope.	Your keys that sit in a supplier's repositories or in their history.

So Cyber Essentials certification does not reach CI secrets, tokens or git history. That is not a flaw in the scheme; it is a boundary, and it belongs in a risk register so that nobody reads the certificate as covering it.

The ICO angle comes in only if a stolen key reaches personal data. A stolen credential is a security incident. It becomes a personal data breach, in the ICO's words, when there is "unauthorised disclosure of, or access to, personal data", and the ICO says to assess that case by case. If a database or storage key was in a workflow or in history, the questions are whether logs show it was used and whether you can show it was not. A notifiable breach must reach the ICO "within 72 hours of becoming aware of the breach, where feasible", and the ICO's guide says to notify even without all the details. A processor must tell its controller without undue delay, with the terms set in the contract. The guide does not say when you "become aware" of a stolen key that has not yet been used; that is a question for your data protection officer or a lawyer.

The supplier question is the one most organisations skip. StepSecurity says one compromised account carried the attack into an organisation-owned repository because the account's owner had kept write access. That is the pattern: a broad token reaches every repository its owner can write to, and your keys may sit in repositories you do not control, a contractor's pipeline, an agency's integration project, a supplier's SDK or a fork a developer made two years ago. Ask which of your suppliers' and contractors' repositories hold your keys, and who at the supplier would tell you.

What to do, in the order worth doing it

The question that exposes the gap

If a supplier's maintainer token leaked tonight and a file named like a security audit went into every repository it could write to, which of your keys sit in those repositories and in their history, and how many of the 72 hours would be gone before anyone told you?

That is the gap three vendor counts cannot show: they say how many repositories were hit, in three units, but not whether yours is among them, whether the workflow ran, or whether anyone has told you. The earlier briefing on a worm release that sat on the npm registry for about 102 minutes shows the same gap from the registry side, and the one on disabled actions that came back shows it from the repository side.