FakeGit returns with 17,610 malicious GitHub repos

The FakeGit malware operation is active again on GitHub, and it is now larger than before. Researchers count 17,610 fake repositories delivering the SmartLoader malware, after the campaign came back earlier this month to spread the StealC infostealer.

The findings come from Apiiro, a company focused on software supply-chain security. According to its researchers, FakeGit resumed activity on October 4.

Most of the accounts behind the repositories look like throwaway profiles created for the campaign. However, the researchers also found at least 700 accounts that appear to belong to real developers.

A loader dressed up as a download

The setup is simple. Each malicious repository has a README file with polished instructions and a download button. That button leads to a ZIP archive containing SmartLoader, the first-stage payload. SmartLoader's job is to fetch and install other malware on the victim's machine.

Activity like this, with different payloads, has been seen since at least January. The name FakeGit was attached to the operation in July, when Island, a company that makes an enterprise browser platform, reported on 7,600 fake GitHub repositories pushing SmartLoader.

In that report, Island noted that 800 of the repositories posed as AI skills or MCP servers. MCP servers are components that let AI assistants connect to outside tools and data. These fake entries showed up in public AI registries and catalogs, where developers browse for add-ons.

13,000 repos re-aimed in 34 hours

Apiiro says the latest wave moved very fast. Within 34 hours, FakeGit pushed changes to more than 13,000 repositories. At its peak, the operator was hitting 2,999 repositories an hour.

The changes were small and targeted. "In the commits we sampled, 97% touched only the README, and 88% pointed its "Download" button at a ZIP that installs SmartLoader," Apiiro says.

That detail matters. The attacker did not need to build new infrastructure for this round.

"Nobody had to create a single new repo. The fleet was already there. It just got re-aimed," the researchers explained.

Why takedowns have not worked

Apiiro links FakeGit's staying power to how removals are handled. Repositories are taken down based on lists, and those lists cover only part of the malicious fleet.

Blocking the payloads is not enough either. Blocklisted files and their backup copies often stay reachable, so the operator can update the download link and keep the same repository online.

Threat intelligence feeds were also behind. "71% of the fleet was missing from URLhaus before our report, and a domain-level DNS blocklist can't block one file on GitHub without blocking GitHub," Apiiro notes. URLhaus is a public database that tracks URLs used to spread malware.

The malicious archives were stored in many places across GitHub. Researchers found them in forks, older files, release assets, issue attachments and dedicated repositories used only to host downloads. Removing a single link at a time does little against this kind of spread.

"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," the researchers said.

What Apiiro recommends

The researchers advise users to check who owns a repository before downloading anything from it. AI skills and MCP servers should come only from official registries or from the vendor's own repositories.

Anyone who suspects SmartLoader has run on their system should handle it as a possible compromise of their GitHub account. That means revoking active sessions and access tokens, and switching to passkeys for sign-in.

Our Take

FakeGit shows that the weak point is no longer just the malware itself, but the trust developers place in a familiar platform. A GitHub page with a tidy README and a download button looks routine, and that is exactly what the operator relies on. Ongoing work on platform-side defenses, such as GitHub's push protection features, targets other risks and does not appear to address lures that live inside README files.

The campaign also fits a wider pattern of attackers using developer ecosystems as distribution channels, similar to malicious npm packages built to reach coders directly. The use of fake AI skills and MCP servers suggests attackers are following developers into newer, less mature catalogs where vetting may be thinner.

The 700 accounts that appear to belong to real developers stand out. If those accounts were hijacked, stolen credentials may be feeding the operation's growth. This makes the advice on revoking tokens and adopting passkeys more pressing, even as passkey adoption still lags among security professionals.

It is worth watching whether GitHub changes how it removes this kind of content, moving from list-based takedowns toward cleaning up forks, release assets and attachments together. Until then, the fleet may simply be re-aimed again.