The FakeGit malware campaign has returned to GitHub on a large scale, with researchers identifying 17,610 repositories used to distribute SmartLoader, an initial payload capable of downloading other malware. The activity resumed on October 4, 2026, after the campaign had earlier in the month been used to deliver StealC, an information-stealing malware.
The campaign primarily relies on temporary accounts, but researchers identified at least 700 accounts that appear to belong to legitimate developers. The malicious repositories use convincingly designed README files containing a download button that leads to a ZIP archive containing SmartLoader.
Rapid Escalation Using Existing Repositories
According to a report by software supply chain security platform Apiiro, the campaign pushed more than 13,000 repositories over 34 hours, with activity peaking at 2,999 repositories per hour. In the commit samples examined by the researchers, 97% were limited to modifying a README file, while the download button in 88% of them led to a ZIP file that installs SmartLoader.
This indicates that the operators did not need to create new repositories; instead, they redirected an existing fleet toward malicious links. Island had linked the name FakeGit to this operation in July, when it documented 7,600 fake repositories delivering SmartLoader, including 800 repositories masquerading as artificial intelligence skills or MCP servers that appeared in public records and catalogs.
Why Is the Campaign Difficult to Contain?
Apiiro researchers believe that removing the repositories covers only part of the malicious infrastructure. Blocked payloads and their backups also remain available, allowing attackers to change the download link while keeping the repository itself active. The researchers found that 71% of the fleet had not been listed in URLhaus before their report was published.
The malicious archives are distributed across forks, old files, release assets, issue attachments, and separate repositories dedicated to hosting. Therefore, deleting one file or link does not prevent the operator from directing the victim to an alternative copy.
What Changes in Practice for Users?
Simply treating the presence of a repository on GitHub as evidence of its trustworthiness is insufficient, particularly when downloading artificial intelligence skills or MCP servers. The researchers recommend verifying the repository owner and relying on official registries or software vendor repositories as installation sources.
If a user suspects that SmartLoader has been executed, the situation should be treated as a possible compromise of the GitHub account, followed by revoking active sessions and access tokens and moving to passkeys. The campaign shows that relying on link blocklists or deleting individual repositories remains limited when an attacker can reuse copies, branches, and release assets.