GhostAction stage two, 19 October 2026: 94 repositories, 66 owners, a "font" that is a script

94 repositories, 66 owners: what the count measures and what it does not

OpenSourceMalware's post of 16 October 2026 counts 94 GitHub repositories carrying a second stage of the GhostAction campaign, belonging to 66 owners: 1.42 repositories per owner (derived). Fifteen of the 94 have since been deleted, renamed or made private, so the researchers could clone 79, and they say all 79 carried the second stage. Of those 79, 65 (82.3%, derived) had gone more than a year without a commit when the first malicious commit landed, and the oldest had been untouched for more than nine years. The Hacker News repeated the figures on 19 October.

Those are the figures of one hunt. A Jamf Threat Labs researcher, looking for victims of a different campaign, found the cluster and submitted it to OpenSourceMalware, which wrote it up. The number counts repositories that carry three planted files. It does not count developers phished, tokens stolen, machines that ran anything, or secrets taken by the second stage. OpenSourceMalware ties the second stage, which arrived six days after GitHub began preventing the first stage's workflow from running, to no cause: "We can't say the block caused it."

Stated and not stated. Sources: OpenSourceMalware posts of 9, 11 and 16 October and its show of 15 October 2026, GitGuardian's update of 13 October, The Hacker News of 19 October. Read on 19 October 2026.

Item	Stated, and by whom	Not stated
94 repositories, 66 owners	OpenSourceMalware, 16 Oct: a cluster found by a researcher and submitted. 79 cloned, and all 79 carried the second stage.	How the cluster was bounded. Whether more exist. What the 15 gone carried, since they could not be analysed.
Dormant repositories	OpenSourceMalware: 65 of 79 had no commit for over a year at the first malicious commit, 47 over two years, 28 over three, the oldest over nine; median 792 days.	The same figures for the 15 gone. Whether anyone still clones them.
What the planted script does	OpenSourceMalware read it without running it: it reads credential files and keys, posts them over plain HTTP and installs a five-minute scheduled job.	That it ever ran on a machine. What the server returns: OpenSourceMalware says it cannot tell what a third stage does.
The 9 October block	GitGuardian, 13 Oct: GitHub started preventing the malicious workflow from running; two later waves extracted no secrets.	What the block is. Any GitHub statement. That it caused stage two.
How the 94 were reached	OpenSourceMalware: pushed under each owner's identity at scripted speed.	Stolen tokens, phishing or something else.
Who is behind it	OpenSourceMalware: a copycat of a launcher PolinRider used, with no shared indicators with other North Korean malware it has seen.	Any attribution. A co-founder told The Hacker News the operator seems to have limited experience: an opinion.

The dates in order, and a gap nobody can attribute

Times are UTC, and the UK is on BST, one hour ahead, until 25 October. Each row names the page it comes from. The intervals of 17 days and six days are stated by OpenSourceMalware and reproduced by our arithmetic; the others are marked derived.

Timeline from OpenSourceMalware, GitGuardian and The Hacker News. Read on 19 October 2026.

When (UTC)	What	Source
Tue 22 Sep	A GitLab-themed look-alike domain is registered. OpenSourceMalware says it is not proven malicious and not linked to GhostAction.	OpenSourceMalware, 9 Oct
Thu 8 Oct, 13:03 to 22:41	The first stage-one workflow lands on 72 of the 79 reachable repositories, one automated run per compromised account.	OpenSourceMalware, 16 Oct
Fri 9 Oct, 09:50	A GitHub-themed look-alike domain is registered, 17 days after the GitLab-themed one. OpenSourceMalware says it was used in a phishing lure the same day.	OpenSourceMalware, 9 and 11 Oct
From Fri 9 Oct	GitHub started preventing the malicious workflow from running (GitGuardian). The waves of 10 and 12 Oct extracted no secrets.	GitGuardian, 13 Oct
Sun 11 Oct, 21:49	OpenSourceMalware publishes the phishing kit analysis.	OpenSourceMalware, 11 Oct
12 to 14 Oct	Four more repositories receive stage one. Stage one is rewritten in dozens: the collection address moves to a different port and the batch tags become date-stamped.	OpenSourceMalware, 16 Oct
Wed 14 Oct, 13:23 to 18:58	The second workflow appears in three repositories; their font and task files follow 7 to 14 hours later.	OpenSourceMalware, 16 Oct
Thu 15 Oct, 01:00 to 10:31	Stage two lands in 76 repositories, the second workflow, the "font" and the task together; 32 in the first two hours.	OpenSourceMalware, 16 Oct
Fri 16 Oct, 05:15	OpenSourceMalware publishes the stage-two analysis.	OpenSourceMalware, 16 Oct
Mon 19 Oct	The Hacker News reports it. This reading ends the same evening.	The Hacker News

