The Model Context Protocol (MCP) was introduced by Anthropic in November 2024 as a standardized way for AI assistants to interact with external tools and data sources. Marketed as the "USB-C for AI applications," it promised to simplify how developers connect LLMs to databases, APIs, filesystems, and development tools. 

Adoption of the standard has been rapid, with up to 1,021 MCP servers being created in a single week. But a steady stream of critical vulnerabilities throughout 2025 and into 2026 has revealed that MCP's rapid adoption outpaced security considerations in the protocol's trust assumptions, reference implementations, popular third-party servers, and the hosting platforms that emerged to simplify deployment. 

These vulnerabilities are not inherently new, and they’re often common weaknesses within the newer attack surface that MCPs provide. Examples include command injection, server-side request forgery (SSRF), path traversal, missing authentication, and insufficient input validation, all of which are well-documented and observed classes of vulnerabilities. These more “classical” vulnerabilities, combined with emerging tactics such as prompt injection, only widen the attack surface and broaden potential impact. 

This echoes our research in the 2025 Dependency Management Report, where we found that among 2,614 MCP implementations: 

• 82% use file system operations prone to Path Traversal (CWE-22)
• 67% use sensitive APIs related to Code Injection (CWE-94)
• 34% use sensitive APIs related to Command Injection (CWE-78)
• 5-7% used APIs tied to Cross-Site Scripting (CWE-79, 7%), SQL Injection (CWE-89, 6%), and Open Redirect (CWE-601, 5%)
  

This post examines the patterns emerging from MCP's first year of vulnerability disclosures and what they reveal about the challenges of securing AI-native infrastructure.

Analysis of CVEs

Anthropic mcp-server-git (CVE-2025-68143, CVE-2025-68144, CVE-2025-68145)

Three vulnerabilities were publicized on January 20, 2026 in Anthropic's official mcp-server-gitThese vulnerabilities were within Anthropic’s reference implementation guidance, which material developers are meant to replicate in their own code base.

1. CVE-2025-68143 allowed the git_init tool to create repositories at arbitrary filesystem paths because the configured --repository boundary was never validated. 
2. CVE-2025-68145 had the same root cause: path arguments weren't checked against the allowed scope. 
3. CVE-2025-68144 passed user-controlled arguments directly to the Git CLI without sanitization, enabling argument injection.

None of these are novel attack techniques. Path traversal (CWE-22) and command injection (CWE-77) have been in the OWASP Top 10 and CWE Top 25 for years. The vulnerable code patterns are straightforward:

# CVE-2025-68143/68145: No validation of repo_path against configured boundary
repo_path = Path(arguments["repo_path"])

# CVE-2025-68144: Unsanitized argument passed to CLI
return repo.git.diff(f"--unified={context_lines}", target)

‍

What makes these vulnerabilities dangerous in the MCP context is the attack vector and the agency given. Because of prompt injection risks, an attacker may not need direct access to the victim's system. Instead, an attacker can identify material processed by the LLM and inject a hidden prompt within a malicious README file, a poisoned GitHub issue, or a compromised webpage. The LLM processes the attacker's payload and may call the vulnerable MCP tools with attacker-controlled arguments.

Framelink Figma MCP Server (CVE-2025-53967)

CVE-2025-53967 affected the Framelink Figma MCP server, one of the most popular MCP servers in the ecosystem with over 600,000 downloads and 10,000+ GitHub stars. Imperva discovered a command injection vulnerability in the fetchWithRetry function that constructed curl commands using unsanitized user input:

// Vulnerable pattern in src/utils/fetch-with-retry.ts
const curlCommand = `curl -s -S --fail-with-body -L ${curlHeaders.join(" ")} "${url}"`;

‍

An attacker could inject shell metacharacters through the fileKey parameter:

fileKey="$(id>/tmp/TEST)"

The vulnerability is exploitable through indirect prompt injection. An attacker doesn't need network access to the MCP server directly. They can embed malicious instructions in Figma design files or comments that get processed by an AI coding assistant. The assistant, following what it interprets as legitimate instructions, calls the vulnerable get_figma_data tool with the attacker's payload.

DNS rebinding attacks expand the attack surface further. A victim visiting a malicious website could have requests routed to their local MCP server, triggering command execution without any interaction with the AI assistant at all.

Orval MCP Client Code Injection (CVE-2026-22785)

