SecurityArticle Ten thousand trojan repos vanished in hours, then came right back — and AI agents are now the targets.
Emeka Okafor A pseudonymous researcher at Orchid Files noticed clones of their own project on GitHub — full commit history intact, original contributors listed, one small addition: a "Download" link in the README pointing at a ZIP full of trojans. They wrote a script against GH Archive push-event data and found roughly 10,000 repositories matching the same fingerprint. After the findings hit the Hacker News front page in June, GitHub deleted all 10,000 within hours.
Then the researcher reran the script. It found fresh repositories immediately — and by the researcher's account, those stayed up for a month, despite the detection method being public, open source, and sitting on GitHub itself.
That second beat is the story. Not that malware exists on GitHub — it always has — but that a working, published detector changed nothing about the platform's posture.
This is a business, not an incident #
The campaign the researcher stumbled into isn't new or obscure. Trend Micro documented it back in March 2025: AI-generated fake repositories posing as game cheats and cracked software, delivering a LuaJIT-based (Smart) that drops Lumma Stealer, attributed to an actor they track as Water Kurita. In July 2026, researchers at Island mapped the current iteration — dubbed FakeGit — at nearly 7,600 repositories across 6,600 accounts, with campaign repos accumulating over 14 million downloads. More than 800 of those repos posed as AI skills or Model Context Protocol servers, and hundreds got themselves listed on public MCP registries for extra credibility.
Nor is the technique novel. Apiiro found over 100,000 malicious clone repositories in a 2024 "repo confusion" campaign. Check Point's Stargazers Ghost Network research the same year exposed thousands of accounts selling stars and forks as a service to make malware repos look loved. The playbook — clone something real, keep its history, add one poisoned link, buy social proof — has been running profitably for at least two and a half years. Deleting the current crop is a cost of doing business the attackers have clearly priced in: the FakeGit repos push identical "Update README.md" commits every few hours, an automation cadence that only makes sense if account and repo churn is routine.
The capability argument doesn't hold #
The most common defense — echoed in the Hacker News thread — is that proactive scanning at GitHub's scale is intractable, that string-based signatures are brittle, that anything the researcher's regex catches today gets trivially mutated tomorrow. All true in the narrow sense, and all beside the point.
GitHub already runs one of the largest real-time content-scanning operations in existence. Secret scanning checks every push to every public repository against hundreds of token patterns, and push protection blocks matching commits before they land. That system deals with adversarial evasion, false-positive pressure, and partner coordination across hundreds of credential issuers. The infrastructure, the ML pipeline, the abuse-handling muscle — it all exists. What the FakeGit campaign exploits isn't a scanning gap; it's an organizational one. Secret scanning lives in the product-security org and sells as part of GitHub Advanced Security. Malware-repo takedowns live in trust and safety, which is a cost center running a reactive, ticket-driven loop: report comes in, repos get deleted, ticket closes. Nobody's OKRs cover "the same actor re-registers tomorrow."
And the behavioral signals here are absurdly strong. Thousands of new accounts pushing README-only commits on a timer, to cloned repos whose only divergence from upstream is an external ZIP link — that's not a hard classification problem. Email providers kill spam campaigns with weaker signals at vastly larger scale. The honest version of GitHub's position isn't "we can't"; it's "this hasn't hurt anything we monetize."
It's about to hurt something they monetize #
Which is why the MCP angle matters more than the raw repo count. Fourteen million downloads of fake game cheats mostly burns consumers running cracked software — a population platforms have historically been comfortable writing off. But 800+ repos masquerading as MCP servers and agent skills, seeded into registries that agentic tools consume, targets developers directly — and increasingly, targets their agents. Island documented AI agents autonomously discovering and pulling these repositories with no human in the loop. An agent that resolves "add an Oura integration" by grabbing a trojanized MCP server from a registry is a supply-chain compromise with no download dialog and no moment of human skepticism to interrupt it.
That collision — malware distribution meeting Copilot-era agent workflows — is the thing most likely to force GitHub's hand, because it converts an abuse-desk problem into a product-trust problem for the business Microsoft actually cares about.
What to do while GitHub decides to care #
Practical takeaways, in rough priority order:
Stop treating repo presence as a trust signal. Commit history, contributor lists, and stars are all forgeable or clonable at zero cost. The FakeGit reposarelegitimate projects, byte-for-byte, except the README.Check the divergence, not the history. Before running anything from an unfamiliar repo, diff it against the project it claims to be, and treat any README linking to an external archive — especially a versioned ZIP — as hostile until proven otherwise. GitHub's own search (path:readme.md
plus an archive-pattern regex) surfaces these in seconds; that's the researcher's whole method.Lock down agent tool acquisition. If your coding agents can install MCP servers or skills, pin them to an allowlist you've reviewed. Public MCP registries currently do roughly zero vetting; several hosted FakeGit listings. Auto-discovery of tools from open registries is, today, an unpatched RCE vector for your dev environment.Demand provenance where it exists. Prefer releases with artifact attestations or signed builds over bare ZIPs. A repo whose releases can't be traced to its own CI shouldn't clear review.
The verdict on the headline question — what does GitHub's security team even do? — is that it does quite a lot, just not this. GitHub's product-security story is genuinely industry-leading; its platform-abuse story is a ticket queue. Those two facts can coexist for exactly as long as the victims are people down Photoshop cracks. With agents now fetching their own dependencies from GitHub's namespace, that grace period is over, and the fix — turning the researcher's weekend script into a first-party behavioral pipeline — is well within reach of a company that already scans every push on the platform. Whether it ships is a priorities question, not an engineering one.
Sources & further reading #
[What does GitHub's security team even do?](https://orchidfiles.com/github-security-team/)— orchidfiles.com -
[I discovered a large-scale malware distribution on GitHub](https://orchidfiles.com/github-repositories-distributing-malware/)— orchidfiles.com -
[What does GitHub's security team even do? (discussion)](https://news.ycombinator.com/item?id=49061769)— news.ycombinator.com -
[FakeGit Campaign Uses 7,600 GitHub Repositories to Spread Smart Malware](https://thehackernews.com/2026/07/fakegit-campaign-uses-7600-github.html)— thehackernews.com -
AI Assisted Fake GitHub Repositories Fuel Smart and LummaStealer Distribution— trendmicro.com
Emeka Okafor· Security Editor Emeka has spent over a decade tracking threat actors, vulnerability disclosures, and the evolving landscape of application security, bringing a sharp continent-spanning perspective to his reporting. He's known for translating dense CVE advisories into clear, actionable context that developers and security teams alike actually read.
Discussion 0 #
No comments yet
Be the first to weigh in.