Between 28 September and 15 October 2026, the official Model Context Protocol SDKs published 13 security advisories: six for the Python SDK and seven for the TypeScript SDK. Most are fixed by upgrading. One is not.
If your MCP server uses the SDK's bearer-token authentication, it may accept a token that was issued for a different service. The patched SDKs add a check for this, but the check is off by default in both SDKs. In the Python advisory's words, "Upgrading alone changes nothing."
If you upgraded your MCP SDK after the October advisories and use its bearer authentication, check two things: that you pass your server's audience to the SDK, and that your token verifier returns the token's audience. Without both, a token minted for another service on the same authorization server still gets in.
What the Bug Is
An OAuth access token says which service it's for in its audience claim (aud). When one authorization server issues tokens for several services (your MCP server, your REST API, an internal dashboard), each token should only work at the service it was issued for.
In affected versions, the SDKs' server-side bearer authentication had no way to check that. A valid token for your REST API was also accepted by your MCP server. Anyone who could get a token for one service could use it at another.
You are affected if all three are true:
- Your HTTP MCP server uses the SDK's bearer authentication:
AuthSettings(...)withtoken_verifier=in Python, orrequireBearerAuth()/verifyBearerToken()in TypeScript. - Its authorization server also issues tokens for other services.
- Your token verifier doesn't check the token's audience itself.
The Fix, Step by Step
Python (mcp)
Advisory GHSA-w4fh-qvv9-3v23, published 5 October.
- Upgrade to
mcp1.30.0 or later (1.x), or 2.2.0 or later (2.x). - In
AuthSettings, setvalidate_token_resource=Trueand setresource_server_urlto the audience your authorization server puts in tokens for your server. - Return the token's audience from
verify_token()asAccessToken.resource.
Make steps 2 and 3 together. With only step 2, every request gets a 401. If your verifier already checks the audience, set validate_token_resource=False to silence the deprecation warning. The setting becomes True by default in SDK 3.0.
TypeScript (@modelcontextprotocol/*)
Advisory GHSA-rvq5-wwqv-78pq, published 5 October.
- Upgrade to
@modelcontextprotocol/sdk1.32.0 or later (1.x). On 2.x:@modelcontextprotocol/server2.3.0 or later, plus@modelcontextprotocol/express2.0.2 if you use it, and@modelcontextprotocol/server-legacy2.3.1. - Pass your server's audience:
requireBearerAuth({ verifier, expectedResource: new URL('https://mcp.example.com/mcp') }). - Return the token's audience from
verifyAccessToken()asAuthInfo.resource, also aURL.
Again, steps 2 and 3 go together.
Can't upgrade yet? Reject any token whose aud doesn't include your server inside your own verifier. Both advisories say that closes the issue on every version.
The Other Advisories
Most of the rest are fixed by upgrading alone. The TypeScript 1.x line needs 1.32.0 to cover all of them: 1.31.0 fixed only the first auth issue below.
| Area | Python | TypeScript |
|---|---|---|
| OAuth client could send credentials to an authorization server the MCP server chose | GHSA-qx49-fqc8-xw99 (high) | GHSA-6qxp-vccf-f47h (high) |
| Server accepts tokens issued for another service (opt-in fix, above) | GHSA-w4fh-qvv9-3v23 | GHSA-rvq5-wwqv-78pq |
| HTTP client transports followed cross-origin redirects, re-sending headers and bodies | GHSA-5h93-6whr-6q8j | GHSA-6prh-2h8m-c8cw |
| Unbounded request bodies or batches; memory exhaustion | GHSA-fmmv-w9g8-j3gc (high) | GHSA-f897-62hf-6gxq, GHSA-46jr-4wx8-v453 (high) |
| Sessions and isolation | GHSA-84m7-p3x7-pcfv: sessions never reclaimed by default (high) | GHSA-22jm-h49p-29qw: tasks not tied to their session (high); GHSA-jm63-cq47-j5jp: shared instances delivered one client's messages to another (high) |
Client fetched server-chosen $ref URLs while validating tool results | GHSA-rwrf-2pqf-9j8j | — |
Patched versions: Python mcp 1.30.0 (1.x) or 2.2.0 (2.x). TypeScript @modelcontextprotocol/sdk 1.32.0 (1.x); on 2.x, server and client 2.3.0, express 2.0.2 and server-legacy 2.3.1.
Why We Can't Score This From Outside
Our scanner checks what an MCP server shows a client that has no credentials. In our study of 3,000 remote MCP endpoints, 29.3% required authentication, and 82.7% of those gave a challenge an agent can follow. That's the front door labelled correctly.
Whether the server then checks a token's audience happens on the server, after a token arrives. A scan without a token can't see it, so the Agent Readiness Score doesn't claim to measure it. It's a question for a code or configuration review.
The new ARS 3.3 check mcp-auth-scope-challenge covers a related, visible piece: whether a server's challenge names the scope a client should request (SEP-835).
What We Did
Our own MCP servers don't use bearer authentication: the hosted Glintbase server is open and anonymous. So the audience bug doesn't affect them. We still moved the scanner app and the @glintbase/mcp package to @modelcontextprotocol/sdk 1.32.1 in our 3.5.0 release, which covers the other TypeScript advisories that applied to us.
Sources
- Python SDK advisories: github.com/modelcontextprotocol/python-sdk/security/advisories
- TypeScript SDK advisories: github.com/modelcontextprotocol/typescript-sdk/security/advisories
Advisory details as published on GitHub and read on 22–23 October 2026. Disclosure: Glintbase sells agent-readiness scoring.
Run a Free AI Readiness Audit
Identify broken parameter signatures, missing Model Context Protocol schemas, and sitemap issues in your developer documentation.
