A Patched MCP Client Can Still Send Its Secret to the Wrong Server
A completed package upgrade does not prove that an OAuth client has stopped trusting the wrong party. For an MCP client, the practical question is which authorisation server the running application will send credentials to.
What the advisory establishes
The MCP Python SDK advisory, published 28 September, covers HTTP clients using OAuthClientProvider, ClientCredentialsOAuthProvider, PrivateKeyJWTOAuthProvider or deprecated 1.x RFC7523OAuthClientProvider with credentials for a legitimate authorisation server and a connection to an MCP server they do not fully trust. SDK-built servers, stdio clients and clients supplying their own tokens or headers are excluded.
The affected ranges are >=1.9.1, <1.30.0 and >=2.0.0a1, <2.2.0; fixes are 1.30.0 and 2.2.0 or later. The structured 2.x range includes the alpha prerelease, while the advisory's narrative examples run from stable 2.0.0 through 2.1.1. The flaw could let an MCP server choose the authorisation server receiving a client credential.
After upgrading, the unattended ClientCredentialsOAuthProvider and PrivateKeyJWTOAuthProvider still require the expected issuer=; without it, the maintainers say the risk remains. The deprecated provider has no issuer option and must be replaced. Clear registrations saved without an issuer once, including those stored by 1.x before 1.30.0, or set the issuer on a self-inserted pre-registered record. If an affected client may have contacted an untrusted server, rotate its client secret and revoke its tokens. On older versions, use only trusted MCP servers. The advisory does not report exploitation.
BlackTree's deployment acceptance checks
Treat this as an application trust-setting change as well as a dependency update. The application owner should identify running clients and their OAuth handlers; the identity owner should confirm the intended authorisation-server URL; and the operations owner should plan any re-registration and credential response. Start with unattended jobs that carry long-lived credentials and can reach server destinations outside the organisation's direct control. An interactive sign-in path has a different approval point and should be assessed separately.
Before closing the change, retain evidence of five checks:
- The deployed process is running the intended fixed branch release, rather than merely having a new version in a lockfile.
- Its configured authorisation-server identity matches the service owner’s approved destination.
- A controlled negative test rejects mismatched issuer metadata before a credential is sent, while the normal sign-in or token flow still works.
- The saved client registration is bound to the intended issuer after the migration, and unattended jobs resume successfully.
- Connection and token-endpoint logs support the exposure assessment. Where that assessment called for credential rotation or token revocation, retain the completion record.
These are BlackTree's proposed acceptance checks, not a vendor-certified test plan. A passing dependency scan cannot answer whether the running client made the right trust decision.
BlackTree's earlier Argo CD MCP report concerns a separate server-side token boundary. It is useful context for asking which side of an MCP connection is allowed to decide where authority flows, but its fix does not repair this Python client issue.