Two derived intervals matter. From the block on 9 October to the burst on 15 October is six days, as OpenSourceMalware states, and five days to the first three repositories on 14 October. OpenSourceMalware's median gap between the two stages is 6.3 days, with 80% of repositories between 6.1 and 6.7 days, and it reads that as a calendar decision: "Someone decided that October 15 was the day." The four repositories that received stage one as late as 12 to 14 October received stage two on 15 October too, one of them 26 hours later.

The other interval is the one that separates the phishing from the 94. The 72 first stage-one pushes of 8 October ran from 13:03 to 22:41 UTC; the look-alike GitHub domain was registered at 09:50 UTC on 9 October. That is between 11 hours 9 minutes and 20 hours 47 minutes after the last and the first of those pushes (derived). Whatever gave the operator the access to push on 8 October, it was not a phishing kit on a domain that did not yet exist. OpenSourceMalware says as much of the first repository it followed: "We haven't tied the kit to these 94 repositories. For the first one we examined, the first malicious push predates the domain."

Three files and a scheduled job: four labels doing the work of a control

OpenSourceMalware describes stage two as three files in the repository and one scheduled job on the developer's machine. It prints their names, paths, settings and addresses for hunters. This briefing prints none: it describes what to look for, and the page is linked above for anyone who needs the indicators.

The four labels, and what OpenSourceMalware says is behind each. Source: its post of 16 October 2026.

What it is called	What OpenSourceMalware says it is	What the label invites
An editor task labelled like a routine lint check	A VS Code task set to run when the folder is opened, with settings that keep it out of sight. Byte-identical in all 79 repositories.	That nobody reads a lint task.
A font, in a font folder, named like a common icon font	38 lines of plain Node.js. "Node doesn't care about the extension, so it runs."	That a font file is inert data.
A second workflow with a generic continuous-integration name	Stage one with more credential patterns and a fallback that uploads findings to a secret gist. It is there "in case the infostealer never runs".	That it is ordinary CI.
No label: a scheduled job on the machine	Installed by the script. Asks the server for a script every five minutes and runs what comes back, at an address keyed by the machine's hostname.	That cleaning the repository ends it. OpenSourceMalware: deleting the font file "doesn't cancel the cron job".

That is the friendly-name fallacy four times in one commit set. The first-stage workflow was named like a security audit. The second stage is named like lint, like CI, like a font. A reader who sees a label and stops has done what the label asked. The controls that would have caught it look at behaviour: a workflow that posts to an address outside the organisation, a task that runs when a folder is opened, a file in a font folder that is text and not a font.

What the script reads. OpenSourceMalware lists what it reads directly: eight credential files (cloud, two package registries, stored git logins, a general network-login file, the stored logins of Anthropic's Claude and Google's Gemini tools, and Kubernetes) and two kinds of SSH private key, read in full. It then searches the home folder for token patterns (AWS, Anthropic, GitHub, npm, PyPI) and adds environment variables whose names begin with AWS, Anthropic, OpenAI or GitHub token names, or one other provider's token name. Everything goes out in one request over plain, unencrypted HTTP to a hardcoded numeric address. OpenSourceMalware spotted two flaws and did not test either: the environment filter misses most real key names, and the home-folder search can time out and throw away what it found. Neither touches the direct reads. It adds that on Windows there is no crontab, so the credential theft would run but the job would not install.

Where the reports differ. The Hacker News lists eight file names for the second workflow. OpenSourceMalware's text gives seven, each in 5 to 16 repositories, and describes an eighth, a third workflow aimed at self-hosted runners, in one repository: its indicator list groups all eight. The Hacker News also says the font file name matches one used in North Korea's PolinRider campaign "from January 2026". OpenSourceMalware says the January file had a different name and that PolinRider used this one for most of 2026. It describes the launcher as copied from PolinRider with the payload replaced, and says: "we're labeling this a copycat rather than an extension of PolinRider". This briefing follows OpenSourceMalware's page.

One of the 79 repositories also carried a separate PolinRider loader in other files, added months earlier. OpenSourceMalware found no indicator shared between that loader and stage two, and says it does not know who ran either push. A name that matches, a launcher that was copied, and a repository that holds both are not an attribution, and nothing in the record establishes a link to any state.

