MCP CVEs expose third-party server risk in agent workflows

At a glance

What this is: This article says MCP server CVEs mostly reuse familiar software bug classes, but the risk changes because third-party servers execute with agent permissions and can widen impact quickly.

Why it matters: It matters because IAM and security teams now have to treat agent-connected MCP servers as governed dependencies, not just add-on tooling, especially where third parties can inherit privileged access.

Context

MCP server vulnerabilities are ordinary software flaws in an identity-sensitive position: the server accepts input and acts on behalf of an agent, so a bug becomes an access problem as soon as the component is trusted. The core governance issue is not whether the protocol exists, but whether every server that joins the environment has been reviewed as a dependency with its own blast radius.

Third-party MCP servers are where the risk concentrates because they are often installed before they are independently assessed. That pattern turns a convenience layer into a governed access path, which means security teams need to think about inventory, provenance, and trust boundaries together.

Key questions

Q: What breaks when shadow MCP servers are allowed into agent workflows without review?

A: The main failure is that trust moves faster than governance. A server can be installed, connected, and used before anyone checks provenance, scope, or runtime behaviour. That creates a path for credential theft, data exfiltration, or injected commands inside workflows that teams assumed were controlled.

Q: Why do vulnerable MCP clients create more risk than ordinary integration bugs?

A: Because they translate remote input into local execution with the operator's or workstation's authority. That means the vulnerable component is not just a connector, it is an execution bridge that can turn trust into host compromise. The practical risk is loss of containment, since one bad tool path can inherit the privileges of the user running it.

Q: What are the signs that an MCP is becoming a security problem in practice?

A: Common warning signs include requests for permissions that exceed the task, actions that go beyond declared scope, unexpected context structures, and rules that can be influenced by external input. These patterns do not always prove abuse, but they do show that the MCP is operating in a gray zone where closer inspection and tighter controls are needed.

Q: How should teams decide whether to keep using a vulnerable MCP server?

A: Use the same decision logic you would use for any privileged dependency: if the server can inherit meaningful access and cannot be independently verified, the safer choice is to remove or isolate it until the trust gap is closed. The issue is not just patch status, but whether the access path itself is acceptable.

Technical breakdown

Why MCP server CVEs behave like identity exposures

MCP server CVEs often look like conventional application flaws, but the security consequence is different because the server executes in the agent’s trust context. Remote code execution, command injection, path traversal, and authentication bypass all become access amplification points when the server is allowed to mediate tool calls or forward tokens. In other words, the vulnerable code is not just exposed to attackers; it is positioned to inherit the agent’s permissions and data reach. That makes the unit of risk the server-plus-trust relationship, not the vulnerability class alone. See the MCP Security Guide.

Practical implication: Treat every MCP server as an identity-bearing dependency, not a harmless integration component.

Third-party MCP servers create inherited trust chains

The governance problem with third-party MCP servers is inherited trust. A server installed without review can bring in its own dependencies, its own update path, and its own handling of credentials, all of which sit inside the agent’s operational boundary once connected. This is why a known CVE is only one part of the story. Even a clean code scan does not remove the risk of later dependency drift, unreviewed changes, or behaviours that the agent will execute automatically because the server is already trusted. See the NHI Authentication Guide.

Practical implication: Require provenance and dependency review before any external MCP server is allowed to connect.

Why agent-native threats sit beside CVEs, not after them

A CVE list captures disclosed bugs, but MCP deployments also face tool poisoning and indirect prompt injection through server responses. These are agent-native threats because the danger comes from what the agent is persuaded to do, not only from a vulnerable binary. That distinction matters: a server can be free of published flaws and still be unsafe if it returns attacker-controlled content that the agent obeys. For practitioners, the control question is broader than patching and includes what the agent is allowed to consume and execute. Read OWASP Agentic Applications Top 10.

Practical implication: Assess MCP servers for malicious output handling, not just disclosed vulnerabilities.

Threat narrative

Attacker objective: The attacker aims to convert a vulnerable MCP server into a trusted execution path that exposes agent credentials and extends control over downstream actions.

1. Entry begins when a third-party MCP server with an exposed flaw is installed and connected to an agent workflow.
2. Credential access follows when the server is trusted enough to act with the agent’s permissions or forward its tokens.
3. Escalation occurs when unsafe handling of input or authentication allows the attacker to move from a software flaw into broader agent access.
4. Impact lands when the compromised server expands the attacker’s reach into the agent’s credentials, data, or tool actions.

Breaches seen in the wild

