modelcontextprotocol/SECURITY.md at main · modelcontextprotocol/modelcontextprotocol · GitHub Skip to content Navigation Menu Sign in Appearance settings * Platform * AI CODE CREATION * GitHub Copilot Write better code with AI * GitHub Copilot app Direct agents from issue to merge * MCP Registry Integrate external tools * DEVELOPER WORKFLOWS * Actions Automate any workflow * Codespaces Instant dev environments * Issues Plan and track work * Code Review Manage code changes * Code Quality Enforce quality at merge * APPLICATION SECURITY * GitHub Advanced Security Find and fix vulnerabilities * Code security Secure your code as you build * Secret protection Stop leaks before they start * EXPLORE * Why GitHub * Documentation * Blog * Changelog * Marketplace View all features * Solutions * BY COMPANY SIZE * Enterprises * Small and medium teams * Startups * Nonprofits * BY USE CASE * App Modernization * DevSecOps * DevOps * CI/CD * View all use cases * BY INDUSTRY * Healthcare * Financial services * Manufacturing * Government * View all industries View all solutions * Resources * EXPLORE BY TOPIC * AI * Software Development * DevOps * Security * View all topics * EXPLORE BY TYPE * Customer stories * Events & webinars * Ebooks & reports * Business insights * GitHub Skills * SUPPORT & SERVICES * Documentation * Customer support * Community forum * Trust center * Partners View all resources * Open Source * COMMUNITY * GitHub Sponsors Fund open source developers * PROGRAMS * Security Lab * Maintainer Community * GitHub Stars * Archive Program * REPOSITORIES * Topics * Trending * Collections * Enterprise * ENTERPRISE SOLUTIONS * Enterprise platform AI-powered developer platform * AVAILABLE ADD-ONS * GitHub Advanced Security Enterprise-grade security features * Copilot for Business Enterprise-grade AI features * Premium Support Enterprise-grade 24/7 support * Pricing Search / Sign in Sign up Appearance settings You signed in with another tab or window. Reload to refresh your session. You signed out in another tab or window. Reload to refresh your session. You switched accounts on another tab or window. Reload to refresh your session. Dismiss alert Uh oh! There was an error while loading. Please reload this page . modelcontextprotocol / modelcontextprotocol Public * Notifications You must be signed in to change notification settings * Fork 1.8k * Star 9.2k * Code * Issues 69 * Pull requests 78 * Discussions * Actions * Projects * Security and quality 1 * Insights Additional navigation options * Code * Issues * Pull requests * Discussions * Actions * Projects * Security and quality * Insights Files Expand file tree main Breadcrumbs * modelcontextprotocol / SECURITY.md Copy path Blame More file actions Blame More file actions Latest commit   History History History 221 lines (161 loc) · 10.6 KB main Breadcrumbs * modelcontextprotocol / SECURITY.md Copy path Top File metadata and controls * Preview * Code * Blame 221 lines (161 loc) · 10.6 KB Raw Copy raw file Download raw file Outline Edit and raw actions Security Policy Thank you for helping keep the Model Context Protocol and its ecosystem secure. Reporting Security Issues 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. What to Include 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) Intended Behaviors and Trust Model 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. Trust Model 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. Behaviors That Are Not Vulnerabilities The following behaviors are intentional features of MCP and are not eligible for security vulnerability reports: Command Execution for STDIO Transport 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. STDIO Transport Trust Boundary 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. Server Capabilities and Side Effects 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. Resource Access Patterns 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. LLM-Driven Tool Invocation 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. Developer and Operator Responsibilities 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. What Remains In Scope 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. SDK Vulnerability Disclosure 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. Reporting Guidelines When evaluating whether to report a potential security issue: * Check this document first. If the behavior is listed as intended, it is not a vulnerability. * 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. * Focus on unexpected access. Vulnerabilities typically involve accessing resources or performing actions that should not be possible given the established trust boundaries. * Provide context. If you believe you have found a genuine vulnerability, explain how it violates the intended security boundaries. Footer (c) 2026 GitHub, Inc. Footer navigation * Terms * Privacy * Security * Status * Community * Docs * Contact * Manage cookies * Do not share my personal information You can’t perform that action at this time.