A Massive Trust Exploit Hides In Plain Sight On GitHub
A newly documented campaign, dubbed FakeGit, has used roughly 7,600 malicious repositories to distribute a loader known as SmartLoader.
The loader delivers StealC, a powerful information-stealing malware. Meanwhile, the operation appears to stem from a single actor rather than a coordinated group. Around 6,600 GitHub profiles were created solely to support this effort.
GitHub’s own download counters recorded over 14 million download events tied to campaign files. However, that number reflects automated requests as much as real victims. Still, even a fraction of that scale represents a serious risk to developers and everyday users alike.
Fake Popularity Signals Make Malicious Repos Look Legitimate
Attackers will usually not depend on luck when building trust with a repository, they will manufacture it through marketing techniques.
For instance, one of the repositories had adopted the name and structure of a popular project to gain a few stars and forks as proof of credibility.
There was an attempt by some of the malicious users to adopt a similar username to that of actual developers, only that the usernames differed by one letter.
The following are some of the disguises used:
- Cracked versions of SaaS browser extension (Notion, Slack, Trello)
- Gaming cheats for Roblox, Fortnite, Valorant
- Cryptocurrency/trading tools
- AI written README with formatted content and description with emojis
- Enterprise tools impersonation (Jenkins, Docker, Databricks)
Most READMEs were easily identified to be AI generated due to unusual grammar and verbose nature, though good enough to deceive in a glance before downloading.
What The Fake Repo Pages Actually Look Like Up Close
Upon closer inspection, there is some sophisticated deceit in a malware repository. From the visual standpoint, it is a perfect clone of an open-source project, star and fork counters, commit history, and README file with badges and sections.
However, it is not actually active community involvement. The stars and forks are fake, commit times are evenly distributed to create the illusion of growth of the project. The README includes information on installation and concludes with a clear button-looking link for downloading the release.
It does not take you to the source code. Instead, it takes you to a packed ZIP file in the Releases section exactly where it belongs. From the visual aspect, it looks like a regular release asset.
AI Coding Assistants Are Now Being Baited Too
It has been found that over 800 repositories in the campaign posed specifically as AI Skills or Model Context Protocol servers, which are increasingly used to extend coding assistants.
While testing, AI coding tools including Claude Code, Gemini, and ChatGPT were asked to find and install free AI capabilities. In several cases, these agents autonomously surfaced malicious repositories without any link being provided by the user.
This matters because AI agents increasingly search, evaluate, and recommend tools independently. Consequently, when an agent trusts GitHub’s popularity signals the same way humans do, it can be manipulated identically. And some agents did recognize red flags and refused to proceed, though results varied across different tests and prompts.
Part Of A Much Bigger Pattern Of Platform Abuse
Thousands of faked accounts and repositories with artificial stars and forks for the simultaneous release of multiple stealer families. Yet another campaign leveraged GitHub Action workflow jobs and targeted automated build pipelines rather than downloaded repositories.
Nearly 10,000 cloned repositories belonging to the same malware family, which is an exponential increase compared to only a few months before.
The clones re-released the exact commit every several hours with the same generic comments, thus creating the illusion of active development. This is yet another example of a structural problem, not a particular solution.
Clones inherit the full trust immediately, while moderation cannot counteract automated abuse on a large scale. Without better provenance checks from the platform side, this attack vector would remain widely available.
Conclusion: When Trusted Discovery Becomes Malware Execution
FakeGit shows that attackers no longer need to compromise a trusted platform to weaponize its reputation. So they can manufacture credibility with copied projects, lookalike developer profiles, artificial stars, polished READMEs, and Release files placed exactly where legitimate software should appear.
Why This Threat Matters
FakeGit turns software discovery into the first stage of malware delivery.
- Thousands of repositories create scale and resilience
- Lookalike profiles and fabricated activity imitate legitimate development
- AI Skills and MCP servers place the campaign inside emerging enterprise workflows
- Agents can surface malicious repositories without receiving a direct attacker link
- Renamed runtimes and disguised payload files reduce visible warning signs
- Blockchain-based C2 resolution allows infrastructure to be rotated
- Encrypted stages retrieved through GitHub make trusted infrastructure part of the delivery chain
- StealC targets passwords, cookies, active sessions, wallets, and developer credentials
The reported download totals represent activity, not confirmed infections. But the campaign does not need every download to succeed. A single compromised developer workstation can expose browser sessions, cloud access, source repositories, and production tooling.
Where Xcitium Changes the Outcome
Xcitium Advanced EDR, powered by Xcitium’s patented Zero-Dwell platform, applies Execution Governance when the downloaded package attempts to run.
GitHub origin should not grant the launcher automatic trust.
Likewise, a renamed Lua runtime should not receive unrestricted access merely because the user started it.
The disguised payload should not inherit the rights of the developer or AI workflow that discovered it.
Unknown code does not receive unrestricted execution rights.
Code can run without being able to cause damage.
Runtime behavior is governed before trust exists.
SmartLoader and its follow-on payloads may attempt to execute, but they should not receive unrestricted access to browser data, developer credentials, cloud tokens, source code, persistence mechanisms, or the real operating environment.
Xcitium ITDR strengthens the next layer when stolen sessions, OAuth grants, tokens, or privileged credentials are reused against enterprise services.
Detection asks, “Did we recognize this repository or payload as malicious?”
Execution Governance asks, “Could unknown code discovered through a trusted platform cause damage at all?”
That is the difference.
Trust the Source Less. Govern the Execution More.
FakeGit proves that stars, forks, familiar usernames, professional documentation, registry listings, and AI recommendations are not proof of software integrity.
Security teams should maintain approved catalogs for AI Skills, MCP servers, plugins, and developer tools. New capabilities should be tested away from live sessions, cloud credentials, SSH keys, source repositories, and production data. Suspected infections require token rotation and session revocation, not only password changes.
Verify the publisher.
Inspect what the archive actually contains.
Govern every unknown process before repository trust becomes endpoint compromise.