The 9 October block: whose words, and what is it?

The headline sentence of the second-stage story is that GitHub began preventing the malicious workflow from running on 9 October and the operator moved to somewhere that control does not reach. Check who says the first half.

Who says GitHub prevented the workflow, and on what evidence. Read on 19 October 2026.

Source	What it says	Basis
GitGuardian, update of 13 Oct	"GitHub started preventing the malicious workflow from running starting October 9." The two later waves "could not extract any secrets".	Its own run records: its table marks the batches of 8 October executed and the 84 commits of 10 October and 65 of 12 October not executed.
OpenSourceMalware, 16 Oct	The same sentence. Its own timeline table attributes it: "According to GitGuardian, as reported by The Hacker News".	A relay.
The Hacker News, 19 Oct	Quotes OpenSourceMalware.	A relay of a relay.
GitHub	Nothing found. Forty changelog entries dated 2 to 19 October, read through the changelog feed, carry none on this. A search of the GitHub blog for the campaign name returns no result.	Not a finding that GitHub did nothing: only that no GitHub description of the block was found.

So "blocked" is one vendor's reading of run records, repeated twice, with no GitHub account of what the block is. OpenSourceMalware's own nearby evidence points at something narrower. Its post of 9 October says StepSecurity reported that workflow approval was the control seen stopping exfiltration in the 8 October wave, and in the one repository its stage-two post followed, nine of ten workflow runs were held awaiting an approval nobody gave. An approval gate is a setting an owner can choose; the sources do not say whether the gate and the platform block GitGuardian describes are the same thing (our inference). GitGuardian's table marks the 8 October batches, the largest of 29,431 commits, as executed, and only the two small batches of 10 and 12 October as not.

What a block on one path does not do is cancel the operator's access. OpenSourceMalware found two repositories whose owners removed the stage-one workflow on 9 October and received stage two on 15 October, and reads it plainly: "Whatever pushed the first stage still had access six days later." Its advice: "Deleting files doesn't revoke the token that pushed them." In the repository it followed, the owner deleted both workflows with a commit titled as a security incident, nearly six hours after the three stage-two commits landed within ten seconds, and left the task and font files, which were still there when the researchers looked. Clean-up that stops at the workflow is half done.

OpenSourceMalware's reading is that stage one needs GitHub to run the workflow and stage two does not: "We can say the operator moved to a place GitHub's controls don't reach." It also notes that the indicators it had published changed between 12 and 15 October, and adds: "That doesn't prove the operator was reading our posts. The timing fits it." The practical lesson is the one the section on labels gave: a hunt for last week's names finds last week's wave. Its other reading, which it labels an inference, is that stage one had little to steal in dormant repositories: "The developer's laptop is where the keys are. That's an inference, but it's the one the data supports."

The phishing leg: a proxy that relays the one-time code, and an approval nobody clicked

OpenSourceMalware's post of 11 October describes a phishing email sent on 9 October, the day the look-alike domain was registered. It was dressed as a GitHub security alert about a sign-in from Moscow, Russia, and addressed by name to an open source developer whose identity the researchers withhold. The page behind it acted as a reverse proxy of GitHub's real login: it collected the password and the authenticator code, then carried injected JavaScript built to start an OAuth device flow asking for three permissions and to submit GitHub's approval form itself from inside the victim's authenticated session. In OpenSourceMalware's words: "The victim does not need to type the device code or consciously approve the OAuth application."

GitHub's own documents say what the person would normally face. The device flow "allows you to authorize users for a headless application, such as a CLI tool", where the user types a short code at GitHub. On the ordinary consent page, GitHub says, "you'll see a page with the app's developer contact information and a list of the specific data that's being requested". GitHub's best-practice page warns that "an attacker can use the device flow to remotely impersonate your app as part of a phishing attack". The three permissions, per GitHub's scope list: the repository scope "Grants full access to public and private repositories including read and write access to code"; the workflow scope "Grants the ability to add and update GitHub Actions workflow files"; and the organisation-read scope gives read-only access to membership and teams. The workflow scope is the one that lets the holder push the next batch of files.

The phishing chain, link by link. Source: OpenSourceMalware, 11 October post and 15 October show.

Link	What OpenSourceMalware shows	What it does not show
The email	One, sent on 9 October, the day the domain was registered. The recipient is withheld.	How many were sent. On its show of 15 October a co-founder said multiple people in its network were phished: no count.
The proxy page	Page source and a browser archive show the password and a one-time code from an authenticator application were sent to the proxy.	Where else the page was used, or who else submitted.
The approval step	A script in the page requests three permissions and submits GitHub's approval form.	Completion: "successful token issuance or exfiltration in this browser session is not" confirmed.
MFA	With one real victim, the attacker "successfully logged in" but "was stopped from escalating privileges by an additional MFA challenge". On its show a co-founder said the kit "very successfully dealt with" the MFA methods tested.	Which methods were tested. That a passkey or a hardware security key was among them.
The tie to the 94	The same numeric address hosts the phishing domain and receives stage-one data.	Any tie between the kit and the 94: OpenSourceMalware has not made one.

The MFA row is the friendly-name fallacy with the most at stake. "MFA" names a control only for the attacks it was built against. The NCSC's blog of 23 April 2026 assesses that all traditional MFA methods, including one-time codes generated by apps, are "inherently phishable", because "secrets or approvals can be observed and relayed during a live session"; it says the NCSC will recommend passkeys wherever a service supports them. GitHub's own passkey page says a passkey is bound to a website domain, so that "the web browser will refuse to authenticate to a lookalike phishing website", and calls this "highly phishing-resistant". None of the sources says any victim used a passkey or a security key, and the record does not show what happens to this kit against one. That is a gap in the record, and a reason to test your own accounts, not a finding.

Opening a folder: what VS Code documents, and what a trust prompt is

The launcher depends on VS Code behaviour that Microsoft documents. On its tasks page (read on 19 October 2026), a task can be set to run when the containing folder is opened; the automatic-tasks setting is off by default, and where the user has not yet chosen, "you are prompted once to Allow or Disallow automatic tasks". The same page says: "Automatic tasks never run in an untrusted workspace, regardless of this setting." On its Workspace Trust page: "When you open a new, unfamiliar folder, VS Code opens it in Restricted Mode to prevent automatic code execution while you review the contents." It also warns that tasks "are part of the committed source code for a repo", so a malicious one "could be unknowingly run by anyone who cloned that repository". Its note: "When in doubt, leave a folder in Restricted Mode."

OpenSourceMalware's reading agrees with the documents: the file does nothing in an untrusted workspace, and only runs if automatic tasks are allowed, by a click on the one-time prompt or by the setting. That makes the exposure depend on human choices: trusting the folder, or a parent of it, and allowing automatic tasks. It also widens who is exposed beyond the owner: "Anyone who opened the repo while the files were in it may have run the infostealer."

Two limits on what the documents give you. First, a trust prompt is a question about a folder, answered once, by someone who has just cloned a repository in order to read it. It is not a review of what the folder contains, and the record does not say anyone answered Allow. Second, the Workspace Trust page says a user can trust a parent folder, which "applies trust to the parent folder and all its subfolders". A developer who trusts a projects folder to save clicks has trusted everything later cloned beneath it. The page does not say what happens when a trusted folder later receives a commit; our inference is that trust attaches to the folder, not to its contents, so a repository trusted as clean stays trusted when a file is added to it.

Dormant is not safe: 65 of 79, and a scale the 94 does not measure

OpenSourceMalware's good-news sentence is that most of the repositories "were seemingly abandoned before the attackers arrived". Its figures: 65 of the 79 had gone more than a year without a commit when the first malicious commit landed (82.3%, derived), 47 more than two years (59.5%) and 28 more than three (35.4%); the median was 792 days, 2.17 years (derived); the other 14 (17.7%, derived) had a commit within the year. Its conclusion is not comfort: "The attacker isn't picking projects." The automation pushes to everything an account can write to, "so a repository the owner forgot they had carries the same malware as the one they work in every day."

Abandoned reads as low risk because nobody uses it. The second stage is built for exactly that assumption, since it waits for whoever opens the folder next, and an owner is not the only such person. Anyone who cloned the project years ago, a fork, a mirror, a build that still fetches it, a new contributor: each is a path to the files, and a repository with no recent commits is also one where a new commit is unlikely to be noticed (our inference: the sources do not say whether any owner noticed). OpenSourceMalware and The Hacker News both advise telling everyone who cloned a repository that carried the files.

Set the 94 against the campaign's size. On 10 October this site's earlier briefing, GhostAction: 345 repositories in two sweeps, found that "tens of thousands" had no count behind it. GitGuardian's update of 13 October now supplies one: "more than 30,000 repositories across 3,000 users and orgs", from "compromising the GitHub accounts of about 1,900 users", with 3,174 secrets the attackers attempted to extract. The 94 are 0.31% of 30,000 (derived; the denominator is "more than", so the share is smaller). That is not a rate. The 94 are what one researcher found by hunting for a particular file pattern; GitGuardian counts repositories that received the first workflow. How many of the 30,000 also carry stage two, and how many carried it before OpenSourceMalware looked, is not stated by either.

