The official MCP Python SDK has three medium-severity advisories, all fixed in mcp 1.30.0 and 2.2.0. They cover a server that accepts bearer tokens issued for a different service (CVE-2026-116684), HTTP clients that follow redirects to another origin with custom headers (CVE-2026-116685), and a client that fetches server-chosen URLs while validating tool results (CVE-2026-116686). If you build MCP servers or clients in Python, including agent harnesses and internal tools, check your mcp version today.
GitHub reviewed all three on October 27, 2026. The advisories were first published in the modelcontextprotocol/python-sdk repository on September 28, October 2 and October 5. None of them describes exploitation in the wild.
| Question | Short answer |
|---|---|
| Am I affected? | If you use mcp below 1.30.0 (1.x) or below 2.2.0 (2.x), in the roles described below |
| Is there a fix? | Yes: mcp 1.30.0 or 2.2.0 |
| Is upgrading enough? | For redirects and $ref, yes. For the token audience check, no: it is off until you turn it on |
| Severity | CVSS 6.8, 5.9 and 6.5 (all moderate) |
| Does data leave my machine? | Possibly credentials in the redirect case, if an endpoint you trust redirects elsewhere |
| Any exploitation reported? | Not in the advisories |
Who is affected
The three issues sit in different parts of the SDK, so the first question is which part you use. The advisories name the affected ranges precisely.
| Advisory | Role | Affected | Fixed |
|---|---|---|---|
| CVE-2026-116684 (GHSA-w4fh-qvv9-3v23) | Server using bearer auth | 1.10.0 – 1.29.1, 2.0.0 – 2.1.1 | 1.30.0, 2.2.0 |
| CVE-2026-116685 (GHSA-5h93-6whr-6q8j) | HTTP or SSE client | 1.8.0 – 1.29.1, 2.0.0 – 2.1.1 | 1.30.0, 2.2.0 |
| CVE-2026-116686 (GHSA-rwrf-2pqf-9j8j) | Any client calling tools | 1.10.0 – 1.29.1, 2.0.0 – 2.1.1 | 1.30.0, 2.2.0 |
The Beam CVE database does not yet have pages for these three, so the advisories above are the reference.
Advisory 1: bearer tokens meant for another service (CVE-2026-116684)
What happened. The SDK's server-side bearer authentication had no way to check that a token was issued for your server, meaning its audience. If one authorization server issues tokens for several services, a valid token for service B was also accepted by your MCP server A.
Who is exposed. The advisory says you are affected if all three are true: your HTTP server uses auth=AuthSettings(...) with a token_verifier=; the authorization server also issues tokens for other services; and your TokenVerifier does not check the token's audience (aud) itself. The CVSS vector is AV:N/AC:H/PR:L, with high confidentiality and integrity impact. The weakness is CWE-863, incorrect authorization.
In plain terms: someone who holds a legitimate token for a neighbouring service on the same identity provider may be able to call your MCP tools with it. For an MCP server that exposes file access, tickets or deployment actions to agents, that is a confused-deputy problem. The agent or user did not intend to authorize your server, but the server accepts the token anyway.
The fix is a setting. This is the one advisory where an upgrade alone changes nothing. The patched versions add a validate_token_resource option that is off unless you set it. Per the advisory, turn the check on with two changes made together:
- Set
validate_token_resource=TrueinAuthSettings, withresource_server_urlset to the audience your authorization server puts in tokens for your server. - Return the token's audience from
verify_token()asAccessToken.resource.
With both, a token for another service gets a 401. With only the first change, every request gets a 401, so test before you ship. If your TokenVerifier already checks the audience, set validate_token_resource=False to silence the deprecation warning. The advisory says the setting will default to True in 3.0.
If you cannot upgrade, reject any token whose aud does not include your server inside verify_token(). The advisory says this closes the issue on every version.
Advisory 2: cross-origin redirects carrying headers and bodies (CVE-2026-116685)
What happened. The 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, two things went along:
- custom headers set on the client, for example an
X-API-Keycredential, 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 the same way on their discovery, registration and token requests. A lone Authorization bearer header was not exposed, since the HTTP library already drops it on cross-origin redirects.
The attack condition. The advisory is careful here. Someone has to be able to make an endpoint you trust redirect elsewhere: a stale redirect to a lapsed domain, a misrouted proxy rule, or redirect logic an attacker can influence. A server that is itself malicious gains nothing from this, because it already receives your requests directly. That is why the vector carries high attack complexity (AV:N/AC:H/PR:N, confidentiality high). The weakness is CWE-200, exposure of sensitive information.
Who is exposed. Code that uses the SDK as an HTTP client through streamable_http_client (on 2.x also Client given an http:// or https:// URL), streamablehttp_client, sse_client, ClientSessionGroup with HTTP server parameters, or the internal create_mcp_http_client helper. That includes an HTTP client you passed in yourself with follow_redirects=True. MCP servers, stdio clients, and clients you supplied with follow_redirects left at its default of False are not affected.
The fix. Upgrade; the advisory says no code changes are needed. Transports and the OAuth providers' own requests now follow a redirect only if it stays on the endpoint's origin (same scheme, host and port, or an HTTP-to-HTTPS upgrade on the same host) and keeps the request method. Any other redirect fails with an error naming the target (MCPError on 2.x, httpx.HTTPStatusError on 1.x).
One behaviour change to plan for: if your client currently reaches its server through a redirect to another host, it will stop connecting after the upgrade. Set the endpoint URL to the redirect's target. The advisory also documents an unsupported subclass that restores the old behaviour, and tells you to prefer fixing the endpoint URL instead.
Before upgrading, you can pass your own HTTP client with follow_redirects left at False: http_client= on streamable_http_client, or httpx_client_factory= on sse_client and streamablehttp_client. ClientSessionGroup has no such parameter. If a client may already have followed a redirect to a host you do not control, rotate the credentials it carried.
Advisory 3: the client that fetched server-chosen $ref URLs (CVE-2026-116686)
What happened. When a connected MCP server declares an outputSchema for a tool, the SDK client validates each call_tool result against it using jsonschema's default resolver. That resolver 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 advisory notes the content was used only as a schema and never sent back to the server); and
- stall, because 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.
The weakness is CWE-918, server-side request forgery, and the CVSS vector AV:N/AC:L/PR:N/UI:R puts the impact on availability (high), with no confidentiality or integrity impact scored.
Why it matters for agents. The "server" here is any MCP server a user connects. Adding an MCP server to an agent is a trust decision, but it is rarely treated as permission for that server to make your machine probe internal addresses such as cloud metadata endpoints or read local files. The advisory scores the confidentiality impact as none because the content is not returned, yet the request itself still originates from inside your network, which can be enough to trigger side effects or map internal hosts. That second point is our reading; the advisory rates only availability.
Who is exposed. Applications using ClientSession over any transport, ClientSessionGroup, or the 2.x Client that call tools on servers they do not fully control. There was no setting to turn the validation off. Applications that only build servers are not affected.
The fix. Upgrade. 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 like #/$defs/... work as before. As a partial stopgap before 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 #.
What this means if you run AI coding agents
Most people who run Claude Code or Codex do not import this SDK directly. But agent harnesses, internal MCP servers, and Python tools that wrap MCP clients often do, and many MCP servers published for agents are written with the Python SDK. Work through this list:
- Find the version. Run
pip show mcpin each environment, orpip list | grep -i mcp. For projects with lockfiles, checkuv.lock,poetry.lockorrequirements.txt. - Upgrade to
mcp1.30.0 or later on 1.x, or 2.2.0 or later on 2.x. - If you run an MCP server with bearer auth, make the two audience changes above and test that a token minted for a different service now returns 401.
- If you run an MCP client, search your logs for redirect errors after upgrading. A client that suddenly fails with
MCPErrororHTTPStatusErrornaming another host was relying on a cross-origin redirect; fix the endpoint URL. - Check for credentials that may have travelled. If an endpoint you trust ever redirected somewhere you do not control while your client carried an
X-API-Keyor similar header, rotate that key. - Look at who your agents connect to. The
$refissue needs a server that declares an output schema with an external reference. Review which MCP servers your tooling connects to, as covered in reviewing MCP servers before you connect an agent.
To tell if you were hit, look for outbound requests from your client process to unexpected hosts or file:// reads around tool calls, unexplained 401-free calls with tokens meant for other services, and requests to your API from unfamiliar sources carrying your key. The advisories do not describe any in-the-wild exploitation, so these are things to look for, not known indicators.
What Beam can and cannot do here
Beam does not read the code inside your MCP client or server, so it will not flag any of these three flaws as such. Two documented features still help. beam cve check . reads lockfiles, sends only package names and versions, and matches them against AgentBeam's CVE database; whether a given advisory is covered depends on that database, so confirm in the CVE database. See Check dependencies against known CVEs in CI. And beam scan .mcp.json --mcp checks an MCP config for risky patterns and unpinned versions without launching the servers, which helps you notice unfamiliar servers before an agent connects. That scan is heuristic: it cannot judge a server's output schema or runtime behaviour. For what Beam watches at runtime, see what Beam watches.
Why this keeps happening in MCP SDKs
These three advisories follow the same pattern as the OAuth credential leak in the TypeScript SDK and the four further TypeScript SDK advisories fixed in 1.32.0: the protocol puts a lot of trust decisions in the client library, such as where to send credentials, which server a token is for, and what a server's metadata may make the client fetch. When the library defaults to permissive behaviour, every embedding application inherits the gap. The Python fixes tighten defaults (same-origin redirects only, no external $ref) in two of three cases, and make the third an explicit opt-in that will become the default in 3.0.
The request body limits advisory covered in MCP TypeScript SDK request body and batch limits is a related reminder that servers and clients must treat anything from the other side of the connection as untrusted input. For the broader transport angle, see AI agent web and transport security and the practical MCP security guide.
Frequently asked questions
Which MCP Python SDK versions are affected?
Depending on the advisory, mcp 1.8.0 or 1.10.0 through 1.29.1, and 2.0.0 through 2.1.1. The fixes are in mcp 1.30.0 (1.x) and 2.2.0 (2.x).
Is upgrading enough?
For the redirect and $ref issues, yes, no code changes are needed. For the token audience issue, no: you must also set validate_token_resource=True in AuthSettings and return the audience from verify_token() as AccessToken.resource.
Are MCP servers and stdio clients affected?
It depends on the advisory. The redirect issue affects HTTP clients only, not servers or stdio clients. The $ref issue affects clients only. The audience issue affects servers that use the SDK bearer authentication.
What can a malicious MCP server do with the $ref issue?
Put an http, https or file reference in a tool output schema so the client requests that URL or reads that local file on every call, or stalls the whole process by holding the connection open. The fetched content was used only as a schema and not sent back.
What if I cannot upgrade yet?
Reject tokens whose aud does not include your server inside verify_token(), pass your own HTTP client with follow_redirects left at False, and call tools only on servers you trust.
Can Beam detect these vulnerabilities?
Not by reading your code. Beam scans MCP config files heuristically, but for dependencies use pip show mcp, or beam cve check to match lockfile versions against the AgentBeam CVE database.
Related reading
- MCP security: review servers before connecting your agent
- MCP security practical guide
- MCP TypeScript SDK OAuth flaw (CVE-2026-104850)
- Four more MCP TypeScript SDK advisories fixed in 1.32.0
- AI agent web and transport security
- Advisories: GHSA-w4fh-qvv9-3v23, GHSA-5h93-6whr-6q8j, GHSA-rwrf-2pqf-9j8j; releases v1.30.0 and v2.2.0
Versions and advisory details are accurate as of October 27, 2026, from the GitHub advisories. Check the advisories and release notes for later changes.