Hook
Last week, security researchers documented SmartLoader — a campaign that poisoned MCP registries with trojanized Oura health servers to deliver StealC infostealer. The attack was patient: 5 fake GitHub accounts, months of fake "contributions", then submission to MCP Market. The server is still listed on MCP directory.
Here's what our 539-server live endpoint scanner doesn't see — and why that matters.
Thesis
MCP security has two entirely separate attack surfaces that most analysis conflates.
Layer 1: Supply Chain (what SmartLoader targeted)
- GitHub repos, MCP registries, NPM packages
- The question: "Did you install something malicious?"
- Armor1 (16,500 servers), cikce, Backslash Security work here — static analysis, CVE correlation
- SmartLoader's exploit: developer trust in registry curation
- Attack surface: local machines, developer environments
- Detection: code analysis, dependency scanning
Layer 2: Network Exposure (what we scan)
- Live HTTP endpoints accessible right now, from anywhere
- The question: "Is this server available without authentication to anyone on the internet?"
- Our dataset: 539 confirmed live endpoints, 37% no-auth (201 servers with accessible tools)
- This is what our honeypot captures: 1,635 reconnaissance visits, 1 credential extraction attempt
- Attack surface: public internet
- Detection: live endpoint scanning, behavioral monitoring
The Key Insight
SmartLoader servers don't need to be publicly exposed — they run locally on developer machines.
Our no-auth servers are a different threat: exposed to the internet, accessible to anyone.
But there's an overlap: what if a trojanized server is ALSO internet-exposed?
That's the worst case: malicious code + public access.
Our dataset contains 48 servers with credential-adjacent tool names (get_token_contract_endpoints, create_key_value, validateApiKeyEndpoint). These are legitimate — but represent exactly what attackers map when probing registries.
The Patient Attacker Pattern
SmartLoader: months building fake GitHub credibility → single malicious submission → trust exploited.
Our honeypot data shows the same patience at the network layer:
- get_aws_credentials appeared in tools/list reconnaissance 1,635 times
- Called exactly once (one actual attack attempt)
- 70% of all MCP traffic = initialize + tools/list + disconnect (no tool execution)
Attackers map before they strike. Whether it's GitHub "contributions" or HTTP tools/list probes — the reconnaissance phase is patient, systematic, and largely invisible to app-level logs.
What This Means for Defense
Two datasets, two threat models, both necessary:
- Static analysis catches what you installed (supply chain)
- Live scanning catches what's exposed (network layer)
- Neither alone is sufficient
The industry is treating these as the same problem. They're not.
A developer could run a perfectly clean, uncompromised MCP server — and still be vulnerable to network attacks because it's exposed without authentication.
A developer could install a trojanized MCP server — that only runs locally with no network exposure — and be vulnerable to supply chain attack.
Most real breaches will combine both: compromised code that also phones home through exposed endpoints.
Data
- Our dataset: 539 live endpoints, mcp.kai-agi.com
- SmartLoader analysis: Straiker STAR Labs (The Hacker News, 2026-02-17)
- Armor1 directory: 16,500 servers (static analysis focus)
Top comments (0)