Summary
An authorization-server confusion vulnerability in the MCP TypeScript SDK can cause an HTTP MCP client to send stored OAuth credentials to an authorization server selected by a connected MCP server. This may expose refresh tokens, client secrets, or signed authentication assertions when the client connects to an untrusted or compromised server.
An authorization-server confusion vulnerability in the MCP TypeScript SDK can cause an HTTP MCP client to send stored OAuth credentials to an authorization server selected by a connected MCP server. This may expose refresh tokens, client secrets, or signed authentication assertions when the client connects to an untrusted or compromised server.
Affected context
The issue affects applications that use the SDK as an MCP client over HTTP with an OAuth-enabled authentication provider, including custom OAuth providers and supported bundled providers. Risk is present when the client can connect to an MCP server that is not fully trusted while retaining credentials intended for a legitimate authorization server, because the credentials are not sufficiently bound to that issuer.
The issue affects applications that use the SDK as an MCP client over HTTP with an OAuth-enabled authentication provider, including custom OAuth providers and supported bundled providers. Risk is present when the client can connect to an MCP server that is not fully trusted while retaining credentials intended for a legitimate authorization server, because the credentials are not sufficiently bound to that issuer.
Exploit preconditions
- Attack surface: HTTP-based MCP client authentication and protected resource metadata processing
- Required access: Ability to operate, compromise, or influence an MCP server to which the client connects
- Trigger point: Client authentication or token refresh after processing server-provided authorization metadata
- Credential condition: The client holds a refresh token, client secret, or signed assertion for another authorization server
- Why exploitation is possible: The client accepts the server-selected authorization server without adequately verifying that it matches the issuer associated with the stored or configured credentials
- Attack surface: HTTP-based MCP client authentication and protected resource metadata processing
- Required access: Ability to operate, compromise, or influence an MCP server to which the client connects
- Trigger point: Client authentication or token refresh after processing server-provided authorization metadata
- Credential condition: The client holds a refresh token, client secret, or signed assertion for another authorization server
- Why exploitation is possible: The client accepts the server-selected authorization server without adequately verifying that it matches the issuer associated with the stored or configured credentials
Why this happens
The underlying flaw is insufficient verification of the relationship between authentication credentials and the authorization server requesting them. The client treated authorization-server information supplied through a connected MCP server as authoritative, even though stored and pre-provisioned credentials were not bound to an expected issuer. This maps primarily to CWE-345: Insufficient Verification of Data Authenticity, with a related CWE-522: Insufficiently Protected Credentials concern because sensitive credentials could be disclosed to an unintended recipient.
The underlying flaw is insufficient verification of the relationship between authentication credentials and the authorization server requesting them. The client treated authorization-server information supplied through a connected MCP server as authoritative, even though stored and pre-provisioned credentials were not bound to an expected issuer. This maps primarily to CWE-345: Insufficient Verification of Data Authenticity, with a related CWE-522: Insufficiently Protected Credentials concern because sensitive credentials could be disclosed to an unintended recipient.
Potential impact
- An attacker may obtain refresh tokens or client secrets
- An attacker could replay exposed credentials against the legitimate authorization service
- Signed assertions or private-key-based authentication material may be misused
- A compromised authorization account or connected application could permit unauthorized data access
- Credential exposure may enable lateral movement into integrated services
- An attacker may obtain refresh tokens or client secrets
- An attacker could replay exposed credentials against the legitimate authorization service
- Signed assertions or private-key-based authentication material may be misused
- A compromised authorization account or connected application could permit unauthorized data access
- Credential exposure may enable lateral movement into integrated services
General mitigation guidance
Mitigation centers on binding every credential to an explicitly trusted authorization-server issuer and refusing issuer changes that are not independently authorized.
Common defensive patterns include:
- Require an expected issuer or equivalent allowlist for each OAuth credential set
- Validate protected resource metadata against trusted configuration rather than accepting it unconditionally
- Keep refresh tokens, client secrets, and signing credentials scoped to their intended authorization server
- Prefer interactive authorization flows that clearly display and verify the authorization server
- Restrict MCP clients to servers with established trust relationships when issuer binding cannot be enforced
- Apply least privilege to OAuth scopes and client identities
- Rotate credentials if they may have been sent to an unintended authorization server
Mitigation centers on binding every credential to an explicitly trusted authorization-server issuer and refusing issuer changes that are not independently authorized.
Common defensive patterns include:
- Require an expected issuer or equivalent allowlist for each OAuth credential set
- Validate protected resource metadata against trusted configuration rather than accepting it unconditionally
- Keep refresh tokens, client secrets, and signing credentials scoped to their intended authorization server
- Prefer interactive authorization flows that clearly display and verify the authorization server
- Restrict MCP clients to servers with established trust relationships when issuer binding cannot be enforced
- Apply least privilege to OAuth scopes and client identities
- Rotate credentials if they may have been sent to an unintended authorization server
How teams detect issues like this
Organizations can look for this issue through:
- Static analysis of OAuth client code for issuer values derived directly from remote MCP metadata
- Code review checks confirming that tokens and client secrets are associated with an expected issuer
- Tests that simulate a server advertising an unexpected authorization server
- Runtime monitoring for token, secret, or assertion requests sent to unapproved authorization endpoints
- Policy enforcement that requires issuer allowlists and blocks authentication to untrusted MCP servers
- Automated security review tools that identify missing authenticity checks around OAuth metadata
Organizations can look for this issue through:
- Static analysis of OAuth client code for issuer values derived directly from remote MCP metadata
- Code review checks confirming that tokens and client secrets are associated with an expected issuer
- Tests that simulate a server advertising an unexpected authorization server
- Runtime monitoring for token, secret, or assertion requests sent to unapproved authorization endpoints
- Policy enforcement that requires issuer allowlists and blocks authentication to untrusted MCP servers
- Automated security review tools that identify missing authenticity checks around OAuth metadata
