Thank you for helping keep the Model Context Protocol and its ecosystem secure.

If you discover a security vulnerability in this repository, please report it through the GitHub Security Advisory process for this repository.

Please do not report security vulnerabilities through public GitHub issues, discussions, or pull requests.

To help us triage and respond quickly, please include:

• A description of the vulnerability
• Steps to reproduce the issue
• The potential impact
• Any suggested fixes (optional)

This section documents behaviors that are intentional design choices in MCP and are not considered security vulnerabilities. Understanding these behaviors helps developers build accurate threat models, enables security researchers to focus on genuine vulnerabilities, and clarifies the trust boundaries within MCP for all implementers.

MCP is designed to enable AI applications to interact with external tools, data sources, and services. The protocol operates under the following trust assumptions:

MCP clients trust MCP servers they connect to. When a user or application configures an MCP client to connect to a server, the client trusts that server to provide tools, resources, and prompts. The security of this trust relationship depends on proper server selection and configuration by the user or administrator.

Local MCP servers are trusted like any other software you install. When you run a local MCP server, you are trusting it with the same level of access as any other application or package on your system. Just as you would evaluate the trustworthiness of a library or tool before installing it, you should evaluate MCP servers before running them.

MCP servers trust the execution environment they run in. Servers have access to the resources available in their execution context. This is by design, as servers need access to local files, databases, APIs, or other resources to provide their intended functionality.

Users and administrators are responsible for server selection. MCP clients should provide clear information about server capabilities, but the decision to connect to and use a server rests with the user or administrator. Some clients may auto-connect to certain servers based on configuration; users should review these settings.

The following behaviors are intentional features of MCP and are not eligible for security vulnerability reports:

MCP clients using the STDIO transport launch MCP servers by executing commands. This command execution is an intended feature, not a vulnerability:

• Clients execute the configured command to start the server process
• The server process runs with the same privileges as the client
• Command arguments specified in configuration are passed to the server

This is expected behavior. Users configure which servers to run, and the client executes those configurations. Reports about "arbitrary command execution" via STDIO transport configuration, whether in MCP client applications or SDKs, are not vulnerabilities. Process spawning is a core feature of the STDIO transport mechanism.

When using the stdio transport, the client spawns the server as a local subprocess in the designated environment (e.g., OS, containerized sandbox) and both run with equivalent environment-level privilege. The SDK does not defend either peer against a malicious counterpart across the stdio channel: a malicious server already has arbitrary code execution by virtue of being run, and a malicious client already has full process control over the server it spawned.

Out of scope (file as a regular issue, no CVE/GHSA): reports whose only impact is that one stdio peer can crash, hang, exhaust resources of, or otherwise deny service to the other. If the affected SDK code is reachable via any of the supported remote transports or results in vulnerabilities such as a sandbox escape, the report remains in scope. Deployments that run stdio servers at reduced privilege (containers, sandboxes) are responsible for enforcing isolation at that boundary; the SDK's stdio transport is not a sandbox.

MCP servers provide capabilities that may have significant effects on the system or external services. These capabilities are features, not vulnerabilities:

File system access: Servers like the reference filesystem server intentionally read, write, and list files within their configured scope. A filesystem server's purpose is to provide file access to AI applications.

Git and version control: Servers providing git functionality can execute git commands, which may include operations like resetting commits or force pushing. If you grant an AI agent unrestricted access to git commands, it can perform any git operation—this is not a vulnerability in the server.

Database operations: Servers may execute queries, modify data, or manage database schemas based on their intended purpose.

Network and API access: Servers may make HTTP requests, call external APIs, or interact with remote services.

System commands: Some servers are designed to execute system commands or scripts.

This is expected behavior. Servers that perform their documented functions are working as intended. Reports about "server X can perform action Y" are not vulnerabilities when Y is the server's intended purpose. The appropriate safeguards and permissions for these capabilities are the responsibility of the user or administrator deploying the server.

MCP resources expose data to clients. Servers may provide resources containing file contents, database query results, API responses, or system information.

This is expected behavior. Resources are designed to provide context and data to AI applications. The scope of accessible data is determined by server implementation and configuration.

When AI applications use MCP, the language model determines which tools to invoke based on user requests and available tool descriptions. This means:

• The LLM may invoke tools in ways the user did not explicitly request
• Tool invocations depend on how the LLM interprets the user's intent
• Multiple tools may be invoked in sequence

This is expected behavior. LLM-driven tool selection is fundamental to how AI applications use MCP. Reports about "LLM invoked unexpected tool" are not MCP vulnerabilities, as they relate to LLM behavior and application-level controls.

MCP's security model places certain responsibilities on developers and operators:

Server developers are responsible for:

• Implementing appropriate access controls within their servers
• Documenting the capabilities and permissions their servers require
• Validating inputs from clients before performing sensitive operations
• Following the principle of least privilege in server design

Client developers are responsible for:

• Providing clear information to users about server capabilities
• Implementing appropriate consent mechanisms before connecting to servers
• Displaying tool invocations and resource access to users when appropriate
• Sandboxing server execution where feasible

Operators and users are responsible for:

• Connecting only to trusted MCP servers
• Reviewing server configurations before deployment
• Understanding the capabilities of servers they enable
• Configuring appropriate access restrictions for their environment

For additional guidance on building and deploying secure MCP implementations, see the Security Best Practices documentation.

The following categories are considered security vulnerabilities when they arise from flaws in the MCP specification or official SDK implementations:

• Protocol-level vulnerabilities: Flaws in the MCP specification that enable attacks regardless of implementation
• Authentication/authorization bypasses: Ways to access resources or invoke tools without proper authorization
• Implementation vulnerabilities: Bugs in specific SDK implementations (buffer overflows, injection flaws, etc.)
• Sandbox escapes: Breaking out of intended isolation boundaries explicitly defined in the protocol or SDKs
• Session hijacking: Unauthorized access to another user's session
• Token theft or leakage: Vulnerabilities that expose access tokens
• Cross-tenant access: Accessing resources belonging to other users in multi-tenant deployments

This list is not exhaustive.

Security reports against the official MCP SDKs are handled through GitHub Security Advisories on the affected SDK's repository. Private vulnerability reporting is enabled on every official SDK repository in the modelcontextprotocol organization.

When a report is received, the maintainers of that SDK assess whether the same issue affects other official SDKs. Many MCP vulnerabilities stem from shared patterns, transport implementations, or spec-level behavior that multiple SDKs implement the same way. The receiving maintainers coordinate with the maintainers of other potentially affected SDKs to determine which are impacted and to what degree, so that fixes and advisories can be released together rather than leaving some SDKs exposed after others have published.

If the root cause is a defect in the specification rather than an implementation bug, the coordinating maintainers will discuss this with the specification maintainers.

CVEs are assigned through GitHub's CNA as part of the GHSA workflow.

When evaluating whether to report a potential security issue:

1. Check this document first. If the behavior is listed as intended, it is not a vulnerability.
2. Consider the trust model. If the issue requires the attacker to already have access that the trust model assumes they have, it may not be a vulnerability.
3. Focus on unexpected access. Vulnerabilities typically involve accessing resources or performing actions that should not be possible given the established trust boundaries.
4. Provide context. If you believe you have found a genuine vulnerability, explain how it violates the intended security boundaries.