SixHack Academy Offensive learning
ES Español ✓ EN English ✓
Enter
MCP Security: The New Weak Link in AI Agents
October 07, 2026

MCP Security: The New Weak Link in AI Agents

What the Model Context Protocol (MCP) is and why it became a new attack surface in 2026: tool poisoning, command injection, the year's CVEs and how to audit an MCP server.

During the early years of generative AI, much of the security conversation focused on what happened inside the model itself: incorrect responses, information leakage, jailbreaks, or prompt injection.

Agents have changed that boundary. A model no longer has to be limited to producing text. It can query databases, read repositories, analyze documents, access APIs, create tickets, interact with cloud services, or execute tools capable of modifying real systems.

One of the technologies that has accelerated this transition the most is Model Context Protocol (MCP). Anthropic introduced MCP in November 2024 as an open standard for connecting AI applications to tools and data sources. The idea was simple: provide a common interface so that every application would not need a different integration for every service.

The common comparison is a “USB-C for AI applications”. And that is exactly where the security problem appears: the easier it becomes to connect an agent to new capabilities, the more important it becomes to control what gets connected, with which permissions, what information reaches the model, and which actions it can perform.

Adoption has been extraordinarily fast. By December 2025, Anthropic was already referring to more than 10,000 active public MCP servers and adoption across products such as ChatGPT, Cursor, Gemini, Microsoft Copilot, and Visual Studio Code. In July 2026, the protocol maintainers stated that its Tier 1 SDKs were collectively approaching 500 million monthly downloads.

That adoption has also introduced a new attack surface: tool poisoning, indirect prompt injection, manipulated MCP configurations, unauthenticated servers, SSRF, OAuth token theft, excessively privileged tools, and supply-chain issues.

Note: this article focuses on defensive analysis and authorized security assessments. The examples explain threat models and trust boundaries without providing exploitation chains against third-party systems.

In this guide

What MCP is and what really changes

Model Context Protocol is an open protocol that standardizes how an artificial intelligence application can connect to external tools, resources, and systems.

Without MCP, an application that wanted to work with GitHub, a database, a filesystem, and an internal API would normally have to integrate each service independently. MCP introduces a common interface between the AI application and those systems.

An MCP server can expose different capabilities. Among the most important are tools, which allow actions to be performed, and resources, which provide information or context.

The difference compared with a traditional integration is not that application logic disappears, but that the model can now participate in deciding which tool to use, when to use it, and with which parameters.

In a classic application, a developer explicitly defines what happens when a user clicks a button. In an agentic system, the user can express an intention in natural language, the model interprets that intention, selects a tool, and constructs the parameters sent to the server.

This introduces another decision-making layer between user input and the final action.

MCP does not automatically make a tool secure. The protocol standardizes how it is described, discovered, and invoked, but authorization, input validation, and the limits of each action remain the responsibility of the applications and servers implementing it.

The architecture and its trust boundaries

MCP conceptually separates three main components: the host, which is the application where the user or agent experience lives; the MCP client, which maintains communication with the server; and the MCP server, which exposes tools, resources, or other capabilities.

From a security perspective, however, that representation is incomplete. Behind the server there may be an operating system, a database, a corporate API, a SaaS provider, cloud infrastructure, or credentials with significant privileges.

A security assessment therefore needs to reconstruct the entire chain of trust. It should identify who controls the information reaching the model, who can modify tool descriptions, who can register new MCP servers, which identity each component runs under, which credentials it receives, and which systems it can reach.

It also matters which actions can be performed without user intervention. A tool that only retrieves public information has a very different threat model from one capable of deploying code, modifying infrastructure, or deleting resources.

MCP security cannot be assessed by looking at the protocol alone. The complete architecture and the identities crossing each component need to be analyzed.

The new attack surface

OWASP currently maintains a project dedicated specifically to the main risks around MCP. These include tool poisoning, command injection, contextual prompt injection, insecure token management, excessive permissions, insufficient authentication, and MCP servers used outside organizational control.