• Salesloft OAuth token breach: hackers stole OAuth tokens to access Salesforce data via Salesloft.
• Klue OAuth Supply Chain Breach: OAuth tokens compromised in Klue integration breach affecting 700+ organisations via Salesforce data access chain.

Read and download The State of NHI & AI Agent Breach Report 2026, covering 200+ breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

Third-party MCP servers are not merely integrations, they are delegated access surfaces. Once a server is allowed to mediate agent actions, the security model changes from software assurance to identity governance. That means inventory, provenance, and review discipline matter as much as vulnerability status. The practitioner conclusion is that unaudited MCP servers should be treated as privileged dependencies, not optional plugins.

Published MCP CVEs expose a familiar but mis-scoped control problem. The industry keeps describing these issues as classic software bugs, but the governance failure is that they sit inside an identity pathway. If the server can act with the agent’s permissions, then patching alone does not answer who is trusted to inherit those permissions in the first place. Practitioners need to govern the trust boundary, not just the defect.

Tool poisoning belongs in the same risk conversation as disclosed CVEs. A server that returns attacker-controlled content can be dangerous even when no known vulnerability exists, because the agent may execute what it is given. This is the point where software scanning stops being sufficient and runtime trust evaluation begins. The practitioner conclusion is that agent-connected servers need behavioural scrutiny, not only dependency hygiene.

Identity blast radius is the right named concept for MCP server governance. The moment a server joins the agent workflow, its defect surface and its trust surface merge, and the resulting blast radius is defined by what the agent can already do. That is why third-party review cannot be an afterthought. Practitioners should measure MCP risk by the access the server can inherit, not by the CVE count alone.

From our research library:

• 24,008 unique secrets were exposed in MCP configuration files in 2025 alone, the protocol's first year of widespread adoption, according to the State of Secrets Sprawl 2026.
• Read next: MCP Security Guide

What this signals

Identity blast radius: MCP governance has to move from vulnerability counting to trust-boundary management, because the practical risk comes from what the server can do once the agent accepts it. That means inventory and provenance become access controls in all but name, and every external server should be judged by the permissions it inherits, not the elegance of its code.

Third-party MCP servers will increasingly force practitioners to collapse software security and identity security into one review path. If a server can forward tokens, mediate tool calls, or return executable content, then the control point is selection time, not only patch time. That shifts the programme conversation from reactive remediation to pre-connect approval.

For practitioners

• Audit third-party MCP servers before connection Review each server’s source, dependencies, authentication model, and update path before allowing it into an agent workflow.
• Track published CVEs and dependency drift Re-scan servers whenever dependencies change so a clean install does not become risky after an update.
• Separate trusted from untrusted server outputs Restrict what agent workflows will accept from server responses so attacker-controlled content cannot be executed by default.
• Map server permissions to actual agent need Limit each MCP server to the smallest set of actions and data it genuinely requires, then remove any unnecessary access paths.

Key takeaways

• MCP CVEs are ordinary software flaws only on the surface, because their real effect is to expand access inside the agent trust boundary.
• Third-party servers are the main governance problem when they inherit permissions, dependencies, and update risk without independent review.
• The control that matters most is not patching alone but deciding which servers are allowed to connect, what they may inherit, and what they may return.

Related NHI Mgmt Group resources: MCP Security Guide · OWASP Agentic Applications Top 10 · NHI Authentication Guide · Attack Surface Management Guide

Key terms

• MCP Server: An MCP server is a tool endpoint that connects an AI agent to external systems and data sources through Model Context Protocol. Because it extends what the agent can reach, it becomes part of the identity and access surface and must be reviewed like any other privileged connector.
• Identity Blast Radius: The amount of damage a compromised identity can cause across systems, data, and infrastructure. In NHI environments, it is shaped by permissions, network reach, and administrative capability rather than by the credential alone. Reducing blast radius is a containment strategy that limits lateral movement and data exposure.
• Tool Poisoning: Tool poisoning is an attack in which malicious instructions are hidden inside tool descriptions, examples, or schemas that an AI agent reads when deciding what to do. The danger is not only in the tool's code, but in the metadata that shapes the agent's behaviour and trust decisions.
• Third-Party MCP Server: A third-party MCP server is an external service that exposes tools or data to AI agents through the Model Context Protocol. It creates a controlled integration point, but also extends trust boundaries because the server can access prompts, actions, and connected systems, so identity, authorization, and auditing controls must be tightly managed.

Deepen your knowledge

NHI governance, agentic AI identity, and machine identity lifecycle are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are building or maturing an IAM programme, it is worth exploring.