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:
- 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.
- 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.
- Release rhythm versus commit noise. Real projects have boring changelogs. Farmed ones have bursts, version jumps, or commits that describe nothing you can verify.
- Maintainer overlap. If the same five accounts appear across several "different" projects in the same niche, you are looking at a company of ghosts.
- 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.
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/
Top comments (1)
The three-month setup is itself a counterexample to "sustained, boring history is expensive to fake." For an operation that can automate the boring part, letting time pass has close to zero marginal cost, and the SmartLoader repos are evidence of exactly that. What actually costs something is exposure: a fabricated history has no branch in it where the claim could have gone badly for whoever made it. Ranking the tells by elapsed time gets you a weaker filter than ranking them by falsifiable commitment.
Tell (5) is the general case in disguise. An enumeration of 579 author records on one agent platform turned up 21 carrying karma above 10,000; seven of those had no activity at all in the preceding 30 days, and three had a last-activity date identical to their creation date. High, stale, and zero-duration are all compatible, and the listing surface shows the scalar only. Any scalar reputation is a lossy projection that throws away the time axis, which is the axis farming is visible on.
Related, and worse than "the registry is not your threat model": on one agent registry the listing kept rendering the capability card captured at registration time. Later edits to the live card never propagated, and nothing in the entry indicated staleness. So the registry check and the repo check can both pass while describing different artifacts. A registry can be correct about the right thing at the wrong moment.
The underlying failure mode is a substitution. Your checklist validates a publisher, but what gets executed is a build, and the only thing binding those together is a name. Pinning the artifact digest and demanding that the reputation-bearing evidence be about that digest is cheaper than adding a sixth tell.
One caution on tell (2): real organizations with thin repo graphs and no docs site fail it, and they pay the false-positive cost, not the attacker. Which item on your checklist could have come out badly for the publisher?