FakeGit Campaign Plants SmartLoader Malware Inside Nearly 7,600 GitHub Repositories

A sprawling supply-chain attack called FakeGit has seeded close to 7,600 malicious repositories on GitHub, with more than 800 of them impersonating artificial intelligence tools, according to security researchers who mapped the campaign.

What FakeGit Actually Does

The mechanics are deceptively simple. A developer searches for an AI helper, finds what looks like a polished project, and downloads a ZIP archive. The moment they unpack it and run the setup, a malware loader called SmartLoader executes silently in the background.

SmartLoader is not the final payload. It is the delivery mechanism. Once it establishes a foothold, the operators can push password stealers, remote-access trojans, or cryptocurrency wallet drainers onto the machine at will. The developer thinks they just installed an AI assistant. They have actually handed someone else the keys.

Why Developers Are Falling For It

The bait is well chosen. AI tooling is the single hottest category of software any developer wants right now. Some of the fake repositories pose as Model Context Protocol servers, a relatively new interface standard that lets AI assistants like Claude connect to external data sources. That is a technically credible-sounding concept, which makes the decoy harder to dismiss on sight.

The FakeGit operators invest real effort in presentation. They clone legitimate open-source projects, copy the names and profile avatars of respected developers, and write README files in fluent, professional English. Nothing looks obviously wrong. That is the point.

GitHub's star system, which developers rely on as a rough quality signal, can be gamed. Profiles created within the past few weeks sometimes carry inflated star counts. The issue tracker is empty, there is no pull-request history, and no one outside the repository's own comment section is discussing the code. Individually, each of those flags is ignorable. Together, they paint a picture.

The Supply-Chain Blast Radius

This campaign does not threaten only the individual developers who download the bad code. It threatens everyone downstream.

A compromised developer laptop can yield cloud-provider keys, internal source code, authentication tokens for production systems, and customer data. One poisoned download can become a full corporate incident. The Verizon 2024 Data Breach Investigations Report found that supply-chain and software dependency attacks have grown steadily as a breach vector, precisely because a single upstream compromise can propagate to dozens of organizations simultaneously.

Small engineering teams, freelancers, and startup developers are especially exposed. They often lack the sandboxed testing environments that larger security teams mandate, and they move fast because speed is a competitive advantage. Attackers know this.

The Control That Failed: Developer Security Awareness

The root failure here is not technical. GitHub has takedown processes, and security tools can scan packages for known malicious signatures. Yet FakeGit kept spinning up fresh repositories as fast as the old ones were removed, reaching nearly 7,600 at its peak count. Volume is the strategy. The operators bet that if they publish enough convincing fakes, some percentage of developers will always slip through.

The control that failed is the human one. Developers are trained throughout their careers to trust open source, to share freely, to assume that code on a reputable platform has passed some implicit community review. FakeGit weaponizes that cultural habit. There was no phishing email to flag, no suspicious link to hover over. The attacker placed malicious content exactly where developers expected to find legitimate content, and waited.

That is why security-awareness training for technical staff cannot stop at phishing simulations. Engineers need specific education about supply-chain risks, repository vetting habits, and the social-engineering techniques attackers use to fake credibility in developer spaces.

What the Scale Tells Us

Close to 7,600 repositories is not a hobby project. Operating at that volume requires automation, rotating accounts, and probably a team. The campaign has the hallmarks of an organized criminal operation rather than an opportunistic individual.

GitHub serves more than 100 million developers worldwide. Even a tiny conversion rate on 7,600 malicious repositories produces a meaningful number of infected machines. And those machines belong to people who build the software that everyone else uses.

What Defenders Should Do Now

Four practices will reduce exposure significantly.

First, verify repository age and activity before trusting any project. A profile created in the last 30 days with a single, polished AI tool and no development history deserves intense skepticism.

Second, run unfamiliar code inside an isolated virtual machine or container before allowing it anywhere near a corporate network or a machine with stored credentials.

Third, review what packages are actually being installed during any setup process. ZIP archives that execute scripts on extraction should trigger immediate review.

Fourth, check whether the project is referenced or discussed by the real developer community outside GitHub itself. A genuine tool will have forum threads, blog posts, or social mentions that pre-date the repository's creation. A fake one will not.

Organizations can also review how Train2Secure approaches developer-focused security programs to understand what structured training looks like at scale. The goal is building the instinct to pause and verify, not just react after something goes wrong.

GitHub is actively removing FakeGit repositories as they are reported. The operators keep rebuilding. Until vetting habits change at the individual developer level, the campaign will keep finding new victims.