---
title: "7 Common MCP Security Flaws and Vulnerabilities"
description: "If you're using MCP in your workflows or building MCP servers, be sure to avoid these common MCP security anti-patterns."
canonicalUrl: "https://zuplo.com/blog/2026/06/29/7-common-mcp-security-flaws"
pageType: "blog"
date: "2026-06-29"
authors: "billDoerrfeld"
tags: "MCP, Security, API Best Practices"
image: "https://zuplo.com/og?text=7%20Common%20MCP%20Security%20Flaws%20and%20Vulnerabilities"
---
Model Context Protocol (MCP) is opening up tremendous efficiency and automation
as a standard way to connect AI agents with external data, tools, and APIs. The
protocol has quickly gained substantial adoption, but at the same time, it's
opened up a new attack surface, combining familiar software security problems
with newer AI-native risks that AI and security engineers are just starting to
unravel.

Zuplo's [State of MCP Report](https://zuplo.com/mcp-report), released in early
2026, found that confidence in MCP is high, but security and compliance concerns
were the top issue preventing increased MCP use. On the builder side, security
and access control complexity is similarly the top challenge when developing MCP
servers. The report also found that 58% of MCP builders are wrapping existing
APIs, which means MCP inherits classic API security problems on top of the new
AI-native ones.

Researchers have pointed to
[MCP vulnerabilities](https://thenewstack.io/building-with-mcp-mind-the-security-gaps/)
like prompt injection, tool poisoning, jailbreaks, rug pulls, sensitive data
leakage, and others. Although MCP security awareness is improving, plenty of
implementations still lack the proper access control, credential management,
capability scoping, or monitoring to safeguard MCP usage.

The growth of MCP is cause for concern as the volume of agentic-based actions
[continues to grow](https://leaddev.com/ai/how-to-justify-ai-investments).
Below, we'll look at some of the most common flaws within MCP ecosystems. We'll
cover the risks they cause and offer general mitigations on how AI engineers and
security teams should respond.

## 1. Credential mismanagement

A top flaw in MCP ecosystems is poor key and token practices, which can quietly
undermine security. When Astrix
[analyzed 5,200 open-source MCP server implementations](https://astrix.security/learn/blog/state-of-mcp-server-security-2025/),
it found the credential layer in rough shape.

88% of servers require credentials, but only 8.5% use OAuth. The majority, 53%,
lean on static API keys or personal access tokens (PATs), and 79% of those keys
are passed through plain environment variables.

That matters because
[API keys make poor security tokens](https://nordicapis.com/10-security-issues-with-api-keys/).
They are long-lived, they leak through logs and telemetry, and a stolen one
keeps working until someone notices and rotates it. For this reason, OWASP's
emerging [top ten list for MCP](https://owasp.org/www-project-mcp-top-10/),
currently in beta, ranks token mismanagement and secret exposure (MCP01) as the
number one threat facing MCP ecosystems.

Long-lived credentials might be hardcoded in configurations or leaked into logs,
telemetry, memory, or other areas an agent can later access. OWASP states that
attackers might attempt to retrieve tokens using prompt injection or debugging
traces.

**The risks:**

- Exposure to sensitive data
- Privilege escalation
- Compromise of connected systems

**The mitigations:**

- Avoid hardcoding secrets or leaving them in development environments
- Don't solely rely on API keys for upstream servers
- Abstract MCP access with a layer for proper authentication, token handling,
  and credential rotation

## 2. Overpermissioned access

According to IBM's 2025
[Cost of a Data Breach Report](https://www.ibm.com/reports/data-breach), 97% of
organizations that reported an AI-related security incident lacked proper AI
access controls. Where MCP is concerned, poor identity, access, and permission
boundaries can pose serious threats. Agents often have overpermissioned access
to MCP tools, meaning that they have excessive privileges and scopes, breaking a
least privilege or zero-trust strategy.

MCP ecosystems typically involve many agents, servers, and clients. In this
environment, it's easy for identity and scopes to slip. Sometimes access is
broad or not enforced properly, or at all.

Insufficient authentication and authorization is a recurring pain in the MCP
space. In
[Bloomberry's analysis of 1,400 MCP servers](https://bloomberry.com/blog/we-analyzed-1400-mcp-servers-heres-what-we-learned/),
nearly 40% required no authentication at all, meaning anyone who could reach the
server could enumerate and call its tools.

With poor access control and broad scopes, malicious actors that gain access to
one system can in effect elevate their privilege elsewhere. When agents have
excessive scopes to MCP tools, an attacker could leverage this to perform
unintended actions. Alternatively, a large language model (LLM)-powered agent
with excessive permissions could take unintended wide-ranging actions on its own
accord, behaving as an insider threat.

**The risks:**

- Malicious actors performing unintended actions
- Critical attack paths to connected systems
- Insider LLM-generated risks

**The mitigations:**

- Sharing highly scoped MCP tools internally, with granular permissions by user,
  team, agent, or environment
- Applying just-in-time access and elevating permissions at execution time
- Routing MCP access through an approved compliant gateway

## 3. Shadow servers

Public MCP directories now catalog over 20,000 public MCP servers. And, as
developers begin configuring, using, and even spinning up their own multiple MCP
servers, the likelihood for some to fall outside the purview of accepted,
governed IT tools is quite high. Due to the variance of MCP servers in use
today, some are saying
[MCP sprawl](https://nordicapis.com/mcp-is-making-api-sprawl-worse/) is the new
shadow IT.

Without a proper MCP catalog, you lose the ability to formally inventory which
servers, tools, and services developers and agents are using. This flaw can
manifest as unsafe resource consumption, unrestricted rogue tool use, or
unmanaged access to sensitive systems. Rogue or unmanaged MCP servers can also
pose a threat if vulnerabilities are not tracked and patched over time.

**The risks:**

- Rogue tool use outside of governed IT
- Unpatched vulnerabilities
- Potential for credential leakage or compromise

**The mitigations:**

- Having a centralized registry to visualize what MCP servers are in use
- Generating "approved" versions of MCP servers for developers to use
- Using an MCP gateway to direct, govern, and limit internal MCP tool use
- Requiring approval workflows for adding new MCP servers or tools

## 4. Poor visibility

Another security fault in MCP ecosystems is missing telemetry into how MCP
servers are being used. This includes what tools were called, by what agent,
within what department, at what time, and so on. Beyond tool invocations,
important telemetry includes changes made to context and tools as well.

The aforementioned Bloomberry research put the median server at five tools, with
most clustered in the 1-to-9 range and a long tail running to 19 or more.
Multiply even a modest per-server count by the number of servers wired into a
single environment, and you are quickly managing hundreds of tools. Lacking deep
observability into tool-level use can hinder debugging or auditing flows.

The visibility issue is not isolated to MCP. Really, it's a concern for AI
systems at large. According to Teramind's
[The Shadow AI Behavior Report](https://www.teramind.co/l/shadow-ai-report-2026/),
86% of organizations have no visibility into how data moves to and from AI
tools.

**The risks:**

- Poor auditing trails
- Failure to meet compliance requirements
- Unoptimized use of resources

**The mitigations:**

- Including runtime governance as part of your MCP control plane
- Continually auditing and cataloging the use of MCP servers to ensure
  visibility
- Using observability traces to inform debugging and auditing efforts

## 5. Context poisoning

Another big area of risk for MCP is when an attacker is able to tamper with the
tools, context, or prompts that an agent relies on. One example is tool
poisoning, in which malicious instructions are embedded within MCP tool
descriptions or outputs in order to manipulate model behavior. These poisoned
instructions might be invisible to the user but allow the attacker to steer the
model toward unauthorized actions.

In 2025,
[researchers at Invariant Labs](https://invariantlabs.ai/blog/whatsapp-mcp-exploited)
demonstrated that an attacker could exfiltrate data from a WhatsApp MCP server
in an agentic system by using a malicious MCP server to hijack the agent into
leaking the user's context. The setup leveraged a malicious tool that, in
effect, poisoned the context the agent depended on.

Without any input validation on the prompts, tools, or context an agent has
access to, an adversary could steer an agent away from its original goal and
toward the attacker's intent, a manipulation OWASP's agentic threat taxonomy
calls "intent breaking and goal manipulation." Context injection could also
pollute shared memory, sessions, or other context that the agent relies upon.

**The risks:**

- Manipulation of agents
- Disruption of user intent
- Nuanced targeted attacks
- Incorrect or falsified information

**The mitigations:**

- Validate, filter, and constrain untrusted context before it reaches agentic
  systems
- Runtime monitoring to continually parse and detect malicious abuse
- Generating highly scoped MCP servers that in effect limit tool accessibility
- High-grade access controls on context storage and access to prevent tampering

## 6. Unsafe tool execution

Command injection and execution can arise when an MCP server or agent uses
untrusted input to run shell commands, scripts, API calls, or queries without
proper validation or sanitization. In severe cases, this can lead to remote code
execution (RCE), one of the worst cybersecurity vulnerabilities due to the
damage that can be caused with direct system access.

As the NSA says in its
[guidance on MCP security](https://www.nsa.gov/Portals/75/documents/Cybersecurity/CSI_MCP_SECURITY.pdf?ver=bmgiSbNQLP6Z_GiWtRt6bg%3D%3D),
"MCP's rapid proliferation has outpaced the development of its security model."
Its flexible design has allowed innovation but at the cost of introducing
ambiguity on how to use it safely. For instance, the agency specifically
highlights arbitrary code execution (ACE) as a top pressing concern.

Independent researchers have discovered RCE vulnerabilities present within many
MCP server environments. For instance,
[2025 research from Equixly](https://equixly.com/blog/2025/03/29/mcp-server-new-security-nightmare/)
found that 43% of MCP servers have command injection vulnerabilities. While RCE
vulnerabilities are not as common as when MCP was first introduced, they're
still a pressing threat.

**The risks:**

- Remote code execution style attacks
- Completely compromised systems
- Data exfiltration
- Role elevation

**The mitigations:**

- Diligent validation and sanitization of all input
- Governance into all context and data fed into agentic systems

## 7. Supply chain risks

MCP servers are now distributed and installed at the scale of a mature package
ecosystem. [PulseMCP's tracking](https://www.pulsemcp.com/statistics) shows
local servers pulled tens of millions of times in a single recent month, the
kind of volume that makes registries an attractive target. Most of those
installs arrive with no vetting at all. As such, this introduces classic supply
chain issues, like typosquatting, in which developers accidentally download
malicious code from package managers.

OWASP includes software supply chain attacks on its in-progress list of MCP
threats. As OWASP describes, a software supply chain style attack in an MCP
ecosystem could alter an agent's behavior, or introduce execution-level
backdoors. An untrusted MCP server could also change after approval, exposing
new tools or altering tool descriptions, which could compromise a system.

**The risks:**

- Altered agentic behavior
- The creation of backdoors and rug pulls
- Unsafe or unapproved tool execution

**The mitigations:**

- Careful analysis of new downloads within MCP ecosystems
- Centralized tooling catalogs with approval workflows for new MCP servers
- Code scanning and validation to spot malicious injection

## How an MCP Gateway Closes These Gaps

MCP is here to stay. And with it comes a mix of familiar security problems and
novel AI-native threats. As such, cybersecurity needs a response that is up for
the task. Thankfully, many risks are being minimized by emerging strategies as
well as new platforms to reduce the risk of enterprise MCP adoption.

For example, Zuplo's aforementioned MCP report found that companies are most
commonly using a gateway when hosting their MCP servers. Just as it's common
practice to abstract APIs with a gateway layer for safe access, it's becoming
standard practice to use an
[MCP gateway](https://zuplo.com/blog/mcp-gateway-comparison) to secure access to
underlying MCP servers.

By using an
[enterprise-grade MCP gateway](https://zuplo.com/blog/why-enterprises-need-an-mcp-gateway),
users can quickly mitigate many of the risks above, especially around secrets,
authentication, authorization, monitoring, and tooling governance, that
naturally arise when scaling MCP in practice. As such, it's worth considering
how an MCP gateway can untangle the MCP sprawl you might find yourself in.