Model Context Protocol (MCP) servers came into existence only a few months ago (introduced as an open source standard by Anthropic), but like everything else AI-related, they’ve been exploding. There are already several websites serving as directories or catalogs of MCPs, listing 10,000s of them. With the recent announcement by OpenAI that they too will open up to the MCP standard, we can expect even more MCPs.
You don’t have to be a security expert to understand that when something is suddenly available so quickly and in such large quantities, can easily be used to augment your use of AI services, can interact with your applications or infrastructure, or embed itself into your software development process – it could introduce new security risks, or even be abused by malicious actors to insert themselves into your systems for nefarious purposes.
We’ve already highlighted some of the risks of Vibe Coding and what it means for AppSec. In this blog we’ll focus on the risks of using MCP servers in your software development environment, especially IDEs (integrated development environments) used by developers. But first, let’s understand what MCP servers are, and what benefits they might bring to software developers (feel free to skip ahead if you already know.)
What is an MCP Server?
MCP servers enable contextual, persistent memory and state management across AI models and agents. They store and serve contextual information, typically structured as documents, memory vectors, or state snapshots, to improve reasoning, coding, and collaboration workflows—especially in long-running or complex development sessions. Typically, they extend the default interface of LLMs to connect them to other systems, making them usable in a variety of situations that go beyond step-by-step human prompts and chat-style interactions.
Use-cases of MCP servers in vibe coding and IDEs
When we look at how MCP servers can enhance the developer experience and improve coding practices, we see them act as intermediaries between LLMs and AI-agents on the one hand and the IDE on the other hand.
Key use-cases include:
- Persistent AI Coding Sessions: Your IDE integrates with an AI assistant that stores your work history, task structure, and documentation in MCP. When you return after a break, the assistant "remembers" the project state, open bugs, and coding style.
- Multi-Doc Contextualization: You're building a feature that spans multiple services. MCP stores a semantic index of your microservice architecture docs, schemas, and config files. You ask your assistant, "Where does the user session get verified?" and it pulls the relevant file instantly from MCP.
- Agent-Based Debugging: You run an autonomous coding agent that uses MCP as its short- and long-term memory. It tracks function definitions, unresolved errors, and commits across a dev session. You can inspect its "memory trace" via the MCP dashboard or in the IDE.
- Fine-Grained Prompt Engineering: Prompt templates in your IDE that reference specific MCP contexts, standards or use-cases.
So MCPs can really change the software development process, and the ecosystem of tools that a developer uses. This holds true in any IDE, but in vibe coding environments such as Cursor, Windsurf and Zed, you can expect MCPs to be used even more liberally.
While the convenience and functionality of these servers are undeniable, their integration also opens the door to a host of security risks - let’s see what those are.
Key Risks Associated with MCP Servers in IDEs
Understanding how these risks materialize is essential for safeguarding development environments. Below are some of the most concerning threats posed by vulnerable, poorly configured, or malicious MCP servers:
-
Prompt Manipulation:
MCP-integrated AI systems might be vulnerable to prompt injection, where maliciously crafted input causes the LLM agent to perform unintended actions. Attackers can embed hidden instructions in code comments, documents, or other context data so that when the AI reads them, it overrides its legitimate instructions. This “context poisoning” can lead to the AI executing commands or divulging information that it shouldn’t, or creating deliberately malicious or vulnerable code in the application that would later serve as an entry point for the attacker.
-
Sensitive Data Leakage and Exfiltration:
Compromised MCP servers may log requests, capturing sensitive queries, documents, or conversation history. They could use this information to infer identities, business logic, or trade secrets. Misconfigured or untrusted MCP servers can also exfiltrate files or records without the user realizing. For example, a malicious document or chat message in a connected system (e.g. Slack or Drive) could trick an AI agent into retrieving and transmitting internal files to an attacker’s server. In enterprise settings, this risk is amplified by the sensitivity of data (source code, customer info, credentials) that developers handle.
-
Authentication and Access Control Gaps:
Authentication and authorization weaknesses in MCP deployments present a serious risk. The MCP standard is still evolving its security model – currently, many MCP servers lack strong authentication by default. This means an MCP server (especially if mistakenly listening on a network port) could accept requests from any client, potentially allowing unauthorized access to your IDE or other connect software development tools. Moreover, lack of user identity propagation means MCP servers might connect to backend systems (code repos, issue trackers, databases) with shared credentials, not the individual user’s privileges. Without careful design, an AI agent could fetch data that a given developer shouldn’t have rights to see, simply because the MCP server was configured with an overly broad access token.
-
Excessive Privileges and Permission Misuse
MCP servers often run with broad privileges, and if not properly constrained, they can perform powerful actions that may be abused. In local deployments, the MCP server inherits the user’s permissions – meaning it can read/write files, access internal networks, or even execute code with the same rights as the developer. This creates a wide blast radius if the AI agent is tricked into doing something nefarious. A key governance concern is how user consent and tool permissions are handled in IDE integrations. Some clients (e.g. Claude or VS Code extensions) prompt the user the first time a tool is used, but if the user selects “Allow all” or if the client reuses the initial grant, the AI can continue performing actions without further user oversight.
-
Infinite Call Loops and Resource Exhaustion:
A malicious or badly configured MCP server might trigger recursive calls or expensive queries, leading to denial-of-service attacks or exhausting system resources.
-
Trust Misplacement in Tool Reasoning:
By returning plausible yet incorrect results, MCP servers can either deliberately subtly distort decision-making processes, or overly rely on poorly prompted LLMs, leading to erroneous outcomes or failed operations, or simply bad quality of code.
-
Exploiting Plugin Actions:
When integrated with tools like file systems or databases, MCP servers might trigger unsafe plugin actions or cross-plugin injections, causing significant damage. For example, in a development context, an MCP might exploit Jira integration to open false tickets for bugs that don’t exist, or ones that encourage support engineers to input credentials for stealing.
-
Direct Injection of Malicious Rules:
A compromised MCP server can install harmful project rules, code, or logic within the IDE. These rules might corrupt workflows, compromise sensitive data, or disrupt essential functions in ways that are difficult to identify and trace.
-
Supply Chain and Third-Party Dependency Risks:
MCP servers and clients often rely on open-source packages, community-developed connectors, or third-party services – introducing supply chain vulnerabilities. Using an unverified MCP implementation is akin to installing any other dependency from the internet, but with access to your code and IDE. A compromised or trojanized MCP package could inject malicious code into the development environment, since MCP servers run with substantial privileges. An attacker might publish an MCP server that claims to integrate with a popular tool (like Jira or GitHub) but actually contains backdoors or data-harvesting code. Even without overt malware, poorly maintained dependencies pose risks: an outdated library in an MCP server could have known exploits (like an old YAML parser leading to RCE). There’s also the risk of dependency confusion – if an internal MCP tool has the same name as a public package, a build or update system might pull the wrong one. Unofficial implementations are especially risky if they don’t undergo security review (many are new and have “minimal security review” to date).
-
Malicious or Compromised MCP Servers (Tool Poisoning):
Attackers can use methods like typo-squatting to fool users into using them instead of official ones from known vendors. Tool poisoning attacks use a malicious MCP server to seem legitimate to the client but embed hidden malicious instructions in the tool descriptions. The AI model “sees” those hidden directives and can be manipulated into actions like reading sensitive files or sending data to an attacker, all while the user only sees a benign tool name/description. Teams must therefore be extremely cautious about which MCP servers they integrate: prefer official or vetted servers, verify the source code if open-source, and consider running them in a restricted environment.
Mitigating Risks: A Call for Vigilance
While malicious MCP servers are not common at least amongst the most popular MCP servers, their potential to exploit vulnerabilities should not be underestimated. Judging from previous trends, there’s little doubt that malicious actors are not ignoring this opportunity. Developers and organizations can take proactive steps to minimize the risk:
· Implement Rigorous Tool Verification: Ensure that all tools integrated into MCP servers undergo thorough vetting and adhere to secure coding standards.
· Monitor and Audit MCP Activity: Regularly review logs and interactions to detect anomalies or suspicious behavior.
· Apply Namespace Enforcement: Treat rules in MCPs as executable logic: review, validate, and control their usage as you would with code, ensuring they can’t be misused or produce unintended behavior.
Conclusion
The dynamic and interconnected nature of MCP servers in IDE environments offers unparalleled advantages but also exposes systems to potential vulnerabilities. By understanding the risks and implementing best practices, developers can protect their workflows and ensure the integrity of their environments. Although malicious MCP servers are uncommon, security vulnerabilities in legitimate MCP servers can present significant risks. Maintaining vigilance and employing proactive strategies are essential for mitigating these threats.
To learn more about MCP and vibe coding risks - download our whitepaper