FakeGit Turns AI Skill Discovery into a Malware Supply Chain
Installing a new AI skill or Model Context Protocol (MCP) server can look like ordinary developer work: find a repository, follow its README, download a package, connect the tool. The FakeGit campaign shows why that workflow now deserves the same scrutiny as adding a production dependency. Researchers at Island reported a network of roughly 7,600 malicious GitHub repositories, more than 800 of which presented themselves as AI skills or MCP servers, to distribute SmartLoader and subsequent information-stealing malware.
The important shift is not just scale. The campaign uses convincing project names, copied code, lookalike developer profiles and plausible READMEs to make discovery itself part of the attack chain. A person may follow the instructions; an AI agent asked to find and explain a capability can surface the same repository. Neither event should be treated as a trust decision.
What FakeGit changes
According to Island's research, the campaign's repositories point users toward ZIP archives that initiate a loader chain, then deliver SmartLoader and, in reported cases, the StealC infostealer. The operation has been described as AgentBaiting: attackers prepare discoverable lures for people and for agents that search public repositories, skills or MCP registries on a user's behalf.
An agent that merely recommends an unsafe project is not the same as an agent that downloads or executes it. But organisations frequently blur those permissions. A chatbot that can read untrusted repository content, invoke a shell, write a config, access browser sessions or use a developer token creates a much shorter path from search result to impact.
Make capability installation a controlled change
- Use an allowlist. Maintain an owned catalogue of approved skills, MCP servers, extensions and package versions. A public listing is discovery infrastructure, not an endorsement.
- Verify the publisher and artefact separately. Check the canonical project, maintainer history, releases, signatures or hashes where available, and inspect the exact archive that will run. A familiar README is not evidence that a download is safe.
- Sandbox evaluation. Test an unapproved capability in an isolated, disposable environment with no production credentials, source repositories, browser profile or network reach to sensitive services.
- Keep agents least-privileged. Split discovery, analysis and execution. An agent that searches the web should not inherit a shell, deploy key, cloud credential or approval to install software.
- Log and review changes. Record who approved a new capability, the source and version, granted permissions, checks performed and where it is enabled. Revoke it quickly when a supplier issue emerges.
Detecting the risky pattern
Alert on execution of installers from temporary download paths, unreviewed ZIP archives, unusual script interpreters and new outbound connections from developer workstations or agent sandboxes. Review agent and CI logs for installation commands or instructions originating from repository text. The goal is not to block every new tool; it is to stop untrusted content from silently becoming an instruction with authority.
The durable lesson
AI-capability ecosystems are software supply chains. Treat skills, MCP servers, prompts that fetch tools and agent plugins as executable dependencies with an owner, provenance, a review path and a removal plan. That posture remains useful even after this specific campaign disappears.
