When developers look for open-source libraries, GitHub is often the first stop. That trust—the assumption that a repository with decent documentation and reasonable activity is legitimate—has become a critical vulnerability. The FakeGit campaign demonstrates this at scale, with nearly 7,600 malicious repositories now active on the platform, many masquerading as AI tools or Model Context Protocol servers to distribute SmartLoader malware.
The anatomy of repository-based distribution
What makes FakeGit effective is its attention to social engineering detail. The campaign doesn't rely on obscure, obviously suspicious repositories. Instead, attackers have cloned legitimate projects, created lookalike developer profiles, and written convincing README files that read like genuine documentation. More than 800 of these repositories specifically pose as AI skills or MCP servers—tooling that has seen explosive adoption among developers seeking to extend language models with external capabilities.
The distribution mechanism is straightforward: victims download what appears to be a legitimate ZIP file from a repository, extract it locally, and execute the contents as part of their build or development workflow. SmartLoader then establishes persistence and begins its payload delivery chain. From an attacker's perspective, GitHub provides free hosting, credible presentation surfaces, and organic discoverability through search—all without the operational overhead of maintaining a malware C2 infrastructure.
Why dependency chains remain fragile
This campaign highlights a structural weakness in modern development workflows. Most teams focus security audits on their direct dependencies—libraries explicitly declared in package manifests. Yet the attack surface extends far beyond package managers. A developer might search GitHub for a trending AI tool, find what looks like an active community project with recent commits and stars, and integrate it into their workflow with minimal vetting. The repository itself becomes the attack vector, and no standard vulnerability scanner catches it because technically, no known vulnerability exists until exploitation occurs.
The scale—7,600 repositories—suggests either significant automation in repo creation or a distributed network of collaborators. Maintaining that volume whilst keeping individual repositories plausible enough to avoid immediate takedown requires either compromised accounts or a steady stream of throw-away credentials. GitHub's reporting mechanisms will likely catch and remove batches of these repositories, but the pattern reveals a fundamental asymmetry: defenders must catch every malicious upload; attackers need only succeed once per target.
Practical implications for build security
Infrastructure and DevOps teams should treat external code discovery as a security-critical process. That means moving beyond simple reputation checks (fork count, star count) toward behavioural analysis. Does the project have a genuine commit history spanning months or years, with multiple independent contributors? Does the maintainer have other active projects and a verifiable presence outside GitHub? Are there actual issues and pull requests from unrelated users, or is the repository artificially static?
Containerised builds add another layer of protection. If developers are fetching external tools into isolated build environments rather than their local machines, lateral movement becomes more difficult. Code review for any third-party integration—even trusted-looking ones—remains essential. Some organisations now require explicit approval workflows for new external dependencies, enforcing a minimal vetting gate before code even enters the build pipeline.
Monitoring repository activity can also flag sudden shifts in behaviour. A project that was dormant for months and suddenly pushes new binary builds, or one where the maintainer suddenly changes the README to point to external download links, deserves scrutiny. Some organisations use GitHub's API to monitor their own import statements and alert when the upstream repository undergoes significant structural changes.
The broader pattern
FakeGit is not an isolated incident but a continuation of supply chain attacks that have plagued the ecosystem for years. NPM, PyPI, RubyGems, and other package repositories have all seen malware campaigns exploiting similar trust assumptions. GitHub, being the primary source for both published and unpublished code, remains an attractive distribution channel precisely because it looks legitimate and requires minimal adversary infrastructure investment.
The responsibility to address this threat is distributed. Platform operators can improve detection of coordinated inauthentic behaviour and increase friction for bulk repository creation. Maintainers should use 2FA and carefully guard their credentials. Developers need to cultivate healthy scepticism about code provenance. And teams responsible for infrastructure should implement layered defences: network segmentation, build isolation, signed commit verification, and behavioural monitoring.
Until these practices become standard, campaigns like FakeGit will continue exploiting the gap between the speed of development and the rigour of supply chain verification.
