GHSA-rwrf-2pqf-9j8j: SSRF

Published Oct 27, 2026
·
Updated

Summary In affected versions, when a connected MCP server declared an outputSchema for a tool, the SDK's client validated each calltool 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 #.

Affected Software

2 affected componentsFixes available
pip/mcp>=1.10.0<1.30.0
1.30.0
pip/mcp>=2.0.0<2.2.0
2.2.0

Remediation

Recommended actions to resolve this vulnerability, in priority order.

  1. Upgrade

    Upgrade pip/mcp to a version that resolves this vulnerability.

    Fixed in 1.30.0
  2. Upgrade

    Upgrade pip/mcp to a version that resolves this vulnerability.

    Fixed in 2.2.0
  3. Upgrade

    Upgrade mcp to a version that resolves this vulnerability.

    Fixed in 1.30.0
  4. Upgrade

    Upgrade mcp to a version that resolves this vulnerability.

    Fixed in 2.2.0
  5. Compensating control

    Until upgrading, call tools only on servers you trust and skip tools whose outputSchema contains an $id, or a $ref or $dynamicRef that does not start with #.

Event History

Oct 27, 2026
Advisory Published
via GitHub·09:05 PM
Data Sourced
via GitHub·09:05 PM
DescriptionSeverityWeaknessAffected Software

Frequently Asked Questions

1

Which deployments need remediation priority?

Applications using the SDK as an MCP client through ClientSession over any transport, ClientSessionGroup, or the 2.x Client are affected when they call tools on MCP servers they do not fully control. Applications that only build MCP servers are not affected.

2

What does an attacker need to control to trigger this?

The attacker needs to operate or control a connected MCP server that can declare an outputSchema for a tool. The client must then call that tool for the schema reference to be fetched or read.

3

Can validation be disabled as a temporary workaround?

No. There was no setting to turn this validation off in the affected versions.

4

How can I determine whether a deployed application is affected?

Check whether it uses pip/mcp versions 1.10.0 through 1.29.1 or 2.0.0 through 2.1.1 as an MCP client, and whether it calls tools from servers outside its full control. A client can be affected over any transport.

5

What operational effects should be investigated?

A malicious schema reference can cause the client to make HTTP or HTTPS requests from its own network position or read local files through file:// references. It can also freeze all sessions in the process because the synchronous fetch has no timeout when a target accepts a connection and does not respond.

Contact

SecAlerts Pty Ltd.
132 Wickham Terrace
Fortitude Valley,
QLD 4006, Australia
info@secalerts.co
By using SecAlerts services, you agree to our services end-user license agreement. This website is safeguarded by reCAPTCHA and governed by the Google Privacy Policy and Terms of Service. All names, logos, and brands of products are owned by their respective owners, and any usage of these names, logos, and brands for identification purposes only does not imply endorsement. If you possess any content that requires removal, please get in touch with us.
© 2026 SecAlerts Pty Ltd.
ABN: 70 645 966 203, ACN: 645 966 203