Skip to content
AI Security Wire

Published

- 4 min read

By

MCP Python SDK Advisories: Audience, Redirect, $ref Flaws (CVE-2026-116684/5/6)

img of MCP Python SDK Advisories: Audience, Redirect, $ref Flaws (CVE-2026-116684/5/6)

The maintainers of the MCP Python SDK published three advisories on October 27, 2026, all rated medium by GitHub. None is a headline remote code execution bug. Our view: each one is a trust-boundary mistake of the kind that tends to matter once an MCP deployment grows past a single laptop. They are tracked as CVE-2026-116684, CVE-2026-116685 and CVE-2026-116686. Some of this is a sequel: we covered a separate SDK OAuth issue on October 23.

Bearer tokens with no audience check (CVE-2026-116684)

GHSA-w4fh-qvv9-3v23 (CWE-863, CVSS 3.1 6.8) says the SDK’s server-side bearer authentication had no way to check that a token was issued for your server. If one authorization server issues tokens for several services, a valid token for another service was also accepted by your MCP server. It matters only if you use AuthSettings with a token_verifier, your authorization server also issues tokens for other services, and your verifier does not check aud itself.

The catch is in the fix. Per the advisory, the patched versions add a validate_token_resource setting that is off unless you set it. You need to set it to True, set resource_server_url to your audience, and 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.

Redirects that carry credentials (CVE-2026-116685)

GHSA-5h93-6whr-6q8j (CWE-200, 5.9) covers the Streamable HTTP and SSE client transports, which followed redirects to any host. Custom headers such as an X-API-Key went along, and on a 307 or 308 so did the request body. A lone Authorization bearer header was not exposed, because the HTTP library already drops it cross-origin. The SDK’s OAuth client providers also followed redirects on discovery, registration and token requests, so OAuth token requests were included. Stdio clients and servers are not affected. A malicious server gains nothing here, since it already sees your requests. The risk is an endpoint you trust redirecting somewhere you do not, for example a stale redirect to a lapsed domain.

The fix follows redirects only within the same origin. The advisory warns that clients that reach their server through a cross-host redirect will stop connecting after the upgrade, and tells you to set the endpoint URL to the redirect target. Until you upgrade, the advisory’s workaround is to supply your own HTTP client with follow_redirects=False.

Output schemas that fetch URLs (CVE-2026-116686)

GHSA-rwrf-2pqf-9j8j (CWE-918, 6.5) concerns clients. When a server declared an outputSchema, the client validated tool results with a resolver that fetched any unresolved $ref by opening the URL, whether the scheme was HTTP, HTTPS or file. The fetch ran from the client’s network position on every call, and it blocked the event loop with no timeout, so a target that went quiet could freeze every session in the process. The content was used only as a schema and never sent back to the server.

Servers are not affected. If your application is a client calling tools on servers you do not fully control, it is.

Timing and status

PyPI lists mcp 1.30.0 and 2.2.0 as uploaded on September 7, 2026, which is 50 days before the advisories (that is a fact about upload dates; the advisories do not say whether the fixes were announced earlier); the current release is 2.3.0. The advisories name 1.30.0 and 2.2.0 as the first patched versions. As of October 30, NVD shows the records as Awaiting Analysis (116684) and Deferred (116685, 116686), with GitHub’s scores only. CISA-ADP SSVC data is attached to CVE-2026-116686 only (dated October 28: exploitation none, automatable no, technical impact partial). None is in the CISA KEV feed released October 29.

What to do

  1. Upgrade mcp to 2.2.0 or later (1.30.0 or later on 1.x).
  2. If you run an MCP server with bearer auth, turn on audience validation as described above, or reject tokens whose aud lacks your server inside verify_token().
  3. If your client may have followed a redirect to a host you do not control, rotate the credentials it carried.
  4. Until you upgrade clients, only call tools on servers you trust.

References

Frequently Asked Questions

Which MCP Python SDK versions are affected and what is the fix?
Per the three GitHub advisories, the pip package mcp is affected in 1.x and 2.x. The audience-check flaw (CVE-2026-116684) covers 1.10.0 through 1.29.1 and 2.0.0 through 2.1.1, as does the $ref flaw (CVE-2026-116686). The redirect flaw (CVE-2026-116685) starts earlier, at 1.8.0. Fixed releases are 1.30.0 and 2.2.0. For the audience flaw, upgrading alone changes nothing: you must set validate_token_resource=True and return the audience from verify_token().
Is this being exploited?
No evidence of exploitation found as of October 30, 2026 in the CISA KEV JSON feed (released 2026-10-29T19:09Z) or in the three GitHub advisory texts, which do not mention exploitation. That covers only those sources; we did not search vendor telemetry or threat reports. Treat it as unknown.
How severe are these and who scored them?
GitHub rates all three medium: 6.8 (CVE-2026-116684), 5.9 (CVE-2026-116685) and 6.5 (CVE-2026-116686). In the NVD API on October 30, those are GitHub's scores, which NVD labels secondary. NVD lists the records as Awaiting Analysis or Deferred, so there is no NVD-primary score. Our assessment: the real risk depends on your deployment, such as a shared authorization server or clients talking to servers you do not control.