[Blog](/blog) Show links Resources [Blog](/blog) [Breaches](/breaches) [eBooks, reports, & more](/resources) [Events](/events) [News](/news) [Attack Surface Management](/category/attack-surface-management) Show links Categories [Attack Surface Management](/category/attack-surface-management) [Company News](/category/company-news) [Compliance and Regulations](/category/compliance-and-regulations) [Cybersecurity](/category/cybersecurity) [Data Breaches](/category/data-breaches) [DevOps](/category/devops) [Human Cyber Risk](/category/human-cyber-risk) [Risks and Vulnerabilities](/category/risks-and-vulnerabilities) [Third-Party Risk Management](/category/third-party-risk-management) [Vendor Risk Management](/category/vendor-risk-management) [1 in 15 MCP Servers are Lookalikes: Is Your Org at Risk?](/blog/mcp-server-lookalikes) Publish date May 12, 2026 {x} minute read # 1 in 15 MCP Servers are Lookalikes: Is Your Org at Risk? [Get a demo](/contact-sales) [Free trial](/demo) [Download the PDF guide](/resources/complete-guide-to-attack-surface-management) [Free trial](/demo) Written by [Shane Moosa](/team/shane-moosa) Content Writer Shane is a cyber writer with a software development background. Reviewed by [Kaushik Sen](/team/kaushik-sen) Chief Marketing Officer Kaushik has a background in software engineering, enterprise solution architecture, and data analytics. He brings a unique, data-driven perspective to cybersecurity education. Table of contents eBook A Complete Guide to Attack Surface Management Free resource ### A Complete Guide to Attack Surface Management Monitor and secure your most critical data and assets through Attack Surface Management [Download now](/resources/complete-guide-to-attack-surface-management) Researchers recently analyzed 18,000 Claude Code configuration files pulled from public GitHub repositories. What they found was straightforward and alarming: developers are already installing mistyped, misconfigured, and near-identical MCP server names — often without realizing it. The human-error condition that makes typosquatting work was already present at scale before any attacker needed to exploit it. That research was published by UpGuard. The registries it examined — Smithery.ai, MCP.so, and the official GitHub MCP Registry — are the same ones that threat actors have already begun operating in. This post is about what they found, what it means for your organization, and what one real supply chain attack looked like when it played out over four months in 2025. ## The two ingredients every typosquatting attack requires Typosquatting is not a new concept. It has been a documented attack method in software package registries — npm, PyPI, RubyGems — for years. The mechanics are the same regardless of the ecosystem. First, an attacker registers a name that is visually close to a legitimate, trusted tool. Then, a user makes a small error — a missing letter, a transposed character, an incorrect capitalization, and moves to the last stage, where they install the attacker's version instead of the legitimate one.  Staging this kind of attack is unsuspectingly simple, as typosquatting only requires two ingredients: **Accessibility** (the ability to create lookalike resources) and **Human Error** (a user making a "fat-finger" mistake). [In the MCP ecosystem, both are currently present](https://www.upguard.com/blog/typosquatting-in-the-mcp-ecosystem) at a level that should concern any security leader. * **The "silent" match:** If names aren't case-sensitive, "UpGuard" and "upguard" are the same. A typosquatted server could be deployed without the user ever seeing a conflict. * **The "lookalike" identity:** If names *are* case-sensitive, an attacker can register hubspot alongside the legitimate HubSpot. Without a central registry to enforce unique ownership, users are left to guess which is genuine. **Deep Dive:** For a full technical breakdown of our analysis of those 18,000 developer files, read [our original research on typosquatting in the MCP ecosystem.](https://www.upguard.com/blog/typosquatting-in-the-mcp-ecosystem) ## A registry landscape defined by inconsistent governance Not all MCP registries carry equal risk. Understanding the governance posture of each is the first step in making an informed decision about where your developers should and should not source tools. | Registry | Approx. Scale | Moderation Posture | Risk Profile | | ------------------- | --------------- | ----------------------------------- | --------------------------------------- | | GitHub MCP Registry | \~57 servers | Official only; highest governance | Very low; extremely narrow scope | | Smithery.ai | 3,500+ servers | Community-submitted; 92% unverified | High brand impersonation surface | | MCP.so | 16,500+ servers | Unmoderated | Highest risk: 3–15 lookalikes per brand | The practical reality for mid-market organizations is that developers do not browse the 57-server official registry first. They search Smithery or MCP.so, because those platforms are where the tools they actually need are listed.  It's these moderately to near-unmoderated platforms where the risk concentrates, and is also where small oversights can lead to massive consequences, as the MCP ecosystem is orders of magnitude easier for opportunistic attackers to target. ## Case study: The SmartLoader supply chain attack (Feb 2026) In February 2026, [researchers at Straiker published findings](https://www.straiker.ai/blog/smartloader-clones-oura-ring-mcp-to-deploy-supply-chain-attack) on what may be the most instructive MCP supply chain attack to date — not because of its technical sophistication, but because of what it reveals about attacker economics and intent. The threat actor was SmartLoader, an established malware operation previously focused on distributing infostealers through fake pirated software download sites. The decision to pivot infrastructure toward [the MCP ecosystem](https://www.upguard.com/blog/mcp-ai-protocol-expanding-your-attack-surface) was deliberate and calculated.  Developers hold concentrated, high-value credentials — cloud service logins, GitHub tokens with CI/CD access, cryptocurrency wallets, and database credentials. Shifting to target them when MCP servers are a critical vulnerability within their workflow is not just logical, but it should be expected. ### Phase 1: Target selection SmartLoader chose the Oura Ring MCP server as its clone target. The original was created by an OpenAI engineer and distributed via GitHub. Its user base — productivity-focused developers integrating wearable health data into AI workflows — was precisely the demographic SmartLoader wanted to reach: technically sophisticated, credential-rich, and accustomed to self-sourcing developer tools. ### Phase 2: Fake ecosystem construction (three months) Five fake GitHub accounts were created with AI-generated developer personas. Each account cross-forked the others to manufacture the appearance of an active community of contributors. Forks accumulated. Apparent activity increased.  Over three months, the attacker built enough surface credibility to pass a casual review. This phase required patience, not technical skill — which is significant, because it means the barrier to replication is low. ### Phase 3: Trojanized repository A malicious fork was published. The code appeared functionally identical to the legitimate Oura Ring MCP server. The payload was embedded in a file called resource.txt, containing a LuaJIT script. The technical obfuscation was layered: 443-state virtual machine obfuscation, octal string encoding, and chunked assembly techniques designed to defeat static analysis. One indicator of compromise stood out: the original author of the legitimate server was excluded from the contributor list on the malicious fork. Legitimate forks always include the original creator. The absence was the tell — but only if you knew to look for it. ### Phase 4: Registry poisoning The trojanized repository was submitted to a legitimate MCP market registry. It appeared alongside genuine community contributions. No visual distinction. No warning. No moderation review flagged the submission. #### **The payload: StealC infostealer**  On execution, it exfiltrated browser saved passwords, cloud service session cookies, Discord tokens, cryptocurrency wallet files, SSH keys, and API credentials — silently, before any user noticed abnormal behavior. The persistence mechanism was disguised as a legitimate Windows audio process: RealtekAudioManager\_ODMw\.exe. [Standard endpoint detection](https://www.upguard.com/blog/endpoint-detection-and-response) tools that rely on process name recognition would not flag it. ## What your team can do this week For a lean security team, the immediate actions are practical and achievable: **1. Search your brand in community registries now.**  * Open Smithery.ai and MCP.so and search your organization's name, product names, and the names of any developer-facing tools you operate. If you find unofficial servers using your brand, document them — this is both a third-party risk item and a potential reputational exposure for your customers. **2. Establish a simple provenance check for MCP server approvals.**  * Before any MCP server is installed in a development environment, verify: When was the publisher's account created? Does their commit history extend beyond this single repository? Is the original author of a forked project listed as a contributor? Do not rely on stars, forks, or download counts — SmartLoader demonstrated these can be systematically fabricated. **3. Audit your remote-hosted MCP dependencies.**  * For any MCP server that connects to an external endpoint (rather than running locally), identify who operates that endpoint. A server maintained by an individual GitHub account is a materially different risk from one maintained by an established organization with a security program. **4. Ask your development team leads to identify every MCP server currently installed.**  * This does not require a technical scan — a direct conversation is faster and often more informative. Document what you find. Unknown servers are the priority. For the analyst on your team who triages developer environment alerts: the provenance checks above — account age, contributor history, original author presence — are the triage equivalent of checking sender reputation before investigating a phishing alert.  Build them into your MCP server approval workflow the same way you would vet a new open-source dependency. If your team already spends [20 minutes per alert gathering context](https://www.upguard.com/resources/the-context-gap), adding a 5-minute provenance check at installation time prevents hours of investigation later. ## The parallel to npm and PyPI — And why it matters Security teams that have managed open-source dependency risk will recognize this pattern immediately. The npm and PyPI ecosystems have dealt with typosquatting, dependency confusion, and supply chain poisoning for years. The response — tools like Dependabot, npm audit, Snyk, and private package registries — took years to develop and are still imperfect. The MCP ecosystem is at the same inflection point as npm was around 2018: growing rapidly, largely unmoderated, and increasingly targeted by attackers who have recognized the opportunity. The difference is that MCP servers do not just provide libraries — they provide AI agents with the ability to execute actions in your systems. The tooling to match the threat is still catching up. In the meantime, manual verification and policy controls are the primary defense. ## The visibility gap is the core problem The incidents in this post — and the data behind them — point to a single underlying issue: most organizations have no systematic way to know which MCP servers are being used across their developer environments, or whether any of those servers have been impersonated in public registries. That is not a criticism. MCP launched in November 2024, and security tooling for it is still emerging. But the window between the threat materializing and the detection capability existing is precisely where exposure lives, and that window slowly grows wider each day. > *UpGuard Breach Risk's**** Threat Monitoring**** continuously ****scans major MCP registries for brand impersonation and unofficial servers**** targeting your organization. The same registry-layer detection would have surfaced the SmartLoader campaign before a developer installed it.\ > \ *[***See how Threat Monitoring identifies registry threats →***](https://www.upguard.com/tour) *Next in this series: *[*Post 3 — AI GitHub Agents: How One Issue Leaked Private Repos*](https://www.upguard.com/blog/ai-github-agents-issue-leaked-private-repos) eBook A Complete Guide to Attack Surface Management Free resource ### A Complete Guide to Attack Surface Management Monitor and secure your most critical data and assets through Attack Surface Management [Download now](/resources/complete-guide-to-attack-surface-management) ## Related posts Learn more about the latest issues in cybersecurity. Attack Surface Management #### [Find Out if You're Exposed on the Dark Web](/blog/find-out-if-youre-exposed-on-the-dark-web) Answer 5 quick questions to predict what a dark web scan will find about your company. Then run the free scan to see your real exposure. [](/team/lance-turner) [Lance Turner](#) October 14, 2026 Data Breaches #### [Your First Dark Web Scan Report, Explained](/blog/your-first-dark-web-scan-report-explained) You scanned your domain. What do the results mean? [](/team/lance-turner) [Lance Turner](#) October 13, 2026 Data Breaches #### [Good Security Rating? Your Dark Web Exposure Says Otherwise](/blog/good-security-rating-your-dark-web-exposure-says-otherwise) Scan your domain to see just how exposed you are on the Dark Web. [](/team/lance-turner) [Lance Turner](#) October 13, 2026 Attack Surface Management #### [Shadow MCP Servers: The AI Infrastructure You Can't See](/blog/shadow-mcp-servers) In 2012, it was Dropbox. In 2026, it’s Shadow MCP. Discover why unvetted AI agents are an invisible threat and how to regain total visibility. [](/team/shane-moosa) [Shane Moosa](#) August 25, 2026 Attack Surface Management #### [Six MCP Security Incidents Every Security Leader Should Know](/blog/mcp-security-incidents) From registry poisoning to filesystem wipes: discover the 6 MCP security incidents every leader must know to secure their AI agent workflows in 2026. [](/team/shane-moosa) [Shane Moosa](#) July 1, 2026 Attack Surface Management #### [Breach Risk Threat Monitoring: A Path to Clarity in Cyber Noise](/blog/threat-monitoring) Cut through the noise of constant security alerts to proactively identify and mitigate urgent breach risks before they escalate with threat monitoring. [](/team/shane-moosa) [Shane Moosa](#) September 3, 2026 [All posts](/blog) Experience superior visibility and a simpler approach to cyber risk management [Get a demo](/contact-sales) [Free trial](/demo)