CVE-2026-22785 demonstrates how MCP tooling can inherit vulnerabilities from upstream data sources. Orval generates type-safe TypeScript clients from OpenAPI specifications, and its MCP server generation incorporated the summary field without proper escaping.

An attacker controlling an OpenAPI spec could inject code directly:

paths:
  /pet/findByStatus:
    get:
      summary: Finds Pets by status.' + require('child_process').execSync("open -a Calculator").toString(),//

‍

The generated MCP client would execute arbitrary code when processed. This isn't a flaw in MCP itself, but rather a reminder that MCP servers often process untrusted input from external sources. The trust chain extends beyond the immediate tool implementation to every data source that feeds into it.

CVE-2026-23947 followed shortly after, affecting a different code path in the same package where x-enumDescriptions fields were embedded without escaping. The pattern repeats: user-controlled strings concatenated into executable code.

What to do about it

Exclude LLMs and MCP servers from your trust boundary

These vulnerabilities share a common architectural assumption: Inputs from LLMs or MCP components can be trusted. This assumption is flawed for several reasons:

• Prompt injection is a side effect and a property of how LLMs work. Language models process text and follow instructions. They cannot reliably distinguish between instructions from a trusted operator and instructions embedded in content they're asked to process. Every document, webpage, email, or API response an LLM reads is a potential vector for injecting instructions. Security models that assume the LLM will only pass "good" inputs to MCP tools will eventually fail.
• MCP servers inherit the trust problems of their inputs. An MCP server that processes data from external sources (OpenAPI specs, Git repositories, Figma files, API responses) is processing potentially attacker-controlled content. The server cannot assume this content is benign simply because it arrived through an expected channel.
• Outputs from LLMs and MCP servers are untrusted by definition. If the input can be manipulated, the output can be manipulated. Code that consumes LLM responses or MCP tool results must validate and sanitize that data before using it in security-sensitive operations.

CVE-2026-22807 in vLLM illustrates this pattern outside the MCP context. vLLM loads Hugging Face auto_map dynamic modules during model resolution without gating on trust_remote_code, allowing attacker-controlled Python code in a model repo to execute at server startup. The vulnerability occurs because the code trusts external data (model configs from Hugging Face) that can be attacker-controlled. An attacker who can influence the model repo or path achieves arbitrary code execution before any request handling occurs. The documented security boundary (trust_remote_code) exists in the API but wasn't enforced in the code path that mattered.

The remediation principle is the same across all these vulnerabilities: Treat LLM outputs, MCP tool arguments, and external data sources as untrusted input. Validate against expected schemas. Sanitize before passing to shell commands, SQL queries, or code generation. Enforce boundaries in code, not just documentation.

Considerations for AppSec teams

Inventory MCP deployments and their data sources. Know which MCP servers are running in your environment, what permissions each server has, and what external data feeds into them. Developers often install MCP servers without security review.

Treat all LLM and MCP outputs as untrusted. Validate and sanitize data at every boundary where it's consumed. This applies to MCP tool arguments, LLM-generated code, API responses processed by agents, and any content that flows through the AI pipeline.

Apply standard secure coding practices at MCP tool boundaries:

• Validate paths against configured boundaries using canonicalization
• Escape or reject special characters in data embedded in generated code
• Enforce authentication even for localhost-bound services

Evaluate server combinations for compound risk. Individual MCP servers may be low-risk in isolation. The Cyata attack chain required both Git and Filesystem servers. Document which servers run together and assess the combined attack surface.

Audit third-party MCP servers before deployment. The npm and PyPI ecosystems have hundreds of MCP servers of varying quality. Check for recent security updates, review open issues, assess maintainer responsiveness, and consider whether the maintainer has security expertise.

Monitor for anomalous MCP activity. Log tool invocations and alert on unexpected patterns: git_init calls to paths outside configured repositories, file operations targeting sensitive directories, shell metacharacters in tool arguments.

Conclusion

MCP's first year delivered a clear message: AI infrastructure needs application security, not just model safety. MCPs thus far have concentrated existing risks into a single layer and inherit many of the classical vulnerabilities that impact other code and dependencies, now with additional input sources in the form of LLMs. 

AppSec teams that adapt their threat models now, treating LLMs as untrusted intermediaries rather than trusted components, will avoid repeating the hard lessons of the past. The classical vulnerabilities aren't new, but the attack vectors are. Understanding that distinction is what separates secure AI deployments from incidents waiting to happen.