CVE-2026-52869: MCP Python SDK HTTP Transports Serve Session Requests Vulnerability

HIGH
Advisory Identifier: GHSA-jpw9-pfvf-9f58
CVSS 7.1
CWE-639
Published
Advisory Summary

CVE-2026-52869 is a HIGH (CVSS 7.1) http transports serve session requests vulnerability (CWE-639: Authorization Bypass Through User-Controlled Key) affecting MCP Python SDK libraries in the PyPI ecosystem. The issue involves http transports serve session requests without verifying the authenticated principal. Remediation is available by upgrading affected packages to version 1.27.2.

CVE-2026-52869 at a Glance

CVE Identifier CVE-2026-52869
GHSA Identifier GHSA-jpw9-pfvf-9f58
Severity HIGH
CVSS v3.1 Base Score 7.1
CWE Classification CWE-639: Authorization Bypass Through User-Controlled Key
Affected Product MCP Python SDK
Package Ecosystem PyPI
Published Date
Last Updated

Security Impact

CVSS: 7.1

The security impact metrics below are parsed directly from the CVSS v3.1 vector string (CVSS:3.1/AV:N/AC:H/PR:L/UI:N/S:U/C:H/I:H/A:L).

Attack Vector Network (AV:N)
Attack Complexity High (AC:H)
Privileges Required Low (PR:L)
User Interaction None (UI:N)
Scope Unchanged (S:U)
Confidentiality High (C:H)
Integrity High (I:H)
Availability Low (A:L)

How to Fix CVE-2026-52869

To remediate this vulnerability, upgrade all affected MCP Python SDK dependencies to a patched release. Both direct and transitive dependencies should be checked, as frameworks or security libraries may pull in vulnerable versions transitively.

mcp fixed: 1.27.2
pip install mcp>=1.27.2
Verify Direct and Transitive Dependencies

Run the following command in your project directory to verify that all resolved dependencies use the patched release:

pip show mcp

How to Check if You Are Affected

To determine whether your Python environment is affected by CVE-2026-52869, inspect your installed packages using pip:

pip show mcp

Analyze the terminal output to locate any version of MCP Python SDK in your dependency tree. If any resolved version matches the vulnerable ranges listed in the table below (for example, versions earlier than 1.27.2), your application is affected.

Note: The pip show mcp command checks currently installed packages in your active Python environment.

Technical Details

Vulnerability Mechanism & Technical Analysis

This vulnerability is classified under CWE-639: Authorization Bypass Through User-Controlled Key, where the system's authorization functionality does not prevent one user from gaining access to another user's data or record by modifying the key value identifying the data. In MCP Python SDK, software state validation or input boundaries are circumvented during processing. Review the official source advisory statement below for specific affected components, classes, and reproduction details.

Source Advisory Statement

### Summary In affected versions, the SSE and Streamable HTTP server transports routed incoming requests to an existing session based only on the session identifier, without verifying that the request was authenticated as the same principal that created the session. Anyone who learned or guessed a session ID could send JSON-RPC messages on that session, regardless of which bearer token the request carried. ### Am I affected? Only if a developer's application server uses an HTTP transport (SSE, or Streamable HTTP in stateful mode) **and** authenticates requests. Servers on stdio, stateless Streamable HTTP, or with no authentication configured are not affected. ### Details Both transports look up the target session by its identifier alone — the `session_id` query parameter for SSE (`mcp.server.sse.SseServerTransport`) and the `Mcp-Session-Id` header for Streamable HTTP (`mcp.server.streamable_http_manager.StreamableHTTPSessionManager`). Once the lookup succeeded, the request was handled on that session without comparing its authentication context to the credentials presented when the session was created, so a request authenticated as a different OAuth client could inject messages into the session. On the SSE transport the response is delivered to the original client's event stream; on the Streamable HTTP transport it is returned on the injecting request, so the injecting client can also read the result. The SSE transport has been affected since the first release; the Streamable HTTP transport since version 1.8.0. ### Impact Servers using either HTTP transport together with the SDK's built-in bearer-token authentication are affected: the per-client isolation that authentication provides can be bypassed for any session whose ID is known. Session IDs are randomly generated UUIDs, so exploitation requires obtaining one out of band (logs, network observation). Servers that do not enable bearer-token authentication have no per-client isolation to bypass and are not addressed by this advisory, and stateless Streamable HTTP deployments do not maintain sessions and are unaffected. ### Mitigation Upgrade to version 1.27.2 or later, which records the authenticated principal that created each session — the OAuth client ID together with the token's issuer and subject when the token verifier supplies them — and answers requests presenting a different principal with the same 404 response as for an unknown session. Deployments where many end users share a single OAuth client (hosted MCP clients, gateways) should ensure their token verifier populates `AccessToken.subject` (e.g. from the token's `sub` claim) so sessions are isolated per user rather than per client. Deployments using a custom authentication backend other than the built-in `BearerAuthBackend` should enforce an equivalent check themselves.

CVE-2026-52869 Affected MCP Python SDK Versions

1 component(s)
Fixed Versions:
1.27.2
Product / Package Ecosystem Affected Versions Fixed Version
mcp
PyPI
< 1.27.2
1.27.2

References

Frequently Asked Questions

