The surprising part isn't the repository count. It's that the operator barely needed to build anything new.
What happened: thousands of existing repos were pointed at new payloads
BleepingComputer reported Apiiro's findings. According to that report, in just 34 hours, FakeGit pushed more than 13,000 repos, peaking at 2,999 an hour. Nearly all of those changes were small. Apiiro said "In the commits we sampled, 97% touched only the README, and 88% pointed its "Download" button at a ZIP that installs SmartLoader".
In other words, the operator kept the existing repositories and changed where their download links went. The researchers summed it up this way: "Nobody had to create a single new repo. The fleet was already there. It just got re-aimed."
The lure itself is simple. The malicious repositories use convincing README instructions with a download button pointing to a ZIP archive containing the initial payload, SmartLoader, that is used to distribute other malware. The goal of this latest wave is to deliver the StealC infostealer.
Most of the accounts are disposable. Still, researchers identified at least 700 accounts that appear to belong to legitimate developers. Read that number as researchers' judgment about which accounts look genuine, not as 700 confirmed account takeovers. Either way, it means a familiar username next to a repository doesn't prove the project is safe.
Section summary:
- Apiiro counted 17,610 malicious repositories after the campaign came back on October 4.
- More than 13,000 repositories were updated in 34 hours, peaking at 2,999 an hour.
- Most commits only edited the README to point the download button at a SmartLoader ZIP.
- At least 700 of the accounts involved appear to belong to real developers.
How FakeGit got here: from 7,600 repos to 17,610
This isn't a new threat. While similar activity with various payloads has been observed since at least January, the FakeGit term was associated with this operation in July, when researchers at enterprise browser platform Island published a report on 7,600 fake GitHub repositories pushing the SmartLoader malware.
The Hacker News covered Island's July research, which described the method plainly: "FakeGit uses copied projects, lookalike developer profiles, convincing READMEs, and malicious ZIP files to deliver SmartLoader malware," according to Island lead security researcher Oleg Zaytsev. The same coverage said that as of July 2026, the FakeGit operation has recorded more than 14 million downloads across GitHub Release assets in about 200 campaign repositories.
Island also found a strong focus on AI tooling. Of the 7,600 malicious GitHub repositories created by about 6,600 profiles, 800 posed as Skills or MCP servers for individual and enterprise use, from Gmail and WhatsApp integrations to Databricks, Jenkins, and Docker tooling. Island called the technique "agentbaiting." It works when an AI agent searching for a skill or an MCP server ends up inadvertently discovering one of these bogus GitHub repositories, causing it to do the attacker's bidding on its own without any intervention from a human user. According to Nsane Forums' coverage of the Island research, Island found in public registries and catalogs more than 600 listings for skills and MCP servers that were linked to the FakeGit campaign. Some of them included LobeHub, Glama, MCP.so, and MCP Market.
There is also a link to an older operation. The same report said the campaign is considered a continuation of an older operation that used Lumma Stealer and was attributed to a threat actor tracked as "Water Kurita" by researchers at cybersecurity company Trend Micro.
One caution: the AI-skill figures come from Island's July count. Nobody has claimed that all 17,610 repositories in Apiiro's October count are AI-themed. They pretend to be all kinds of software.
Section summary: In about three months, FakeGit went from roughly 7,600 publicly documented repositories to more than 17,000. The AI and MCP lures documented in July are still a useful warning for developers using agent tooling.
Why takedowns haven't stopped it
Apiiro's most useful finding for defenders explains why the campaign is still running. According to the researchers, the reason behind FakeGit's survival is that removing repositories is based on lists that cover only a fraction of the malicious repos. BleepingComputer adds that blocklisted payloads and backup copies remain accessible, so the operator can change download links while keeping the same repositories online.
Two weaknesses stand out:
- Blocklist coverage is incomplete. Apiiro says 71% of the fleet was missing from URLhaus, abuse.ch's public database of malware URLs, before its report. A DNS blocklist that works on whole domains can't block one file on GitHub without blocking GitHub entirely. Few companies can afford to block the platform their developers rely on all day.
- There are spare copies everywhere. The researchers found malicious archives in forks, older files, release assets, issue attachments and separate download-hosting repositories. If one file is removed, the lure can be pointed at another copy.
The pattern will be familiar to anyone who has fought malvertising. A blocklist entry or a single takedown handles one URL, while the operator controls thousands of places to put the next one. In practice, the reliable defenses are stronger platform-level detection and users who are more careful about where they download from.
Section summary: Removing links one at a time doesn't work against a fleet with backup copies stored in many parts of GitHub, and domain-level blocking can't separate a malicious file from the rest of GitHub.
What SmartLoader leads to
Island's July research described the end goal: to leverage the access afforded by SmartLoader to establish persistence and push secondary payloads, such as StealC, an information stealer capable of harvesting a wide range of data from compromised systems. Nsane Forums' coverage added that the ZIP archives pose as installers or project releases but are disguised Lua payloads that trigger SmartLoader.
That's why one infection on a developer's Windows PC can affect a whole team. Browsers on these machines hold saved credentials and active sessions for GitHub, cloud consoles and internal systems. That is why Apiiro treats a suspected infection as a possible GitHub account compromise, not just a cleanup job for one PC. It also suggests a possible explanation for the hundreds of genuine developer accounts in the fleet, although the reporting doesn't prove how each account was taken over.
What Windows users and developers should do
Apiiro gives several recommendations. Below each one is our own general advice from standard security practice:
- Check who owns the repository. Apiiro says to verify the owner. A polished README, a familiar project name or a big star count proves very little, because Island found the campaign copies real projects and uses lookalike profiles.
- Get AI skills and MCP servers only from official sources. Apiiro says to install these from official registries or vendor repositories. Given what Island found in public catalogs, a listing in a third-party directory isn't proof that a tool is legitimate.
- Be wary of an unexpected ZIP "Download" button. Legitimate open-source projects usually point to source code, signed release builds or package managers. A README that pushes you to download an archive and run what's inside deserves a closer look, especially if it tells you to ignore Windows security warnings. (This is general guidance, not a quote from Apiiro.)
- If you suspect you ran SmartLoader, act like your account is compromised. Apiiro says to revoke active sessions and access tokens, then move to passkeys. Passkeys can't be phished like passwords, though they won't protect a session that has already been stolen. Revoking sessions is what handles that part.
- Organizations should bring in their security team. Apiiro's advice covers sessions and tokens. It isn't a full incident-response plan, so use your existing procedures to clean the device.
For GitHub enterprise and organization admins, there is a relevant platform feature. In an August 18, 2026 changelog entry, GitHub said enterprise owners, organization admins and members with the "Manage enterprise credentials" permission can now revoke all tokens of a specific credential type, such as personal access tokens, SSH keys, OAuth app tokens or GitHub App user access tokens. They don't have to wipe every credential a user has. GitHub also said these bulk actions are now available at the organization level, both in the web UI and through the REST APIs, and that each action is recorded in the audit log. That allows a more targeted response if a developer may have run a FakeGit payload. It doesn't fix the infected PC, and it isn't a FakeGit-specific fix.
The bigger picture
FakeGit exploits a habit many developers have: trusting a repository because it looks like a normal GitHub project. The fleet doubled in size between July and October. In one day and a half, the operator updated thousands of repositories. Takedown lists cover only part of the campaign. Together, those facts suggest the problem won't be solved by reporting malicious repositories one at a time.
There is a fair counterpoint. Apiiro sells supply-chain security products, and its numbers come from its own snapshots and sampling. The 97% and 88% figures, for example, come from sampled commits, not from every repository. Still, the overall picture matches Island's independent July research. Both describe copied projects, convincing READMEs, ZIP downloads, SmartLoader as the first payload and StealC at the end.
If you install tools from GitHub, especially AI skills and MCP servers, check who publishes the project before you click any download button.