GHSA-rwrf-2pqf-9j8j

Summary

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 no setting that turned the validation off.

Affected versions: 1.10.0 through 1.29.1, and 2.0.0 through 2.1.1.

Not affected: applications that only build servers. If nothing in your code uses ClientSession, ClientSessionGroup or the 2.x Client class, you are not affected.

Fix

Upgrade to mcp 1.30.0 (1.x) or 2.2.0 (2.x) or later. The client now resolves references only within the schema document the server sent (plus the standard JSON Schema metaschemas), so result validation performs no network or file access. A tool whose output schema points outside its own document fails at call time with RuntimeError (Invalid schema for tool ...); in-document references such as #/$defs/... work as before.

Until you can upgrade, call tools only on servers you trust. As a partial stopgap, skip tools whose outputSchema contains an $id, or a $ref / $dynamicRef that does not start with #.