Many of these vulnerabilities are not new by themselves. Command injection, SSRF, poorly implemented OAuth, and excessive privileges have been part of traditional security assessments for years.

What changes with agents is the position these vulnerabilities occupy within the architecture.

Attacker-controlled input may reach the model. The model may use it as context when making a decision. That decision may select a privileged tool and ultimately reach an API, filesystem, shell, or internal service.

The attack surface is therefore no longer limited to the endpoint. It also exists in the way the agent interprets information and decides which capability to use.

This gives traditional security questions a new dimension: we should not only ask whether a parameter reaches a shell, but also whether untrusted content can convince the model to invoke the tool that reaches that shell.

Tool poisoning: when the tool itself becomes an input

To choose a tool, the model needs to understand what that tool does. This information usually includes its name, description, and parameter schema.

A tool description is therefore not simply documentation intended for a developer. It may become part of the context the model uses for reasoning.

If that description comes from an untrusted source, an attacker can attempt to introduce instructions designed to alter the agent's behavior. The model may interpret information that appears to describe a tool as additional instructions about how it should behave.

OWASP includes this category as MCP03: Tool Poisoning.

The problem can become even more subtle when tools change after they have already been approved. A user may initially authorize a server exposing an apparently harmless tool. If its description later changes and the client automatically retrieves the new version, the trust originally granted may be extended to content that was never reviewed.

Names, descriptions, metadata, and outputs should therefore be treated as untrusted inputs. Installing an MCP server should not imply that any text produced by that server automatically becomes trusted instructions for the model.

Tool poisoning appears when information about a tool is mixed with instructions that the model interprets as part of its objective. Defense begins by clearly separating data, metadata, and trusted instructions.

Indirect prompt injection through MCP

An MCP server does not even need to be malicious to introduce a prompt injection.

Imagine an agent connected to GitHub through MCP. The user asks it to summarize the open issues in a project and the server retrieves several issues. One of them was created by an external user and contains instructions directed at the model.

When that issue enters the model context, the agent may find itself processing both the legitimate user request and the instructions introduced by the attacker.

The same pattern can appear when reading emails, documents, web pages, pull request comments, support tickets, database records, logs, or outputs generated by other tools.

This is the essence of indirect prompt injection: the attacker does not need to communicate directly with the model. It is enough to control a source of information that the agent will later consume.

The impact then depends on the tools available to the agent. An agent that can only summarize text has limited exposure. One that can also send information externally, modify repositories, or perform administrative operations can turn the same injection into a much more serious problem.

This is why it is not reasonable to rely solely on the model correctly distinguishing between “content to analyze” and “instructions to follow”. That separation needs to be reinforced by the architecture.

STDIO and command execution: what is a vulnerability and what is not

One of the areas that has caused the most confusion around MCP security is the operation of local servers through STDIO.

In this model, the MCP client starts a local process and communicates with it through standard input and output. The configuration specifies which program should be executed and which arguments it requires.

The client executing that configured command is therefore not, by itself, a vulnerability. That is precisely the expected behavior of this type of server.

The MCP project explicitly states this in its security policy: executing the configured command to start a STDIO server is part of the design.

The real security boundary lies in who can control that configuration.

If only trusted local configuration can define the program and its arguments, the system is executing what the user or administrator chose to install. But if a GitHub issue, a project file, a web page, or another untrusted input can modify that configuration, server registration can become a path toward code execution.

OX Security research

In April 2026, OX Security published research focused precisely on this boundary. According to its findings, the work resulted in more than 30 disclosures and more than 10 CVEs in products where untrusted inputs could reach STDIO server configuration or its parameters.

OX described the issue as a systemic risk in the MCP ecosystem and estimated exposure associated with more than 150 million SDK downloads and up to 200,000 servers.

The MCP project maintains a stricter interpretation: executing the configured server is expected behavior, and the vulnerability exists in the application that allows this configuration to be controlled without appropriate safeguards.

