Stars Don’t Save You: Popularity Is Not Security in the MCP Ecosystem

Introduction

Model Context Protocol (MCP) has emerged as the dominant standard for bridging the gap between large language models (LLMs) and the silos of local and remote data. By providing a unified interface, MCP enables AI applications to evolve into active “agentic workflows” capable of executing code, querying databases, and managing cloud infrastructure. This rapid surge in adoption has turned MCP directories into a critical foundation of the emerging AI economy.

However, the speed of this evolution has significantly outpaced the implementation of traditional security safeguards. In our previous work, Hunt Them All: Identifying MCP Vulnerabilities Using AI, we ran an automated security analysis of open-source MCP servers using a multistage approach paired with randomized manual verification. This analysis revealed the concerning reality of how vulnerable publicly available MCP servers are in practice.

Identifying security issues, however, is just part of the equation. To obtain a more comprehensive view of the impact these issues might have on the AI ecosystem, it is important to weigh them against measures of popularity, development activity, and effective adoption. This is the goal of our follow-up work.

A common assumption is that relying on popular application directories and known, active providers reduces the chance of encountering vulnerable applications. But this is not always the case. Our research challenges this assumption, showing how the distribution of MCP security issues does not necessarily correlate with popular software authors or servers that should have been verified by the providers. We also provide examples showing the major impact of these vulnerabilities on the AI software ecosystem and its business.

Dataset exploration and breakdown of security issues

Between November 2025 and March 2026, we crawled four popular MCP directories—GitHub, Glama, Lobehub, and PulseMCP—and extracted all the relevant metadata, such as popularity, authors, number of commits, and languages. We then correlated the directory entries with the security issues that we discovered in our previous work.

Overall, we identified 9,695 unique MCP servers with available directory metadata, as shown in Table 1. Nearly all appear on GitHub and may also appear in one or more of the other directories, so the per-directory counts overlap and are not additive.

From each directory, we extracted all metadata pertaining to the MCP server, its description, comments left by users, stars and activity reports, and any other directory-specific information.

Out of the 9,695 servers, our security audit identified 5,832 servers that showed security issues. As we have noted previously, we did not include 3,573 servers that were marked as unsecured solely because of a lack of authentication. While a lack of authentication is still considered an aggravating factor when paired with other security issues, we did not consider it alarming enough to flag an MCP server on its own. That left us with 2,259 servers with confirmed security issues.

From the retained servers that showed security issues other than a simple lack of authentication, we identified 4,982 issues, as shown in Table 2.

Each of the issues was placed in one of three risk categories:

• Vulnerability: Security issues involuntarily introduced by the developer that could lead to exploitation
• Vulnerable by design: Design issues that constitute potentially harmful behavior for the server; code injection consists of code executed locally via a user input request per the developer’s specification
• Malicious behavior: Behaviors that could harm client and related agentic systems, such as prompt injections

Putting common assumptions to the test

Security issue profile by popularity

We analyzed whether a server’s popularity could somehow serve as a reliable indicator of security issues, as shown in Figure 1.

Grouping servers affected by security issues by GitHub star count reveals how their severity and issue mix vary across the adoption spectrum:

• High-popularity servers (50 or more stars) have the largest individual blast radius per server. They are potentially installed by most users, which means each security issue reaches the widest audience. Their set of issues leans toward the classes that are most relevant for popular, feature-rich tools: SSRF (embedded URL fetching), arbitrary file access (document- or file-manipulation tools), and prompt injection (LLM-facing interfaces).
• Medium-tier servers (10 to 49 stars) represent the bulk of the ecosystem by server count. Their aggregate scores dominate simply through volume. Issue diversity tends to be highest here—this is the “long tail” of MCP development, where a wide range of use cases and security practices coexist.
• Low-popularity servers (1 to 9 stars) might reflect tools that are experimental or for personal use. Despite low reach, they can carry severe, individual security issues (for example, command injection, arbitrary code execution) because they receive less community scrutiny. The average number of security issues per server in this tier warrants attention. A higher-than-expected average indicates that low-visibility servers are not inherently safer, just less visible.
• No-star servers are the least adopted but might include servers early in their lifecycle or deployed in private. Security issues here carry the lowest impact on the ecosystem but have the highest individual uncertainty (for example, no community reviews, no star signals, and no public validation of the code).

