FakeGit re-arms 17,610 malicious GitHub repos to drop SmartLoader and steal sessions

October 8, 2026. Apiiro, a software supply chain security platform, publishes a number that staggers: 17,610 fake repositories on GitHub are distributing the SmartLoader loader. October 4, 2026. The FakeGit campaign resumed activity, this time to push the StealC infostealer. 2,999 per hour. That was the peak creation rate — without a single new repository being created. Why it matters: the malicious fleet was already in place and was merely re-aimed, which makes piecemeal takedowns powerless — and developers who install “AI skills” from GitHub are the designated target.

A fleet that was already there, just re-aimed

The most unsettling finding in Apiiro’s report is captured in one quoted sentence: “Nobody had to create a single new repo. The fleet was already there. It just got re-aimed.” The group behind FakeGit does not start from scratch on each campaign: it reactivates a stock of repositories that are already indexed and referenced, and simply swaps the payload.

The numbers describe the mechanics. In 34 hours, FakeGit pushed more than 13,000 repositories, peaking at 2,999 repos per hour. In the commits the researchers sampled, 97% touched only the README, and 88% pointed their “Download” button at a ZIP archive that installs SmartLoader. The pattern is industrial: an enticing README, a download button, a poisoned ZIP.

SmartLoader is only the first stage. It is a loader — its job is to drop the final payload, here the StealC infostealer, which drains credentials, cookies and session tokens. The fake repos mostly use throwaway accounts, but researchers identified at least 700 accounts that appear to belong to real developers — compromised accounts, hijacked to lend the lure a legitimate reputation.

The weak link: AI skills and MCP servers

What elevates FakeGit from a nuisance to a serious threat is its target. Back in July, the Island platform documented 7,600 fake repositories pushing SmartLoader, and noted that 800 of them masqueraded as AI skills or MCP servers appearing in public AI registries and catalogs.

MCP, the Model Context Protocol, has become the de facto standard for connecting AI agents to external tools. Thousands of developers install “MCP servers” found on GitHub to give their assistant new capabilities — reading files, querying databases, driving services. It is exactly the kind of add-on people install quickly, trusting the name and the README, without auditing the repository.

A malicious MCP server does not just steal cookies: it runs in the very environment where the AI agent lives, with that agent’s access. For a developer, installing a fake MCP server means handing an attacker a foothold on their machine and, often, the tokens of their development tools — GitHub, package registries, cloud services.

Nor is the threat confined to a handful of victims. A fleet of 17,610 repositories is large enough to surface near the top of generic searches for popular tooling, which means the attack does not depend on any single person’s mistake — it depends on volume. For every developer who checks the owner, there are dozens who do not, and a lure fleet this size only needs a small hit rate to pay off.

Why takedowns don’t work

The reason FakeGit survives takedown waves is structural, and Apiiro spells it out in three observations.

First, blocklists cover only a fraction of the fleet. “71% of the fleet was missing from URLhaus before our report,” the company notes. Takedowns rely on lists of known repos, but the bulk of the stock never appears on them.

Second, a DNS blocklist can’t block one file on GitHub without blocking GitHub. If the lure points at an archive hosted on the github.com domain itself, a domain-level rule is useless — you would have to cut off the entire platform.

Third, backup copies are everywhere. The researchers found malicious archives in forks, older files, release assets, issue attachments and separate download-hosting repositories. The result: “Delete one file and the operator can point the lure at a spare copy — a fork, an older ZIP, a release asset or an issue attachment.” Targeted deletion becomes a cat-and-mouse game the defender loses every round.

Respond as if the account was compromised

Apiiro’s recommendations are direct, and the most important one is about the response, not the prevention. If SmartLoader execution is suspected, the incident should be treated as a GitHub account compromise: revoke active sessions and access tokens, and move to passkeys.

That is the right mental model. SmartLoader is a loader, so its presence means StealC — or another final stage — has very likely run on the machine. An infostealer targets session tokens and saved credentials first: revoking sessions strips the value of what was already stolen, and passkeys make reusing captured passwords harder.

On prevention, the guidance is simple and old: verify the repository owner. A recent account with no history hosting an enticingly named “MCP server” is a red flag. For AI skills and MCP servers, the install source should be official registries or the vendors’ own repositories, not a link found at random in a search. That single habit — checking who owns the code before running it — is the highest-leverage defense available, because it stops the attack at the point where the attacker actually depends on the victim’s trust.

Spotting a fake repo before you click

Individual defense starts with a critical look at the repository, before opening the archive. Three signals overlap, and each takes thirty seconds to check.

• The owner. A recently created account with no notable repositories and no contribution history, hosting an “MCP server” named exactly after the tool you searched for, is a red flag. Checking the account’s creation date and age is usually enough to decide.
• The content. A repository whose commits touch only a README — no code, no tests, no CI — is not a project; it is a storefront. The 97% of README-only commits that Apiiro observed is the lure’s signature.
• The download button. A legitimate repository publishes its code in the repo or on its language’s registry, not in a ZIP archive pointed at by a “Download” button in the README.

The rule that sums it up in one sentence: for an AI skill or an MCP server, the install source is the official registry or the vendor’s repository, never an intermediary link found in the middle of a search.

Verdict

If you install AI skills or MCP servers from GitHub, change the reflex today: check the repository owner, its history and its age, and systematically prefer the vendor’s official registry or repo — a fake MCP server runs with your access and your tokens, not in a sandbox. If someone on your team may have run a fake repo, do not try to “clean up”: treat the event as an account compromise, revoke sessions and tokens, and switch to passkeys. For the collective defense, do not count on GitHub takedowns — a fleet of 17,610 re-aimable repositories will not shrink through partial blocklists; it gets bypassed by the vigilance of the people who click.

References

• BleepingComputer — FakeGit malware campaign returns with 17,610 malicious GitHub repos, October 8, 2026
• Apiiro — FakeGit campaign report (SmartLoader/StealC), October 2026
• Island — initial report on 7,600 fake GitHub repositories (July 2026)