What is CVE-2026-52869?
CVE-2026-52869 is a security vulnerability in MCP Python SDK involving HTTP transports serve session requests without verifying the authenticated principal under CWE-639: Authorization Bypass Through User-Controlled Key.
Which MCP Python SDK versions are affected?
Affected versions include releases prior to 1.27.2 across affected packages: mcp.
What version fixes CVE-2026-52869?
Upgrading to 1.27.2 (or the latest patched release for your respective branch) resolves the vulnerability.
Is mcp affected?
Yes, mcp is affected in releases prior to 1.27.2. Upgrade your dependency to 1.27.2 or later.
What is the CVSS score of CVE-2026-52869?
CVE-2026-52869 has a CVSS v3.1 base score of 7.1 (HIGH) with vector string CVSS:3.1/AV:N/AC:H/PR:L/UI:N/S:U/C:H/I:H/A:L.
What CWE is associated with CVE-2026-52869?
CVE-2026-52869 is classified under CWE-639: Authorization Bypass Through User-Controlled Key (The system's authorization functionality does not prevent one user from gaining access to another user's data or record by modifying the key value identifying the data.).
How can I check PyPI dependencies for CVE-2026-52869?
Run the dependency tree command: 'pip show mcp'. This command lists direct and transitive dependencies in your build configuration so you can verify if a vulnerable version is resolved.
Machine-readable OSV JSON OSV v1.5 Schema
Normalized schema output
{
  "schema_version" : "1.4.0",
  "id" : "GHSA-jpw9-pfvf-9f58",
  "modified" : "2026-07-16T19:58:53Z",
  "published" : "2026-07-16T19:58:53Z",
  "aliases" : [ "CVE-2026-52869" ],
  "summary" : "MCP Python SDK: HTTP transports serve session requests without verifying the authenticated principal",
  "details" : "### Summary\nIn affected versions, the SSE and Streamable HTTP server transports routed incoming requests to an existing session based only on the session identifier, without verifying that the request was authenticated as the same principal that created the session. Anyone who learned or guessed a session ID could send JSON-RPC messages on that session, regardless of which bearer token the request carried.\n\n### Am I affected?\nOnly if a developer's application server uses an HTTP transport (SSE, or Streamable HTTP in stateful mode) **and** authenticates requests. Servers on stdio, stateless Streamable HTTP, or with no authentication configured are not affected.\n\n### Details\nBoth transports look up the target session by its identifier alone — the `session_id` query parameter for SSE (`mcp.server.sse.SseServerTransport`) and the `Mcp-Session-Id` header for Streamable HTTP (`mcp.server.streamable_http_manager.StreamableHTTPSessionManager`). Once the lookup succeeded, the request was handled on that session without comparing its authentication context to the credentials presented when the session was created, so a request authenticated as a different OAuth client could inject messages into the session. On the SSE transport the response is delivered to the original client's event stream; on the Streamable HTTP transport it is returned on the injecting request, so the injecting client can also read the result. The SSE transport has been affected since the first release; the Streamable HTTP transport since version 1.8.0.\n\n### Impact\nServers using either HTTP transport together with the SDK's built-in bearer-token authentication are affected: the per-client isolation that authentication provides can be bypassed for any session whose ID is known. Session IDs are randomly generated UUIDs, so exploitation requires obtaining one out of band (logs, network observation). Servers that do not enable bearer-token authentication have no per-client isolation to bypass and are not addressed by this advisory, and stateless Streamable HTTP deployments do not maintain sessions and are unaffected.\n\n### Mitigation\nUpgrade to version 1.27.2 or later, which records the authenticated principal that created each session — the OAuth client ID together with the token's issuer and subject when the token verifier supplies them — and answers requests presenting a different principal with the same 404 response as for an unknown session.\n\nDeployments where many end users share a single OAuth client (hosted MCP clients, gateways) should ensure their token verifier populates `AccessToken.subject` (e.g. from the token's `sub` claim) so sessions are isolated per user rather than per client. Deployments using a custom authentication backend other than the built-in `BearerAuthBackend` should enforce an equivalent check themselves.",
  "severity" : [ {
    "type" : "CVSS_V3",
    "score" : "CVSS:3.1/AV:N/AC:H/PR:L/UI:N/S:U/C:H/I:H/A:L"
  } ],
  "affected" : [ {
    "package" : {
      "ecosystem" : "PyPI",
      "name" : "mcp"
    },
    "ranges" : [ {
      "type" : "ECOSYSTEM",
      "events" : [ {
        "introduced" : "0"
      }, {
        "fixed" : "1.27.2"
      } ]
    } ],
    "database_specific" : {
      "last_known_affected_version_range" : "<= 1.27.1"
    }
  } ],
  "references" : [ {
    "type" : "WEB",
    "url" : "https://github.com/modelcontextprotocol/python-sdk/security/advisories/GHSA-jpw9-pfvf-9f58"
  }, {
    "type" : "ADVISORY",
    "url" : "https://nvd.nist.gov/vuln/detail/CVE-2026-52869"
  }, {
    "type" : "WEB",
    "url" : "https://github.com/modelcontextprotocol/python-sdk/pull/2690"
  }, {
    "type" : "WEB",
    "url" : "https://github.com/modelcontextprotocol/python-sdk/pull/2719"
  }, {
    "type" : "WEB",
    "url" : "https://github.com/modelcontextprotocol/python-sdk/commit/1abcca2408a6b50e10ec601181f63f9978705c00"
  }, {
    "type" : "WEB",
    "url" : "https://github.com/modelcontextprotocol/python-sdk/commit/ce267b6fc515dc4efc1dc70b6975b16ff0feef0a"
  }, {
    "type" : "PACKAGE",
    "url" : "https://github.com/modelcontextprotocol/python-sdk"
  }, {
    "type" : "WEB",
    "url" : "https://github.com/modelcontextprotocol/python-sdk/releases/tag/v1.27.2"
  } ],
  "database_specific" : {
    "cwe_ids" : [ "CWE-639" ],
    "severity" : "HIGH",
    "github_reviewed" : true,
    "github_reviewed_at" : "2026-07-16T19:58:53Z",
    "nvd_published_at" : "2026-07-15T20:17:38Z"
  }
}