If we average the number of security issues by the number of servers per tier (Figure 1), we see that the value does not change significantly. This suggests that there is little correlation between an MCP server’s popularity and its inherent safety. 

Security issue profile by repository activity

We next challenged another assumption: that servers subject to more development activity might be more secure.

The total number of commits captures the cumulative development efforts and ongoing maintenance. Unlike star count (which measures popularity), commit count measures how much code has been written and changed. A higher commit count means more code surface, more refactoring, and potentially more introduced security issues, but also more opportunity to fix them:

• Very active servers (100 or more commits) are repositories with the largest codebases and the most accumulated changes. A high issue count here might reflect genuine complexity—that is, more code paths, more integrations, and more edge cases—rather than negligence.
• Active servers (50 to 99 commits) and moderate servers (10 to 49 commits) represent the mainstream of MCP development. They are projects that are past their proof of concept but are not at production maturity. This is typically where vulnerabilities introduced during rapid feature development have not yet been reviewed or addressed.
• Low-activity servers (1 to 9 commits) are the smallest and the least evolved codebases.
• No-commit servers (0) are repositories that have no recorded commit history and are likely mirrors, forks with no new commits, or improperly indexed repositories. Their issue profile reflects the source they were forked from rather than any original development activity.

As in the previous case, averaging the number of security issues per server (Figure 2) shows little to no correlation across actively developed tiers. The exception is no-commit servers, which show the highest average—but this reflects their nature as mirrors and forks, whose issues are inherited from the upstream source rather than introduced through their own development. Even more actively developed MCP servers are affected by security issues nonetheless.

Verified vs. unverified servers

Another common assumption is that verification status reliably indicates safe software packages. MCP directories verify the trustworthiness of their advertised servers in different ways. These include inspecting code for vulnerabilities through the MCP Inspector, tracking social proof (stars, visitors, and recency), and confirming ownership and vetting servers. While these strategies have been successful, particularly for mobile applications in app marketplaces, they do not yet appear to be equally effective in the MCP ecosystem.

In Figure 3, we compared the average number of security issues for verified and unverified sources.

Yet again, we observed no significant difference in the average number of issues per server between verified and unverified repositories.

The devil is in the details

After challenging the most common assumptions about security and software adoption, we now turn to some more notable aspects of the MCP directories. For ethical and legal reasons, we have anonymized the data, since our goal is not to single out any specific developer, but to capture the overall nature of the ecosystem.

Ecosystem impact

By correlating GitHub’s stars as a popularity indicator with the number of security issues as a severity metric, we obtain a severity-weighted reach metric. For example, a server with 80,000 stars and a moderate number of issues produces a large impact and footprint because of its wide adoption.

In Figure 4, the x-axis shows the long-tail distribution of star counts. Servers in the upper right quadrant (high stars and high number of issues) represent the highest strategic risk to the AI ecosystem. They are simultaneously the most widely installed and the most affected by security issues. These are the servers where a public disclosure would have the greatest immediate effect.

The bubble size in Figure 4 represents the number of exposed MCP tools—a further measure of each server’s attack surface. The more tools a server exposes, the greater the potential for each security issue to be exploited.

Security issue co-occurrence

Another notable pattern is the co-occurrence of security issues we observed across affected MCP servers, which we ranked by prevalence. Each server is assigned its full set of detected issues (deduplicated across scans), and the exact combination is treated as a single fingerprint.

The horizontal bar chart in Figure 5 shows the top 10 most common combinations of issues by the number of affected servers.

Single-issue servers and multi-issue combinations are compared side by side, revealing whether most security issues are isolated findings or tend to cluster in predictable bundles.

Software author risk profiles

By correlating the security issue reports with the author metadata from the directories, we evaluated whether any software authors stood out in terms of the number or severity of security issues.

Figure 6 shows the top 20 software providers by the number of affected servers, broken down by the security issue category. Collapsing issue types into three high-level categories—vulnerability, vulnerable by design, and malicious behavior—clarifies the nature of each provider's risk profile.

The overwhelming majority of risk is categorized as vulnerability—that is, exploitable flaws rather than configuration weaknesses. Vulnerable by design (no authentication and code injection) is significant but secondary, typically appearing as a compounding factor alongside true vulnerability. Malicious behavior (prompt injection) remains a niche but growing concern, especially for providers whose servers expose natural language query interfaces. The relative uniformity of the category mix across providers suggests systemic rather than isolated weaknesses. The underlying issue is the industrywide lack of input validation in MCP tool parameters, not provider-specific negligence.

