"Nobody had to create a single new repo. The fleet was already there. It just got re-aimed," Apiiro researchers wrote — a concise description of how the FakeGit campaign pivoted in early October and suddenly repurposed thousands of dormant GitHub repositories to deliver malware.
Scale and speed of the October 4 resurgence
Researchers at software supply-chain security platform Apiiro report that FakeGit resumed activity on October 4 and now uses 17,610 malicious repositories on GitHub. In just 34 hours the operation pushed more than 13,000 repositories, at one point creating or re-aiming repositories at a peak rate of 2,999 an hour. While the operator primarily uses throwaway accounts, Apiiro identified at least 700 accounts that appear to belong to legitimate developers, complicating detection and trust-based controls.
Delivery mechanism: README 'Download' buttons and SmartLoader ZIPs
The malicious repositories rely on convincing README files with a prominent "Download" button that points to a ZIP archive. That ZIP contains SmartLoader, an initial payload used to distribute additional malware. Apiiro's sampling of commits found that 97% of observed commits touched only the README, and 88% of those READMEs pointed the download button at a ZIP that installs SmartLoader.
SmartLoader itself has been used repeatedly in this operation: the FakeGit campaign distributed SmartLoader in earlier waves, and the October reactivation aimed to push the StealC infostealer via the same mechanism. Island, an enterprise browser platform, first applied the "FakeGit" label in July when it published a report describing roughly 7,600 fake GitHub repositories pushing SmartLoader; Island also noted that about 800 of those repositories masqueraded as AI skills or MCP servers appearing in public AI registries and catalogs.
This site is the portfolio.
OSINTSights runs on Cloudflare Workers, D1, R2, and Vectorize, with an AI pipeline on Hetzner ARM. Nubivance designed, built, and operates it. We do the same for clients.
See what we buildWhy takedowns and blocklists have limited impact
Apiiro's analysis highlights structural obstacles to removing the campaign's artifacts. A large portion of the fleet was not covered by existing blocklists—Apiiro reports that 71% of the fleet was missing from URLhaus before their report. The researchers also note a practical limitation of domain-level DNS blocklists: "a domain-level DNS blocklist can’t block one file on GitHub without blocking GitHub."
Additionally, attackers leave multiple redundant copies and hosting paths in place. Apiiro found malicious archives in forks, older files, release assets, issue attachments and separate download-hosting repositories. That redundancy means defenders who delete a single file or asset can be quickly circumvented: the operator can point the README's download link at a spare copy — a fork, an older ZIP, a release asset, or an issue attachment — without creating new repositories.
What this means for developers, security teams, and end users
- Developers and security teams: Apiiro recommends verifying the repository owner before installing packages or following README download links. For AI skills and MCP servers specifically, the source for installation should be official registries or vendor repositories rather than ad-hoc GitHub projects. If SmartLoader execution is suspected, treat the event as a potential GitHub account compromise: revoke active sessions and access tokens and move to passkeys, the researchers advise.
- End users and maintainers of public assets: Because the malicious lure is primarily a README "Download" button pointing to an archive, users should be cautious of download prompts in otherwise innocuous projects — especially projects that appeared suddenly or that mirror known package names or AI skill listings.
The technical facts in Apiiro's report and Island's earlier July findings point to a simple operational calculus for the actor: reuse and re-aim. Rather than inventing new infrastructure, the operator leveraged an existing fleet of repositories and a thin trick — editing READMEs to point at ZIPs — to scale an infostealer campaign in a matter of days. That reuse, combined with malicious copies hidden across forks, release assets and attachments, turns routine takedown tactics into a game of whack-a-mole and leaves defenders with the harder work of proving provenance and locking down credentials.
Read the original report: https://www.bleepingcomputer.com/news/security/fakegit-malware-campaign-returns-with-17-610-malicious-github-repos/