STDIO executing the configured server is not the bug. The problem appears when untrusted content can modify the command, alter its arguments, register servers without appropriate confirmation, or manipulate configuration that ultimately becomes execution.

This distinction is important because it completely changes how the functionality should be audited.

OAuth, tokens, and remote MCP servers

When the MCP server is remote, the attack surface begins to look much more like that of a modern API.

Familiar problems appear around authentication, authorization, scopes, secret management, SSRF, and OAuth. A server may require identity, act on behalf of a user, and need tokens to access other resources.

This introduces questions very similar to those asked during any OAuth assessment: which Authorization Server is being used, which resource each token was issued for, which scopes it receives, where it is stored, and which component can access it.

LibreChat provides several real examples published during 2026.

One vulnerability affected validation of the OAuth resource parameter. The implementation did not correctly verify that the discovered resource matched the configured MCP server. Under certain conditions, a malicious server could attempt to receive tokens intended for another resource.

Another vulnerability allowed configurable MCP server headers to interact with placeholder substitution mechanisms containing OAuth credentials. The result could expose the token to an attacker-controlled server.

SSRF issues also appeared in the way LibreChat validated destinations reachable through certain MCP-related functionality.

The conclusion is important: MCP does not replace OAuth or eliminate its risks. In many architectures, it combines them with an additional agentic layer.

Real MCP-related CVEs

Counting vulnerabilities is not a good way to measure protocol security on its own. It is much more useful to examine the types of issues that are appearing in real products.

CVE Product Issue
CVE-2025-49596 MCP Inspector Missing authentication between Inspector and its proxy could lead to command execution through STDIO servers. CVSS 4.0: 9.4.
CVE-2025-59536 Claude Code An untrusted project could trigger execution before the user correctly completed the trust confirmation dialog. CVSS 4.0: 8.7.
CVE-2026-22252 LibreChat MCP STDIO configuration accepted arbitrary commands and could allow execution as root inside the container. CVSS 3.1: 9.1.
CVE-2026-30615 Windsurf Attacker-controlled content delivered through prompt injection could modify MCP configuration and automatically register a malicious STDIO server.
CVE-2026-31945 LibreChat SSRF in functionality related to Actions and MCP due to insufficient validation after DNS resolution.
CVE-2026-31951 LibreChat Attacker-controlled headers in MCP configurations could expose OAuth tokens through credential placeholders.
CVE-2026-33032 nginx-ui An MCP endpoint failed to correctly enforce authentication and allowed administrative tools capable of modifying configuration and restarting NGINX to be invoked.
CVE-2026-54030 LibreChat Insufficient validation of the OAuth resource parameter could allow a malicious MCP server to receive tokens intended for a legitimate server.

The identifiers matter less than the pattern they reveal. Authentication failures, configuration control, OAuth, secret management, SSRF, prompt injection, and process execution all appear within the same architectural space.

MCP did not invent all of these vulnerabilities. What it has done is move them closer to a layer where a model may participate in the decision that eventually reaches them.

What changed in MCP during 2026

MCP is not a static protocol. The revision published on July 28, 2026 introduced the largest set of changes since its original release.

New features included a stateless protocol core for remote servers, routing through headers such as Mcp-Method and Mcp-Name, changes to multi-round interactions, a formal extension framework, and a deprecation policy.

There were also significant changes around authorization.

The specification incorporated validation related to the iss parameter following RFC 9207 to reduce mix-up attacks, established a clearer relationship between client credentials and the issuer that created them, and introduced additional clarification around scopes and authorization processes.

The protocol is also moving away from some earlier mechanisms, such as Dynamic Client Registration, toward approaches such as Client ID Metadata Documents.

These improvements reduce certain infrastructure and authorization risks, but they do not solve categories such as tool poisoning or prompt injection. Nor can they compensate for a tool designed with more privileges than necessary.

How to audit an MCP server

A useful MCP assessment begins by reconstructing the complete architecture rather than simply reviewing the code behind each tool.

1. Identify what sits behind the server

You need to understand which host uses the server, how the connection is established, which dependencies exist, and which systems the server can reach. The accounts, credentials, and tokens used at every hop should also be identified.