Use cases

Examining our findings more closely, we identified several use cases that warrant deeper analysis. Given the rate at which the AI ecosystem tends to evolve, these examples should serve as cautionary illustrations rather than actionable intelligence.

Provider_1

This author has released numerous MCP servers, all in the domain of cryptocurrency trading and decentralized finance (DeFi). This is a critical domain dealing with users’ monetary assets, which makes the number of security issues found in the code even more worrisome.

For example, a server-side template injection was identified in an MCP server tasked with fetching trading news. Maliciously crafted news content could have opened it to full server-side code execution. Furthermore, a prompt injection was found in an MCP server tasked with analyzing trades, which could have directly modified the behavior of an agent using that MCP server.

The combination of financial system access, absent authentication, and multiple code execution paths across a large server fleet makes this provider one of the highest-risk sources of MCP servers. A single compromised Claude desktop app session with tools loaded could result in unauthorized blockchain transactions, credential theft, or full server compromise.

Provider_5

This author developed several popular MCP servers, some with up to 1,000 stars on GitHub, with little to no oversight of security features. We found code injection flaws in a server with more than 100 stars, where MCP tools directly called eval(), allowing direct Python code execution. We also found path traversal in an office-related MCP server.

Provider_3

Provider_3 presents a unique enterprise risk profile. These servers are designed for production integration into corporate financial, human resources, and identity systems. Despite that, we identified SQL injections in several MCP servers. A SQL injection in an MCP tool exposed to an AI agent could be triggered by a carefully crafted natural language query, bypassing any assumed layer of LLM sanitization.

Furthermore, we identified unauthenticated access to Active Directory (AD) queries, which means that an LLM agent could enumerate AD objects and attributes without access control at the MCP layer. A malicious actor could exploit this for reconnaissance and privilege escalation.

Conclusions

The rapid expansion of the MCP ecosystem presents both opportunity and risk for the future of agentic AI. While it provides the essential infrastructure for LLMs to evolve into agentic systems, our findings challenge the assumption that everyday metrics, such as popularity or repository activity, are proxies for security. These signals—GitHub stars, active commit histories, and verification badges—do not currently offer a reliable guarantee against critical vulnerabilities.

Our analysis highlights a significant supply chain risk inherent in the way developers currently source MCP servers. Because many of these tools are designed to facilitate low-level system access (such as terminal execution, file system manipulation, and database querying), they are “privileged” by nature.

Integrating a third-party MCP server without a code audit carries significant risk. Users must recognize two primary threats:

• Vulnerable repositories—well-intentioned but poorly secured code that serves as an entry point for external attackers (for example, via SSRF or SQL injection)
• Malicious repositories—servers specifically crafted to exfiltrate credentials, drain cryptocurrency wallets, or conduct reconnaissance on internal networks once connected to an agent

As the ecosystem matures, developers must move away from a “trust-by-default” mindset and adopt a “trust-but-verify” posture, treating every internet-sourced MCP server as unvetted third-party code.

Static code analysis is essential, but it is not an all-in-one solution. To navigate this landscape, the AI industry requires real-time security solutions capable of the following:

• Traffic inspection—monitoring the communication between the AI agent and the MCP server to detect anomalous payloads
• Issue prevention—automatically intercepting and blocking malicious inputs, such as prompt injections or command sequences, before they reach the execution layer
• Behavioral baselining—identifying when an MCP server deviates from its intended function, such as a “weather tool” suddenly attempting to access /etc/passwd

TrendAI™ is at the forefront of this defensive shift, providing specialized solutions designed to protect AI application deployments. By implementing a protective layer that scans traffic in real time, TrendAI™ helps organizations mitigate vulnerabilities and neutralize supply chain threats. This keeps the move toward agentic workflows both productive and secure.

MCP continues to bridge the gap between thought and action in AI. Ultimately, the responsibility for security must be shared between the developers writing the code and the sophisticated security systems monitoring its execution.

About the authors

The Forward-Looking Threat Research Team of TrendAI™ Research specializes in scouting technology one to three years in the future, with a focus on three distinct aspects: technology evolution, its social impacts, and criminal applications. The team has been monitoring AI and its potential misuses since 2020. That year, in collaboration with Europol and the United Nations Interregional Crime and Justice Research Institute (UNICRI), it authored a research paper on the topic.