FakeGit Campaign Exploits GitHub's Open Model to Distribute SmartLoader Malware at Scale
A campaign termed FakeGit has created approximately 7,600 malicious GitHub repositories, with over 800 impersonating AI tools and Model Context Protocol servers to deliver SmartLoader malware. The campaign exploits GitHub's accessibility and developer trust in open-source repositories to achieve broad distribution.
Affected
FakeGit represents a mature evolution in supply-chain attacks, shifting from compromising legitimate repositories to creating entirely fabricated ones at industrial scale. The campaign's infrastructure spans nearly 7,600 repositories, with a significant subset (800+) specifically mimicking AI skills and Model Context Protocol servers, suggesting targeted abuse of contemporary developer interests. The sophistication lies not in novel malware or zero-day exploitation but in social engineering at scale: lookalike developer profiles, convincing README files, and directory structures that pass cursory inspection by developers under time pressure.
The technical approach is straightforward but effective. Attackers clone or imitate legitimate projects, inject SmartLoader malware into build scripts or dependencies, and host the result under profiles designed to deceive. The malware family itself (SmartLoader) likely functions as a loader stage, downloading secondary payloads after establishing persistence. This modular approach allows operators to adapt final-stage payload delivery without redeploying the initial attack surface.
Developers represent the attack surface here, not end-users. The threat model assumes that developers will install dependencies from repositories that appear legitimate without thorough verification. This reflects a real behavioural pattern: developers often prioritise speed and convenience, particularly when onboarding new tools or libraries. The targeting of AI and MCP-related projects is deliberate, capitalising on recent adoption waves and the genuine difficulty distinguishing between emerging legitimate projects and fakes.
Organisations and developers should implement several countermeasures immediately. Repository verification practices should extend beyond names and descriptions to include author history, publication timestamps, and statistical signals of project maturity. Pip, npm, and other package managers offer enhanced security features including signature verification and provenance checks; these should be enabled. Dependency analysis tools that flag repositories with suspicious characteristics (new accounts, rapid uploads, unusual code patterns) can provide early warning. At the organisational level, pinning dependencies to verified versions and conducting code review of supply-chain additions before deployment provides a critical control layer.
The campaign's scale and persistence indicate this is neither a research project nor a one-off incident. The 7,600 repositories suggest either an extremely well-resourced operator or a service offered to multiple threat actors. This underscores a fundamental asymmetry: defenders must verify every dependency, while attackers need only maintain a fraction at sufficient quality to achieve infections. The broader implication is that GitHub-scale open-source platforms will remain attractive attack surfaces, and that platform-level detection and response mechanisms remain inadequate relative to the volume of malicious content that can be hosted.
Sources