CVE-2026-52869 Root-Cause Patch Review for MCP Python SDK Session Ownership

Vulnerability

CVE-2026-52869 describes a session hijacking and authorization bypass in the MCP Python SDK: session identifiers were not bound to the authenticated principal that created them, so any bearer-token-authenticated user who learned a valid session ID could inject JSON-RPC messages into another client session. The issue affected session-oriented transports, notably SSE and streamable HTTP, because request authorization was evaluated at the bearer-token layer but not revalidated against session ownership on later requests.

The patch history shows the root cause was missing identity propagation and missing session-owner checks. Before the fix, transport code accepted a supplied session ID if it existed, without comparing the current request principal to the principal that established that session. The follow-up auth/provider changes add subject and claims support so transports can compare a more precise principal tuple than client_id alone, including RFC-style sub and iss where available.

Relevant sources: commit 1abcca2, commit ce267b6, PR #2690, PR #2719, CVE record.

if request_mcp_session_id is not None and request_mcp_session_id in self._server_instances:
    # vulnerable behavior: session existence was sufficient
    ...

Patch

The fix is split across identity plumbing and transport enforcement.

First, the auth model is extended so access tokens can carry subject and arbitrary claims, and the example auth server/provider/verifier now propagates sub and iss. In commit 1abcca2, AccessToken-related types gain:

subject: str | None = None  # RFC 7662/9068 `sub`: resource owner; unique only per issuer
claims: dict[str, Any] | None = None  # additional claims (e.g. `iss`, `act`)

Second, commit ce267b6 introduces an AuthorizationContext derived from the authenticated user:

class AuthorizationContext(TypedDict):
    client_id: str
    issuer: str | None
    subject: str | None


def authorization_context(user: AuthenticatedUser) -> AuthorizationContext:
    token = user.access_token
    issuer = (token.claims or {}).get("iss")
    return AuthorizationContext(
        client_id=token.client_id,
        issuer=str(issuer) if issuer is not None else None,
        subject=token.subject,
    )

That context is then stored when a session is created and compared on every session-bound request. In SSE, the transport now records _session_owners[session_id] for authenticated creators, rejects mismatched requestors with a 404-equivalent response, and removes owner mappings on disconnect. In streamable HTTP, the manager similarly tracks _session_owners, rejects mismatches before reusing an existing session, and cleans up owner state when sessions are torn down.

The tests added in PR #2719 are meaningful: they cover different client IDs, unauthenticated senders, same client with different subjects, same subject with different issuers, and matching principals. This directly exercises the intended authorization boundary.

Review

Pros

• The patch fixes the actual authorization boundary: session reuse now requires the same authenticated principal that created the session, rather than mere knowledge of a session ID.
• The comparison key is stronger than client_id alone. By incorporating subject and issuer when available, the patch avoids conflating multiple resource owners behind the same OAuth client.
• The implementation is transport-local and explicit. Both SSE and streamable HTTP now maintain session-owner maps and enforce checks at the point where session IDs are consumed.
• The response behavior intentionally returns 404 / “Session not found” on mismatch, reducing session enumeration signal.
• Cleanup logic was improved: owner mappings are removed when connections close, preventing stale authorization state from accumulating for the lifetime of the transport.
• Regression tests are well targeted and source-aligned, especially the matrix in ce267b6 that validates client, subject, and issuer matching semantics.

Cons

• The comparison intentionally “degrades to the remaining components” when token verifiers do not supply subject or issuer. That means deployments with sparse token metadata may still authorize at a coarser principal granularity, especially client_id-only.
• In SSE, owner state is only recorded for authenticated creators. The tests explicitly allow unauthenticated creator/unauthenticated sender reuse, which is consistent with the code but means the security property depends on authentication being enabled and correctly applied upstream.
• The patch appears focused on SSE and streamable HTTP. Based on the provided sources, the review cannot confirm whether every other session-bearing path in the SDK applies the same ownership invariant.
• The example auth changes are important operationally, but they are examples. Real deployments must ensure their token verifier populates subject and claims; otherwise the stronger matching semantics are not realized.

Verdict

Root-cause.

This is a substantive fix, not a superficial filter. The vulnerable condition was that session identifiers were treated as sufficient authority after initial authentication; the patch corrects that by binding session state to the authenticated principal and rechecking that binding on every subsequent session-targeted request. The added subject/iss propagation in 1abcca2 is necessary to make the principal comparison semantically correct, and the transport enforcement in ce267b6 closes the exploit path described by NVD. The main caveat is deployment quality: if integrators do not provide subject/issuer data in token verification, the protection remains correct in structure but weaker in identity precision.