The UK: what the NCSC and DSIT say, what Cyber Essentials does not, and when the ICO is involved

None of the UK material read here is about this campaign. What it supplies is the standard a UK organisation can be held to, and where that standard stops short of a launcher that runs when a folder is opened.

UK sources as read on 19 October 2026, and what each leaves open for this incident.

Source	What it says	What it leaves open
NCSC, Software Security Code of Practice implementation guidance, theme 2 (published 7 May 2025)	Principle 2.1 is "Protect the build environment against unauthorised access"; 2.2 is "Control and log changes to the build environment". "Strong authentication (such as MFA) must be mandated for all developers who access the build environment." Its further reading includes CISA's guide to phishing resistant MFA.	The text says MFA, not phishing resistant MFA. It is about a vendor's build environment, not a laptop that clones third-party code.
DSIT, Software Security Code of Practice (published 7 May 2025, updated 15 January 2026)	Open-source developers and maintainers are "not considered the primary audience". "Any risks associated with open-source code must be managed by end-users or proprietary developers using open-source code in their software."	The Code has no principle named for source control or developer accounts; the nearest are 2.1 and 2.2. The risk it puts on the consumer is the reader's.
NCSC blog, 23 April 2026	All traditional MFA methods, including app-generated one-time codes, are "inherently phishable". The NCSC will recommend passkeys where a service supports them.	Written from an individual user's perspective, not a developer pipeline.
Cyber Essentials, Requirements for IT Infrastructure v3.3 (April 2026)	"authentication to cloud services must always use MFA". Its additional-factor types include an app on a trusted device, and its passwordless list includes one-time codes sent by email, SMS or an app.	Searched case-insensitively, the 26-page text has no match for phish, GitHub, workflow, source code or pipeline (derived). A cloud account protected by an app code meets the text; the kit in OpenSourceMalware's post asks for exactly that code.
NCSC blog, 4 June 2026	"Store sensitive credentials securely, avoiding exposure on developer workstations." "Recent attacks have also targeted API keys and tokens used by developer tooling." Its immediate actions include "Enforce MFA for developer and package registry accounts."	Says nothing about editor tasks that run on opening a folder.
NCSC, Secure your development environment (published 20 February 2019)	If an attacker compromises a developer's environment "they will inherit the same level of permissions and access as that developer."	Published in 2019; does not mention AI tool logins.

Two points follow. The UK standard can be met while an account is phishable by the method this kit is reported to use: Cyber Essentials counts a one-time code as MFA, and the NCSC's own assessment in the same month says such a code can be relayed. And the DSIT Code puts the risk of open source on whoever consumes it, so the dormant repository that carries the files is not the maintainer's problem under that Code; it is the problem of the organisation that cloned it. The NCSC's guidance under principle 1.2 lists "frequency of updates" and "how many maintainers" among the security attributes to weigh when selecting third-party components, and says to regularly test all third-party components and dependencies.

The ICO. None of the sources reports personal data reached through a stolen credential. If a key taken from a developer machine were later used to reach personal data, the ICO's guide says a reportable personal data breach must be notified "within 72 hours of becoming aware of the breach, where feasible". Whether a credential stolen from a laptop makes the organisation aware of a personal data breach is a question for your own incident process; the record supplies no case.

What to do, in the order worth doing

Defender level only: what to look for and harden, with no indicators. OpenSourceMalware's own post carries the filenames, addresses and a client identifier for matching.

What could not be verified

• The 9 October block. No GitHub statement was found. The claim rests on GitGuardian's run records, relayed by OpenSourceMalware and The Hacker News. What the block is, and whether it is the approval gate StepSecurity saw, is not stated.
• The 94. OpenSourceMalware's cluster could be checked only for the 79 it cloned. The Hacker News page was read live and its figures match OpenSourceMalware's, but it is a report of that post, not an independent count.
• Whether any machine ran the script. No source reports one.
• Phishing numbers and MFA. One email is documented. Which MFA methods the kit was tested against is not stated.
• UK documents. Cyber Essentials was searched as extracted text; a word that the extraction missed would not show.

The question that exposes the gap

Which repository your organisation owns, or cloned and trusted, has had no commit for three years, and what would tell you that a file was added to it last week that runs when someone opens the folder?

Key facts