An apparently simple server may be operating with access to a corporate database, private repository, or cloud infrastructure. That context completely changes the severity of any vulnerability.

2. Inventory and classify every tool

Each tool should be classified according to the effect it can produce.

A read-only tool can expose information. A write tool can affect integrity. An administrative tool may deploy, delete, or restart systems. And a generic tool capable of running arbitrary commands or queries can provide an almost unlimited attack surface.

This classification makes it much easier to identify when a convenient capability gives the agent far more power than it actually needs.

3. Review descriptions and metadata

Tool descriptions should be treated as security-relevant inputs. It is worth checking who can modify them, whether they are retrieved dynamically, whether they can change after approval, and whether the user really sees the same information that the model receives.

A mismatch between what the human sees and what the model interprets can create an especially dangerous trust boundary.

4. Audit authentication and authorization per tool

Checking that the server requires login is not enough.

For each capability, determine which user can invoke it, against which resources, with which scopes, on behalf of which identity, and under which limits.

An administrative operation is not protected simply because the agent normally does not call it. Authorization must be enforced by the server.

5. Follow every input to its real destination

Traditional data-flow analysis remains fundamental.

Every parameter should be followed from MCP to the point where it is actually used, checking whether it reaches a shell, SQL query, filesystem path, URL, template, or external API.

This is where familiar vulnerabilities continue to appear: command injection, path traversal, SQL injection, SSRF, and URL manipulation.

6. Audit configuration as well

For local servers, MCP configuration deserves almost the same level of protection as executable code.

You should review who can modify the launch command, its arguments, environment variables, transport selection, registered servers, and project-specific configuration.

Many recent CVEs were not located inside an individual tool, but precisely in this control layer.

7. Analyze what every tool returns to the model

A tool may be perfectly protected against classic injections and still introduce risk if it returns attacker-controlled content directly into the model context.

It is therefore worth testing responses designed to change the agent's objective, make it invoke other tools, request secrets, conceal actions, or alter the expected task sequence.

8. Think about combinations

One of the biggest differences from a traditional assessment is that several independently safe tools may create a dangerous capability when the agent can combine them.

A file-reading tool may be reasonable. An HTTP request tool may also be reasonable. But an agent capable of using both consecutively may create an exfiltration channel.

The same applies to a tool that lists secrets and another that creates tickets in an external service. Neither needs to be vulnerable in isolation, but their composition may produce an outcome the original design never intended to allow.

How to secure an MCP architecture

Defense begins by refusing to treat the model, the tools, and their outputs as a single trust zone.

Design tools with a specific purpose

The more generic a tool is, the harder it becomes to limit its impact.

It is better to expose a specific capability for retrieving defined information or performing a particular operation than to expose an unrestricted shell, arbitrary SQL, or an unconstrained HTTP client.

Validate inputs just like in any other application

Parameters generated by a model are still untrusted data. They must be validated before reaching commands, paths, queries, URLs, or external services.

The fact that an argument was generated by a model does not change basic secure coding rules.

Apply least privilege

The MCP process and the credentials it uses should have only the permissions necessary for their intended function.

Outbound traffic should also be restricted when the server does not need unrestricted access to the Internet or internal networks.

Do not automatically register servers from untrusted content

A client should clearly show which server is being added, which local command will run, and which permissions it requires.

High-impact actions should require appropriate confirmation, especially when the decision may have been influenced by external content.

Separate data from instructions

Tool descriptions and outputs should not be treated as system instructions.

The host should assume that any content coming from a tool may ultimately be controlled by an external source.

Protect identity and secrets

Credentials should use minimal scopes and limited lifetimes. Unnecessary secrets should not be exposed through environment variables or configurations available to every server.

In OAuth deployments, it is also important to verify that credentials are delivered to the correct server and resource.

Control the supply chain

Installing a local MCP server often means installing and executing software.

Verified sources should therefore be used, versions should be pinned, dependencies should be reviewed, and organizations should maintain an inventory of approved MCP servers.

