MCP security is being discussed as a new AI security frontier, but much of the actual risk looks familiar to anyone who has worked in application security.
The Model Context Protocol arrived in late 2024 framed as an AI breakthrough — a clean way to give language models access to tools, data, and workflows. Eighteen months later, the security headlines around MCP read like they were copy-pasted from 2008: command injection, path traversal, missing authentication, server-side request forgery, hardcoded credentials, and internet-exposed management interfaces.
The pattern is unmistakable to anyone who has watched a new infrastructure layer get adopted faster than it gets hardened. MCP is not failing because of exotic AI-specific threats. It is failing because the AppSec basics were skipped, the protocol was deployed as production infrastructure before anyone built operational security around it, and most defenders have not yet been told they own this layer.
This article argues that MCP security in 2026 is overwhelmingly an application security problem wearing AI clothing — and that defenders who already know how to run vulnerability management, detection engineering, and asset inventory have most of what they need. They just have to recognize MCP as in scope.
| Threat Type | Application security weaknesses inside AI-connected MCP servers, clients, tools, and integrations |
|---|---|
| Severity | High — especially where MCP servers connect to production systems, developer workstations, source code, cloud accounts, databases, or internal tools |
| Primary Risk | MCP deployments may expose classic AppSec vulnerabilities through a new AI infrastructure layer with privileged access |
| Common Weaknesses | Command injection, path traversal, authentication bypass, SSRF, hardcoded credentials, insecure tool execution, and exposed management interfaces |
| AI-Native Risk | Prompt injection, tool poisoning, schema poisoning, rug pulls, and manipulation of tool descriptions or metadata |
| Most Exposed Systems | MCP servers, developer workstations, coding agents, IDE extensions, cloud integrations, internal APIs, data connectors, and remote MCP packages |
| Defender Problem | MCP is often deployed by developers before security teams have inventory, ownership, logging, review, or governance in place |
| Detection Surface | MCP server processes, tool invocation logs, endpoint telemetry, network traffic, dependency scans, agent configuration files, and identity/token activity |
| Primary Control Shift | Treat MCP as application infrastructure: inventory it, authenticate it, patch it, log it, restrict it, and govern it |
| Business Impact | Compromised MCP infrastructure can expose source code, credentials, production data, internal systems, developer machines, and downstream enterprise workflows |
There is no shortage of writing on MCP security framed around prompt injection, tool poisoning, and adversarial context manipulation. These are real risks and worth covering. But when researchers actually catalog the disclosed vulnerabilities, the distribution looks nothing like an AI threat report.
An analysis by AppSec vendor Endor Labs of 2,614 MCP implementations found that 82% used file operations vulnerable to path traversal, 67% used APIs related to code injection, and 34% used APIs susceptible to command injection. The disclosed CVE record reflects the same pattern: command injection, authentication bypass, server-side request forgery, path traversal, and supply chain issues dominate. Vulnerabilities in MCP client tooling and inspectors — the developer-facing layer rather than the server — make up a meaningful share on their own.
These are not novel attack classes. Path traversal and command injection have been part of application security for decades. The vulnerability classes appearing in MCP servers in 2026 are the same ones any security engineer would expect to find in a hastily written web application from years ago. The difference is the layer they are appearing in and the privileges that layer holds.
The mistake in the dominant framing is treating MCP as an AI security problem first and an infrastructure problem second. The CVE record points the other way. Prompt injection through tool descriptions matters, and this article covers it below, but it is not where the volume of confirmed risk appears to be concentrated this year.
In April 2026, OX Security disclosed a class of vulnerabilities in Anthropic’s MCP STDIO transport that it characterized as architectural rather than implementation-level. The flaw enables arbitrary command execution on systems running affected MCP implementations, and OX reported that it was present across official Anthropic SDKs including Python, TypeScript, Java, and Rust. OX’s analysis identified more than 7,000 publicly accessible servers and software packages totaling over 150 million downloads as inheriting the exposure.
Anthropic’s response was that the behavior is expected and that input sanitization is the developer’s responsibility. Whether one agrees with that position is a protocol-design debate. The defender takeaway is more practical: a single upstream architectural decision can propagate silently into language bindings, reference implementations, and downstream libraries built on top.
Waiting for the protocol to fix this is not a strategy any vulnerability manager would accept for a more conventional dependency.
This pattern recurs throughout the MCP ecosystem. In January 2026, three CVEs landed in Anthropic’s own reference mcp-server-git implementation — CVE-2025-68143, CVE-2025-68144, and CVE-2025-68145 — covering path traversal and argument injection. The reference implementation is the one developers are explicitly told to model their code after. When the canonical example ships unsafe defaults, every downstream copy can inherit them.
The supply chain implication is the one that matters operationally. MCP servers are increasingly distributed through registries, marketplaces, and npm or PyPI packages. CVE-2025-6514 in mcp-remote, a popular package for connecting to remote MCP servers, became a watershed event. The package contained a command injection vulnerability, carried a CVSS score of 9.6, and had over 437,000 downloads at disclosure.
One of the first mass-scale MCP vulnerability in the wild was a supply chain incident, not a prompt injection one.
Trend Micro’s late-April 2026 scan results showed 1,467 publicly exposed MCP servers, nearly triple its previous count. More notably, the research demonstrated that several of these exposed paths into the underlying cloud infrastructure — not just the data the MCP server was intended to broker, but the AWS or Azure environment hosting it.
Vulnerabilities disclosed in cloud-specific MCP implementations carried CVSS scores of 9.8 and allowed unauthenticated command execution within the cloud environment.
This is the same trajectory defenders have seen before with exposed Elasticsearch instances, open Kubernetes dashboards, internet-facing Redis, unmanaged Jenkins servers, and forgotten development consoles. A new infrastructure category gets adopted faster than the operational security around it. A tooling gap means deployments default to exposed or unauthenticated. Scanners find them. Attackers figure out how to monetize them.
The 1,467 number will likely be higher next quarter. It usually is.
The defensive playbook for this is not new. Asset inventory needs to include MCP servers. External attack surface management tools need to fingerprint them. Network controls need to restrict them. Authentication needs to be required, not optional.
None of this is exotic AI research. The work is recognizing that MCP servers are now in scope for the same controls that already cover every other piece of internet-facing infrastructure.
A pattern that distinguishes MCP from most other infrastructure layers is that the developer workstation is itself a target.
Tools like Claude Code, Cursor, VS Code, Windsurf, and Gemini-CLI consume MCP servers. When the consuming client is vulnerable, every MCP server the developer connects to becomes an attack vector against the developer’s machine. That means credentials, source code, SSH keys, cloud tokens, browser sessions, local files, and repository access may all be in scope.
OX Security’s research identified Cursor, VS Code, Windsurf, Claude Code, and Gemini-CLI as vulnerable to MCP-based prompt injection attacks. Windsurf reportedly required zero user interaction for exploitation. Anthropic’s own MCP Inspector — the tool intended to help developers debug and inspect MCP servers — shipped with a remote code execution vulnerability of its own, CVE-2025-49596. In that case, the diagnostic tooling was itself an attack vector before any malicious MCP server even entered the picture.
The takeaway for defenders running developer environments at scale is direct: MCP-enabled IDEs and CLI tools belong on the endpoint inventory, in the patch cadence, and in the threat model.
A developer running a malicious-but-unsuspicious MCP server inside a coding agent is functionally similar to opening a malicious document — except the agent runs continuously, has tool access, and has been instructed to act on whatever it reads.
The genuinely AI-native attack class on MCP is tool poisoning.
Tool poisoning means manipulating the descriptions, schemas, or metadata of tools so that the consuming language model treats attacker instructions as part of its trusted context. Invariant Labs demonstrated in April 2025 that tool descriptions enter the agent’s context window as trusted content. An attacker who controls a description can hide instructions the model reads and acts on.
Variants include rug pulls, where a previously trusted server pushes a malicious update; schema poisoning, where interface definitions are corrupted; and tool shadowing, where a duplicate tool is registered to intercept or influence calls.
These risks are real and worth defending against.
They are not, however, where the volume of confirmed damage appears to be concentrated in 2026. A defender prioritizing MCP security work should fix command injection vulnerabilities in their own MCP servers, lock down authentication on exposed instances, and pin server versions in agent configurations before building advanced tool-description sanitization pipelines.
The AppSec basics produce more risk reduction per hour spent than the AI-novel controls do at this stage of the ecosystem.
This is the contrarian framing the article rests on: defenders who are nervous about prompt injection through MCP tools should look at command injection exposure first, because the available vulnerability data points strongly in that direction.
OWASP’s draft MCP Top 10 names something most enterprise security teams have not yet inventoried: Shadow MCP.
Shadow MCP refers to unapproved MCP server deployments spun up by developers, data teams, or research groups for experimentation. These deployments are often connected to production data or credentials and are rarely registered with security or governance.
The dynamics mirror Shadow IT and Shadow AI exactly.
A developer wants to give Claude Code access to an internal database. They find a community MCP server on a registry, point it at production read replicas, and never tell anyone. The server may be vulnerable. The credentials it holds may be over-privileged. The tool descriptions it serves may be controlled by whoever maintains the upstream package.
None of this shows up in a CMDB or SBOM unless someone is specifically looking for it.
The detection problem is solvable, but it requires treating MCP as a first-class asset class. Network-level fingerprinting can catch exposed servers. Endpoint inventory of MCP-enabled IDEs can catch the consumer side. Code review of agent configurations can identify what servers a team is actually invoking.
Most of these controls already exist. They just need MCP added to their scope.
Pulling the threads together, here is a concrete posture for a security team operating in an environment with meaningful MCP adoption.
Inventory MCP servers as infrastructure. Internal-network discovery and external-attack-surface scanning both need MCP fingerprints in their detection rules.
Track developer-facing clients such as Claude Code, Cursor, VS Code with relevant extensions, Windsurf, and Gemini-CLI on the endpoint inventory. Maintain a list of approved MCP servers and the version each consuming agent is pinned to.
Treat servers without an owner the way you treat unowned web applications. They should either be assigned an owner, brought into policy, or removed.
Subscribe to the Vulnerable MCP Project and GitHub Security Advisories for the MCP namespace. Add the most-downloaded MCP packages to your SBOM and dependency-tracking pipeline.
Treat reference implementations as untrusted starting points. Security review any code copied from them. When a CVE lands in a widely deployed MCP package, treat the response window the same way you would treat a CVE in a popular web framework — because the blast radius can be similar.
No MCP server should be reachable from the public internet without authentication.
Security teams should apply basic controls:
Credentials held by MCP servers should be scoped narrowly and rotated. If a server holds long-lived production credentials, that is the finding to fix this quarter.
Log MCP tool invocations the way you log API calls.
Defenders should log:
Tool descriptions should be hashed at agent-configuration time and re-validated at session start. A tool description that changes between sessions should be treated as an alert or at least a review trigger.
Outbound traffic from an MCP server to destinations it has not previously communicated with should be investigated. Command execution patterns from MCP server processes should match a known baseline. Deviations should be visible to security operations.
None of this is exotic. It is the same telemetry pipeline already running for other internal services.
Security teams need a standing policy on which MCP servers may be installed, by whom, and against which data sources.
The policy should answer basic questions:
There also needs to be a review process for adding a new MCP server to a developer agent’s allowed list, and a way for security to say no to an MCP server that holds production credentials and has no maintainer.
The most useful thing a security team can do with MCP in 2026 is stop treating it as an AI problem and start treating it as an infrastructure problem with AI-flavored privileges.
The vulnerability classes are familiar. The detection patterns are familiar. The asset management discipline is familiar. What is unfamiliar is the speed of adoption and the fact that the protocol’s design choices can propagate widely before anyone has a chance to harden them.
Defenders who run mature AppSec programs already have most of the muscle memory required. The work is one of scope expansion, not capability acquisition.
MCP is in scope for vulnerability management.
MCP is in scope for asset inventory.
MCP is in scope for detection engineering.
MCP is in scope for governance.
The teams that recognize this early will spend 2026 patching MCP servers the same way they patched web servers a decade ago — methodically, on a deadline, with logs to show for it.
The teams that keep filing MCP under “AI threats, watch this space” may spend the year doing incident response.
ByteVanguard tracks AI security, KEV activity, and enterprise threat intelligence. Subscribe for weekly briefings.
If you find ByteVanguard useful, you can support the site and help keep the analysis independent.
Support the analysis