The FakeGit malware campaign has returned, and its fleet of fake GitHub repositories now totals about 17,610. Software supply-chain firm Apiiro reported the surge, covered by BleepingComputer on 8 October. Island, an enterprise browser vendor, first tied the name FakeGit to the operation in July, when it counted about 7,600 repositories.
According to the report, activity resumed on 4 October using the existing repository fleet. In roughly 34 hours, more than 13,000 repositories were pushed, peaking at about 2,999 per hour. Most accounts are throwaway, but at least 700 appear to belong to legitimate developers.
The lure is simple. Each repository has a README with a "Download" button that points to a ZIP archive. In the commits Apiiro sampled, about 88% of the buttons pointed to a ZIP that installs SmartLoader, a loader that delivers other malware, and about 97% of the commits changed only the README. The final payload named in the report is StealC, an infostealer. Similar activity with other payloads has been seen since at least January.
Some repositories pose as AI skills or MCP servers, imitating entries in public AI registries and catalogs. Island reported about 800 of these in July. This matters because developers and data teams now routinely pull agent tooling from GitHub and run it with access to API keys, source code and internal systems. A "skill" that is really a loader gets that access on day one.
Apiiro says about 71% of the fleet was missing from the URLhaus malware feed before its report. Operators can also re-point download links to backup copies in forks, older ZIPs, release assets, issue attachments or separate download-hosting repositories, so removing one repository does not remove the campaign. Blocking the domain at DNS is not practical either, because it would block GitHub itself.
For a related case of attackers hiding behind trusted developer infrastructure, see our coverage of PoeLLM, which reads its command server address from a GitHub repository.
An infostealer on a developer laptop rarely announces itself. The signals are small: a ZIP pulled from an unfamiliar repository, a new process spawned from a downloads folder, a burst of credential-store access, then logins from a new location using freshly stolen tokens. Obiguard SOC is built to bring those signals together and watch them continuously, so an analyst can spot the chain from "unknown download" to "suspicious sign-in" and respond by revoking sessions and keys before the stolen material is used.
It does not stop a developer from clicking a Download button, and it cannot vet a repository for you. What it shortens is the time between a compromise and someone noticing it, which is the window in which stolen tokens turn into a larger breach.
If a developer in your organisation ran a fake AI skill from GitHub this morning, what is the first alert that would tell you, and how soon would it fire?
See how Obiguard SOC works or talk to us about monitoring your developer endpoints and identities.
Obiguard sits in front of every AI request your organization makes — screening prompts and outputs against the guardrails, compliance frameworks, and audit trails that stories like this one make necessary.
See how it works →