Mechanisms that automatically download and execute the latest version of a package are particularly sensitive in high-security environments.

Log what agents do

Traceability should include who performed the action, which server participated, which tool was invoked, relevant parameters, the result returned, the authorization used, and subsequent actions.

Without that context, incident investigation can become an attempt to reconstruct after the fact a chain of decisions that happened between a model and multiple external systems.

What this means for offensive security

MCP is particularly interesting for offensive security because it does not require abandoning traditional fundamentals.

Most of the analysis still depends on understanding trust boundaries, authentication, authorization, APIs, OAuth, SSRF, injections, secrets, filesystems, process execution, and business logic.

What changes is that there is now another layer making decisions between the input and the final action: the model.

This adds another question that should accompany every assessment: can untrusted information influence the action the agent decides to execute?

If the answer is yes, that decision needs to be followed all the way to the final capability, verifying which controls actually exist between the two.

The technical foundation required to analyze these boundaries is the same one we cover in the Web eXploitation Expert (WXE) course: APIs, authentication, authorization, SSRF, injections, OAuth, business logic, and trust relationship analysis.

MCP changes the interface, but underneath there are still servers, endpoints, tokens, processes, and data. Being able to follow those relationships is what makes it possible to distinguish a powerful feature from an exploitable vulnerability.

Interfaces change. Trust boundaries remain.

At SixHack Academy, we train the offensive reasoning needed to analyze modern applications beyond a simple vulnerability checklist. In Web eXploitation Expert (WXE), we go deeper into the techniques that continue to appear behind architectures such as MCP: authentication, APIs, OAuth, SSRF, injections, and business logic.

Frequently asked questions

What is Model Context Protocol?

MCP is an open protocol originally introduced by Anthropic that standardizes how AI applications connect to external tools and data sources. Since December 2025, the project has been part of the Agentic AI Foundation under the Linux Foundation.

Does MCP still belong to Anthropic?

Anthropic created MCP, but in December 2025 donated the project to the Agentic AI Foundation, a Linux Foundation project initially co-founded by Anthropic, Block, and OpenAI and supported by other companies in the industry.

Is MCP insecure by design?

It would not be accurate to describe it that way. MCP allows very powerful integrations to be built, and those integrations create security boundaries that must be protected. Some risks come from vulnerable implementations, others from clients placing too much trust in configuration or external content, and others from the agent model and prompt injection itself.

What is tool poisoning?

Tool poisoning is the manipulation of a tool, its description, metadata, or results in order to influence the model's behavior. OWASP includes it among the main risks specific to the MCP ecosystem.

Does using STDIO in an MCP server mean there is RCE?

No. With STDIO, executing the process configured to start the server is expected behavior. The risk appears when an untrusted party can control the command or arguments, register servers without consent, or otherwise manipulate that configuration.

Can a prompt injection end up executing commands?

It can if there is a chain connecting untrusted content to the agent's decisions and the agent has tools capable of modifying configuration, executing processes, or performing equivalent actions. CVE-2026-30615 in Windsurf is a real example of a chain where attacker-controlled content could ultimately register a malicious MCP STDIO server.

Does a remote MCP server need authentication?

It depends on what it exposes, but any server providing private resources or sensitive actions must have appropriate authentication and authorization. CVE-2026-33032 demonstrated the impact of leaving a sensitive MCP endpoint accessible without the intended authentication.

Does MCP use OAuth?

Remote deployments can use OAuth for authorization. The 2026 MCP specification also introduced several improvements related to issuer validation, scopes, and credential binding.

What is a shadow MCP server?

It is an MCP server installed or used outside the organization's inventory and controls. It can introduce software, credentials, or capabilities that the security team does not know about.

Do I need machine learning expertise to audit MCP?

Not to get started. The most important fundamentals remain web security, APIs, authentication, OAuth, injections, SSRF, permissions, processes, and secret management. You then need to add the threat model specific to agents and prompt injection.

References

← Back to Articles