The MCP Python SDK maintainers published GHSA-w4fh-qvv9-3v23 on 5 October 2026. Servers using the SDK’s bearer authentication could accept a token issued for a different service. The fix is in mcp 1.30.0 and 2.2.0, but it is off by default. A second advisory, CVE-2026-109527, fixed unbounded request bodies.
Key takeaways
- Token audience: affected 1.10.0 to 1.29.1 and 2.0.0 to 2.1.1.
- Upgrading alone does not turn the audience check on.
- Body size: fixed in 1.29.1 and 2.1.0, with a 4 MiB default limit.
- The audience advisory has no CVE ID; the body size one is CVE-2026-109527.
What is the token audience problem?
The advisory says the SDK’s server-side bearer authentication had no way to check that a token was issued for your server. Where one authorisation server issues tokens for several services, a valid token for another service was also accepted by your MCP server.
You are affected if your HTTP server uses AuthSettings with a token_verifier, your authorisation server also issues tokens for other services, and your TokenVerifier does not check the token’s aud claim itself. The advisory is rated medium and shows No known CVE.
Why does upgrading not fix it?
The advisory says: "Upgrading alone changes nothing." Versions 1.30.0 and 2.2.0 add a validate_token_resource setting that is off unless you set it. To turn the check on, make two changes together:
- Set validate_token_resource=True in AuthSettings, with resource_server_url set to the audience your authorisation server puts in tokens for your server.
- Return the token’s audience from verify_token() as AccessToken.resource.
With only the first change, every request gets a 401. 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().
What is CVE-2026-109527?
The second advisory, GHSA-fmmv-w9g8-j3gc, was published on 30 September 2026 and carries CVE-2026-109527. It is rated high. Affected servers read the whole HTTP request body into memory before checking its size. The advisory says one large request grew memory by two to three times the body size, so a client could take the server offline.
No credentials are needed against the OAuth endpoints, or against a server that does not require authentication. Upgrade to mcp 1.29.1 or 2.1.0. There is no fixed 2.0.x release. Every SDK HTTP endpoint then applies a 4 MiB default limit and answers 413. Servers using only the stdio transport are not affected.
Sorami’s view
This section is opinion. It is our reading of the SDK advisories, not a statement from the MCP maintainers.
Check the token audience on an MCP server as you would on any API. An MCP server is an API that an agent calls, and it should refuse tokens minted for anything else. If your authorisation server serves more than one product, assume this applies until you have tested it.
Test with a real token from a sibling service, not a forged one. That is the case the advisory describes, and it is quick to try in staging once the setting is on.
What to do now
- Find every MCP server using the Python SDK and its mcp version.
- Upgrade to 1.30.0 or 2.2.0, which also include the body limit.
- Set validate_token_resource=True and return AccessToken.resource together.
- Send a token issued for another service and confirm a 401.
- Cap request body size at the proxy if you cannot upgrade yet.
If your MCP server sits in front of real data and you want its authentication tested, see our API penetration testing, or contact us to discuss scope.
Related guides
- Self-replicating prompt injection in AI agents
- PCI SSC AI guidance and AI agent scope
- OWASP API Security Top 10 self-check
- Every Sorami article is in the guides index.
Sources
- MCP Python SDK, GHSA-w4fh-qvv9-3v23: Server bearer-token authentication accepts tokens issued for a different resource server (5 October 2026)
- MCP Python SDK, GHSA-fmmv-w9g8-j3gc / CVE-2026-109527: HTTP server transports and OAuth endpoints read request bodies with no size limit (30 September 2026)
Facts on this page were checked against these sources on 16 October 2026. We update the page when the source changes.