Published:
Ten security advisories for the official MCP SDKs: which update you need now (and which does nothing without configuration)
In short: between 28 September and 5 October 2026 the MCP project published ten security advisories for its official SDKs: six for Python (mcp) and four for TypeScript. The most serious (CVSS 7.5): a malicious MCP server could make a client send its OAuth secrets to the attacker. Python 1.30.0/2.2.0 and TypeScript 1.32.0/2.3.0 or later are safe — but two fixes still have to be switched on.
The Model Context Protocol SDKs are the libraries that a large share of MCP servers and clients are built on, including in-house integrations. A flaw in the SDK is therefore not a flaw in one product but in everything built on top of it. What stands out in this batch is that most fixes shipped before the advisories appeared. Python 1.30.0 and 2.2.0 have been on PyPI since 7 September; the TypeScript fixes landed on 28 September and 2 October. Anyone who has not upgraded since is running known vulnerabilities.
What vulnerabilities were found?
The ten advisories fall into four groups.
- OAuth secrets sent to the wrong party (Python GHSA-qx49-fqc8-xw99, TypeScript CVE-2026-104850; both CVSS 7.5). The client did not always verify that the authorization server named by an MCP server was the one its credentials belonged to. A malicious or compromised MCP server could thereby receive the
client_secret, authorization codes, PKCE verifiers and, in TypeScript, stored refresh tokens. Security firm Cycode, which documented the Python variant, shows that the victim sees the genuine sign-in page of their own provider throughout. Affected: Python 1.9.1–1.29.1 and 2.0.0–2.1.1; TypeScript@modelcontextprotocol/sdk1.12.0–1.30.1. - Tokens for another service accepted (both SDKs, CVSS 6.8). Server-side bearer authentication had no way to check that a token was issued for that particular server. If your identity provider runs one authorization server for several services, your MCP server also accepted tokens meant for another application.
- Data leaking through redirects (both SDKs, CVSS 5.9 and 6.5). HTTP clients followed redirects to any origin and forwarded custom headers such as an
X-API-Key, plus the request body on 307/308 redirects. - Availability and isolation. In Python, a Streamable HTTP server in the default stateful mode never reclaimed sessions (CVE-2026-59951, CVSS 7.5), and HTTP endpoints read request bodies with no size limit (CVSS 7.5) — both ways to take a server down without credentials. A Python client also fetched URLs or local files that a server referenced in an output schema (CVSS 6.5). In TypeScript, clients sharing one
InMemoryTaskStorecould read and cancel each other's experimental tasks (CVSS 8.6); that feature was already replaced in the 28 July specification.
Why is upgrading not enough for some fixes?
This is the point most coverage glosses over. The advisories say it verbatim: "Upgrading alone changes nothing." The audience check is off by default. In Python you set validate_token_resource=True in AuthSettings and return the audience from verify_token(); in TypeScript you pass expectedResource to requireBearerAuth(). The same applies in Python to machine-to-machine clients (ClientCredentialsOAuthProvider and PrivateKeyJWTOAuthProvider): without the new issuer= parameter they still follow whichever authorization server the MCP server points to. On 1.30.0 that only raises a DeprecationWarning, which Python hides by default. Both checks become mandatory in version 3.0.
The project also advises clearing stored OAuth client registrations once after upgrading, so they are re-bound to the correct authorization server. And if a client may have connected to an untrusted server, rotate the client secret and revoke its tokens.
Our advice
(1) Inventory where the MCP SDKs run in your organisation: your own servers, internal agents, and vendor tools that bundle the SDK — ask vendors which version they ship. (2) Upgrade to Python mcp ≥ 1.30.0 or ≥ 2.2.0 and TypeScript @modelcontextprotocol/sdk ≥ 1.32.0, or the 2.x packages ≥ 2.3.0. (3) Then switch on the two opt-in checks: audience validation on your HTTP servers and issuer= on machine-to-machine clients. Put this in your deployment checklist, not just in this patch round. (4) Let agents holding OAuth credentials connect only to MCP servers you trust; this batch shows a malicious server can do far more than return bad answers. More in MCP security and, if you build your own, build an MCP server.
What does this say about MCP's maturity?
Our analysis: ten advisories in eight days sounds alarming, but the pattern is more reassuring than worrying. The flaws were reported by outside researchers, fixed in a coordinated way, patched in both SDKs in parallel and documented with a clear "am I affected?" section per advisory. That is how a mature open-source project should operate. The flip side is that a good share of the fixes are opt-in. That protects existing deployments from breaking, but puts the responsibility on the operator. Organisations using MCP in production should treat SDK updates like any other security maintenance: with an owner, a fixed cadence and a check that the protection is actually enabled. We previously covered the authorization tightening in the July specification; these advisories are its practical follow-up.
Sources
- GHSA-qx49-fqc8-xw99 — OAuth client could send credentials to an authorization server chosen by the MCP server (Python SDK, 28 September 2026)
- GHSA-84m7-p3x7-pcfv / CVE-2026-59951 — Streamable HTTP sessions never reclaimed (Python SDK, 30 September 2026)
- GHSA-fmmv-w9g8-j3gc — request bodies read with no size limit (Python SDK)
- GHSA-rwrf-2pqf-9j8j — server-chosen $ref URLs fetched during validation (Python SDK)
- GHSA-5h93-6whr-6q8j — cross-origin redirects (Python SDK, 2 October 2026)
- GHSA-w4fh-qvv9-3v23 — tokens for a different resource server accepted (Python SDK, 5 October 2026)
- GHSA-6qxp-vccf-f47h / CVE-2026-104850 — OAuth credentials to MCP-chosen authorization server (TypeScript SDK, 30 September 2026)
- GHSA-rvq5-wwqv-78pq — bearer auth accepted tokens for another service (TypeScript SDK)
- GHSA-6prh-2h8m-c8cw — cross-origin redirects (TypeScript SDK)
- GHSA-22jm-h49p-29qw — experimental tasks not tied to session (TypeScript SDK)
- mcp on PyPI — release history (1.30.0 and 2.2.0: 7 September 2026)
- MCP Python SDK OAuth account takeover — Cycode (28 September 2026)
- MCP security digest October 2026 — Adversa AI (8 October 2026)
Frequently asked questions
Which MCP SDK version should I upgrade to?
Python: mcp 1.30.0 (1.x) or 2.2.0 (2.x) or later; the latest is 2.3.0. TypeScript: @modelcontextprotocol/sdk 1.32.0 or later, or 2.3.0 or later for the 2.x packages @modelcontextprotocol/client and @modelcontextprotocol/server. That covers all ten advisories.
Am I affected if I only build an MCP server?
Partly. The OAuth, redirect and $ref flaws are client-side. Servers running over HTTP are affected by the session and memory issues (Python) and by the missing audience check on bearer tokens (both SDKs). Servers that only run locally over stdio fall outside all ten advisories.
Why is upgrading sometimes not enough?
For two fixes the new protection is off by default so existing deployments do not break: the server-side token audience check, and in Python pinning the correct authorization server with issuer= on machine-to-machine clients. You have to switch these on yourself; according to the advisories they become the default in version 3.0.
Last updated: