Open actionable advisories and recorded vendor fixes. This public package view has no inventory attached and cannot establish whether your deployment is affected. A vendor fix never resolves your finding; verify your installed version and the source guidance.
Open advisories
10 actionable advisories, newest first. Withdrawn advisories and news are excluded. Coverage is partial.
In affected versions, the SDK's server-side bearer authentication had no way to check that a token was issued for your server (its audience). Where one authorization server issues tokens for several services, a valid token for another service was also accepted by your MCP server. Am I affected? Yes, if your HTTP server uses the SDK's bearer authentication (`auth=AuthSettings(...)` with `token_verifier=`), its authorization server also issues tokens for other services, and your `TokenVerifier` does not check the token's audience (`aud`) itself. Affected versions: - `mcp` 1.10.0 through 1.29.1 - `mcp` 2.0.0 through 2.1.1 Fix Upgrade to: - 1.x: `mcp` 1.30.0 or later - 2.x: `mcp` 2.2.0 or later Upgrading alone changes nothing. The patched versions add a `validate_token_resource` setting that is off unless you set it. To turn the check on, make both of these changes together: 1. Set `validate_token_resource=True` in `AuthSettings`, with `resource_server_url` set to…
Recommended action: Upgrade to 2.2.0 or 1.30.0 by release line, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
In affected versions, the SDK's Streamable HTTP and SSE client transports followed HTTP redirects to any host. If the configured MCP endpoint answered with a redirect to a different origin: - custom headers set on the client (for example an `X-API-Key` credential) were sent to that origin, and - on a `307` or `308` redirect the request body was re-sent there too. The SDK's OAuth client providers followed redirects on their own discovery, registration and token requests in the same way. A lone `Authorization` bearer header was not exposed; the HTTP library already drops it on cross-origin redirects. Anyone able to make an endpoint you trust redirect elsewhere (a stale redirect to a lapsed domain, a misrouted proxy rule, redirect logic an attacker can influence) could capture that material. A server that is itself malicious gains nothing this way; it already receives your requests directly. Am I affected? Yes, if your code uses the SDK as an MCP client over HTTP through…
Recommended action: Upgrade to 2.2.0 or 1.30.0 by release line, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
In affected versions, when a connected MCP server declared an `outputSchema` for a tool, the SDK's client validated each `call_tool` result with `jsonschema`'s default resolver, which fetches any `$ref` it cannot resolve locally by opening the URL. A server could therefore put an `http://`, `https://` or `file://` reference in a tool's output schema and make the client: - request that URL, or read that local file, from the client's own network position on every call of the tool (the content was used only as a schema and never sent back to the server), and - stall: the fetch ran synchronously on the event loop with no timeout, so a target that accepted the connection and then went quiet froze every session in the process for as long as it held the connection. Am I affected? Yes, if your application uses the SDK as an MCP client (`ClientSession` over any transport, `ClientSessionGroup`, or the 2.x `Client`) and calls tools on servers you do not fully control. There was…
Recommended action: Upgrade to 2.2.0 or 1.30.0 by release line, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
In affected versions, a Streamable HTTP server in stateful mode (the default) never reclaimed session state: - sessions did not expire; - a client DELETE ended the session but left its entry registered; - a session whose first request was refused stayed registered with a running task. Each session also kept its parsed initialize parameters, and the number of sessions was unlimited. A client that could reach the endpoint could grow server memory without bound using ordinary short requests; only a restart reclaimed it. Am I affected? Yes, if you serve MCP over Streamable HTTP in stateful mode and clients you do not fully trust can reach the endpoint. Stateful mode is the default for: - FastMCP (1.x) - MCPServer and Server.streamablehttpapp() (2.x) - StreamableHTTPSessionManager Affected versions: 1.8.0 through 1.29.1, and 2.0.0 through 2.1.1. Not affected: - servers on 1.12.0 or later passing statelesshttp=True (no sessions are kept) - servers using only the stdio or SSE…
Recommended action: Upgrade to 2.2.0 or 1.30.0 by release line, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
In affected versions, the deprecated WebSocket server transport (mcp.server.websocket.websocketserver) accepted the WebSocket handshake without applying any Host or Origin header validation. The TransportSecuritySettings mechanism that the SSE and Streamable HTTP transports use for this purpose was not wired into the WebSocket transport, so there was no SDK-level way to restrict which origins could connect. Am I affected? Only if a developer's application server exposes mcp.server.websocket.websocketserver. This transport has never been part of the MCP specification, is marked deprecated, and is not reachable through FastMCP — a developer must have wired it into an ASGI application themselves. Servers using stdio, SSE, or Streamable HTTP are not affected by this advisory. Details websocketserver() constructed a Starlette WebSocket and called accept(subprotocol="mcp") immediately, with no inspection of the connection's headers. By contrast, SseServerTransport and…
Recommended action: Upgrade to 1.28.1 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
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 sessionid query parameter for SSE (mcp.server.sse.SseServerTransport) and the Mcp-Session-Id header for Streamable HTTP (mcp.server.streamablehttpmanager.StreamableHTTPSessionManager). Once the lookup succeeded, the request was handled on that session without…
Recommended action: Upgrade to 1.27.2 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
In affected versions, the default request handlers installed by the experimental tasks feature (server.experimental.enabletasks()) did not check which session created a task before acting on it. On a server with more than one connected client, any client could observe, read results from, and cancel tasks belonging to other clients. Am I affected? Only if the developer's application server calls server.experimental.enabletasks(). If grep -r enabletasks over their codebase finds nothing, the application is not affected. Details When tasks support is enabled on the low-level server, default handlers are registered for tasks/list, tasks/get, tasks/result, and tasks/cancel. These handlers operated on the task identifier alone and kept no record of the session that created each task. Because tasks/list returned every task in the store, a connected client did not need to know any identifiers in advance: it could enumerate all tasks, read any task's status and result via tasks/get…
Recommended action: Upgrade to 1.27.2 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
The Model Context Protocol (MCP) Python SDK does not enable DNS rebinding protection by default for HTTP-based servers. When an HTTP-based MCP server is run on localhost without authentication using FastMCP with streamable HTTP or SSE transport, and has not configured TransportSecuritySettings, a malicious website could exploit DNS rebinding to bypass same-origin policy restrictions and send requests to the local MCP server. This could allow an attacker to invoke tools or access resources exposed by the MCP server on behalf of the user in those limited circumstances. Note that running HTTP-based MCP servers locally without authentication is not recommended per MCP security best practices. This issue does not affect servers using stdio transport. Servers created via FastMCP() now have DNS rebinding protection enabled by default when the host parameter is 127.0.0.1 or localhost. Users are advised to update to version 1.23.0 to receive this automatic protection. Users with…
Recommended action: Upgrade to 1.23.0 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
A validation error in the MCP SDK can cause an unhandled exception when processing malformed requests, resulting in service unavailability (500 errors) until manually restarted. Impact may vary depending on the deployment conditions, and presence of infrastructure-level resilience measures. Thank you to Rich Harang for reporting this issue.
Recommended action: Upgrade to 1.9.4 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
If a client deliberately triggers an exception after establishing a streamable HTTP session, this can lead to an uncaught ClosedResourceError on the server side, causing the server to crash and requiring a restart to restore service. Impact may vary depending on the deployment conditions, and presence of infrastructure-level resilience measures. Thank you to Rich Harang for reporting this issue.
Recommended action: Upgrade to 1.10.0 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.