The FakeGit campaign shows how attackers are industrializing abuse of GitHub to distribute malware through fake open-source projects.

Researchers reported that the campaign used more than 7,600 malicious GitHub repositories to spread SmartLoader malware. The repositories copied legitimate projects, used lookalike developer profiles, included convincing README files, and hosted malicious ZIP files through GitHub Releases.

This is especially dangerous because GitHub is trusted by developers, IT teams, security researchers, students, and AI builders. A repository with clean-looking documentation, project structure, stars, releases, and developer-style language can appear legitimate enough for users to download and run code without deeper inspection. Apparently, a polished README has become the digital equivalent of wearing a lab coat in a scam.

The scale of the campaign matters. This was not one fake repository or a handful of typo-squatted packages. Thousands of repositories were created to increase reach, improve search visibility, and make takedown harder. Even if some repositories are removed, others may continue driving downloads through search engines, AI assistants, social links, or copied instructions.

The campaign also targeted the AI development ecosystem. More than 800 repositories reportedly posed as AI skills or Model Context Protocol servers. That is a smart and troubling choice by attackers. AI developers are actively searching for new tools, connectors, agents, MCP servers, automation scripts, and integration examples. Attackers know this demand creates a perfect opening for fake projects.

The AI angle creates another risk: coding assistants and AI agents may surface malicious repositories during normal development tasks. If an AI assistant recommends a fake repository because the README looks useful and the project name matches the task, the user may trust the suggestion. This turns AI-assisted development into another discovery path for malware.

The malware distributed through FakeGit, SmartLoader, can act as a loader for further payloads. That means the first download may only be the beginning. Once executed, the malware may install additional components, steal credentials, establish persistence, download infostealers, or prepare the system for follow-on attacks.

For businesses, the risk is especially serious on developer machines. Developer systems often contain GitHub tokens, SSH keys, cloud credentials, npm or PyPI tokens, API keys, browser sessions, VPN access, build secrets, and access to private repositories. A malware infection on one developer workstation can quickly become a software supply-chain incident.

Organizations should warn developers not to trust GitHub repositories based only on search ranking, stars, README quality, or familiar-sounding project names. Before downloading or running tools, users should verify the official project source, maintainer history, release signatures, repository age, commit activity, issue history, and whether the repository is referenced from the vendor’s official website.

Security teams should monitor for execution of downloaded ZIP contents from GitHub Releases, suspicious installer behavior, unexpected outbound connections, new persistence entries, credential-store access, and malware launched from temporary or downloads folders. Developer endpoints should be monitored with the same seriousness as production-adjacent systems, because that is what they are.

Organizations should also review controls around AI-assisted coding. Developers should not blindly execute commands, install tools, or clone repositories suggested by AI assistants without verification. AI tools can help find libraries, but they should not become trusted software-supply-chain authorities. A chatbot recommendation is not provenance. It is a suggestion from a very confident autocomplete machine.

For AI and DevOps teams, any MCP server, AI skill, plugin, agent tool, or automation connector should be treated like executable third-party software. It may access files, tokens, APIs, local environments, browsers, and internal systems. That means it needs review, sandboxing, least privilege, and controlled rollout.

Organizations should maintain internal approved-tool repositories or mirrors for commonly used developer utilities. Instead of allowing every developer to pull unknown tools from public GitHub, teams should validate tools once, document trusted sources, and distribute approved versions through controlled channels.

Security teams should also consider blocking or warning on direct execution from untrusted archives, unsigned binaries, newly created GitHub repositories, and projects with suspicious release patterns. DNS filtering, web reputation checks, EDR behavior rules, and software allowlisting can all help reduce exposure.

If a developer downloaded or executed software from a suspicious repository, the response should include endpoint isolation, malware analysis, review of process history, outbound connections, persistence checks, and credential rotation. GitHub tokens, SSH keys, cloud secrets, package registry tokens, and API keys accessible from the machine should be considered at risk.

The key lesson is that open-source trust cannot be outsourced to platform familiarity. GitHub is a hosting platform, not a guarantee that every project is safe. Attackers are now creating fake repositories at scale, copying legitimate project patterns, and exploiting both human trust and AI-assisted discovery.

FakeGit is a reminder that software supply-chain security starts before code reaches production. It starts when a developer searches, clones, downloads, installs, and runs a tool. Every one of those steps is now an attack surface.

Organizations should treat public repositories as untrusted until verified, especially when they involve AI tools, developer utilities, security software, crypto tools, or anything that asks to run locally. The internet has many helpful projects, but it also has attackers with automation, fake profiles, and enough patience to build 7,600 traps.

Cybersecurity researchers have discovered nearly 7,600 malicious GitHub repositories, out of which more than 800 pose as artificial intelligence (AI) skills or Model Context Protocol (MCP) servers to deliver a malware family known as SmartLoader as part of an ongoing campaign codenamed FakeGit. "FakeGit uses copied projects, lookalike developer profiles, convincing READMEs, and malicious ZIP

Source: FakeGit Campaign Uses 7,600 GitHub Repositories to Spread SmartLoader Malware via The Hacker News — published 20 Jul 2026.