A fake MCP server spent three months earning trust. The tells were there

In February, researchers at Straiker STAR Labs documented a supply chain operation that should reset how you vet MCP servers. A malware operation known as SmartLoader spent three months constructing a fake developer ecosystem: five GitHub accounts with AI generated personas, repos cross forked to simulate an active community, all wrapped around a trojanized Oura Ring MCP server. Then it was submitted to a legitimate MCP market registry.

Three months of patience. Fake commit history, fake people, fake social proof. The old advice, check the GitHub profile, check the stars, dies exactly here. Every signal on that page was farmed on purpose.

Why this works on developers

We pattern match fast. Active community, reasonable README, commits flowing in: install. The whole vetting ritual takes ninety seconds and predators know the ritual. The fake ecosystem was built to pass the ritual, not to survive scrutiny.

What is still hard to fake

Deep fakes of activity are cheap. Sustained, specific, boring history is expensive. These tells survived the operation and they survive the next one:

1. Issue history with real back and forth. Real projects have dumb questions, maintainers asking for versions, and threads that end in “closing, fixed in X”. Farmed repos have quiet issue tabs or drive-by star activity.
2. A company that exists outside GitHub. Domain, docs site, people you can find being wrong about other things in public. Personas that only exist inside one repo graph are a finding.
3. Release rhythm versus commit noise. Real projects have boring changelogs. Farmed ones have bursts, version jumps, or commits that describe nothing you can verify.
4. Maintainer overlap. If the same five accounts appear across several “different” projects in the same niche, you are looking at a company of ghosts.
5. The install count provenance. Big numbers with no corresponding ecosystem, no blog posts, no issues mentioning the project anywhere else, are decoration.

The vetting checklist I run now

Before any MCP server goes into a config I care about:

• Who is behind it, verifiable outside the repo
• Issue quality over issue count
• Changelog realism
• Permissions requested versus purpose. A ring sleep tracker does not need shell access
• First run in a container with no credentials and an egress watch. If it phones home to somewhere unexplained, done
• Config scan for secrets handling and risky patterns. I use my own scanner for this, any equivalent works

The registry is not your threat model. Registries will tighten, add review queues, maybe attestation. Attackers will adapt, the same way they adapted to app stores. The install decision stays yours.

The browser extension ecosystem went through this exact era. We know how it went. The developers who internalized “the marketplace listing proves nothing” were the ones who stayed out of the incident reports.

I publish pieces like this on MCP and AI-agent security regularly, so bookmark if you’d rather not lose it in your feed.

Sources

• UpGuard writeup of the Oura Ring operation and five other incidents: https://www.upguard.com/blog/mcp-security-incidents
• CSA research note on systemic MCP exposure: https://labs.cloudsecurityalliance.org/research/csa-research-note-mcp-security-crisis-20260504-csa-styled/

---

If you want to run checks like these on an MCP server or a .claude/ directory before you install it, I maintain mcpscan, an open-source scanner for tool poisoning, risky permissions and leaked secrets. Issues and false-positive reports are welcome.

Originally published on DEV. Discussion happens there.