FakeGit restarted on 4 October. Apiiro now counts 17,610 GitHub repositories in the campaign, against roughly 7,600 that Island reported in July.

The number is not the story. How it was reached is.

The repositories were already there

In about 34 hours, whoever runs FakeGit touched more than 13,000 repositories, peaking near three thousand an hour. Apiiro's summary of what that took is one sentence: nobody had to create a single new repo.

In 97 percent of sampled commits, the only file changed was the README. The repositories existed. What changed was where their download button pointed.

This is a different economy from mass registration. A newly created repository has nothing — no age, no history, no inbound links, nothing in a search index, and every signal a platform uses to spot bulk abuse pointed straight at it. A repository that has been sitting there has all of those for free, and editing one file does not look like abuse at all. It looks like a commit.

It also explains the speed. Three thousand an hour is not a rate you reach by provisioning accounts; it is a rate you reach when the expensive part was done months ago.

The chain

The path from a repository page to a stolen password is short. A download button in 88 percent of sampled commits leads to a ZIP archive. The archive installs SmartLoader, which exists to deliver other things. In this wave it is delivering StealC, an infostealer.

Apiiro reports that 71 percent of the fleet was absent from URLhaus before it published — so roughly three in ten were known, and seven in ten were not, at a point when the campaign had been running for days.

The account detail that should worry people

Most of the repositories sit on throwaway accounts, which is expected.

But researchers found at least 700 accounts that appear to belong to real developers. That is a different problem from a spam wave. An account with a history, contributions and followers is not only harder to spot — it is more persuasive, and the cost of blanket-blocking it falls on a person who did nothing.

How those accounts were obtained is not stated. Credential stuffing, stolen tokens and malicious workflow actions are all live possibilities, and the campaign is distributing an infostealer, which closes the loop neatly enough to be worth noting without asserting it.

What the payload is for

SmartLoader is a delivery mechanism, which makes the interesting question what it delivered this time. StealC is an infostealer: browser-stored passwords, session cookies, cryptocurrency wallet data, and the credential files that developer tooling leaves on disk.

That last category is why this campaign reads as circular rather than merely large. The people most likely to open a GitHub repository, click a download in a README and run what comes out are developers — and a developer's machine holds cloud keys, package-registry tokens, signing material and the credentials to their own repositories.

Which is one answer to how a campaign ends up with seven hundred accounts that look like they belong to real people. We are not asserting that is how it happened; Apiiro does not say. But a campaign that steals developer credentials and a campaign that needs credible developer accounts are, at minimum, well matched.

Where the AI angle actually is

Island's July research found about 800 of the repositories dressed as AI skills or MCP servers, listed in public AI registries and catalogs.

That is the part worth sitting with. We wrote this week about an MCP endpoint being used as a live command channel inside victim networks. This is the other side of the same immaturity: a new category of component, a set of registries assembled quickly to list them, and an installation step that is usually a copied command. Nothing in that chain has the review a package registry grew over fifteen years, and the attackers arrived while it was being built.

Apiiro's advice on this is narrow and correct: install AI skills and MCP servers from the official registry or the vendor's own repository, not from a search result.

GitHub as the host nobody blocks

This is the second campaign in three days running on the same reasoning. A botnet resolved its command-server address out of a poem in a GitHub repository, because a request to a code host raises nothing. Here the code host is the distribution channel itself, and a developer visiting a repository is doing their job.

There is no statement from GitHub, and no confirmed removals. What makes removal partial even where it happens is that copies survive the repository: forks, releases and issue attachments remain reachable after the original goes. Blocklists covering a third of a fleet, against a campaign that can re-point the rest with a README edit, is not a contest.

What to do

  • Treat a README's download button as an untrusted link, because the repository's age tells you nothing about where that button pointed this morning.
  • Prefer release artefacts you can verify over a ZIP from a link, and check what the repository's history actually contains rather than that it has one.
  • Install AI skills and MCP servers from official registries or vendor repositories only.
  • If you maintain repositories, check your own commit history for changes you did not make. Seven hundred accounts in this campaign look like they belong to someone.

What is not established

  • How the roughly 700 legitimate-looking accounts were obtained.
  • Whether the 17,610 figure holds. It rests on a single vendor's count, as July's 7,600 did.
  • How many people ran the payload. Download counts quoted for this campaign measure activity, not compromise.
  • What GitHub has done, if anything.
  • Whether the same operator is behind the July wave and this one, beyond the shared name and chain.