A newly discovered vulnerability in the official Model Context Protocol (MCP) Python SDK, CVE-2026-116684, could allow an MCP server to accept valid authentication tokens intended for other services through faulty validation of a token’s intended audience. When multiple services share an authorization server, a token issued for one service could potentially be used to access another.
For B2C brands serving consumers via mobile, the implications of the vuln go beyond AI infrastructure. Mobile apps rely on APIs to access customer accounts, personal information, loyalty points, payment-related functions, and other services. If authentication tokens are accepted cross-service, outside their intended context, attackers may exploit gaps between authentication and authorization to access services they shouldn’t.
Patched SDK versions are available, but administrators must explicitly enable audience validation. This vuln illustrates the need to protect API credentials and control which services are trusted to receive authenticated requests.
Approov CEO Ted Miracco, a mobile app security expert, offers perspective:
“A valid token only proves that a trusted issuer created it for someone, at some point, for some purpose.
“It doesn’t prove the three things the server needs to know: Was it issued for this service? Is the party presenting it the one it was issued to? Is the software presenting it genuine and unmodified?
“A hotel key card for room 312 is valid for certain dates, but it shouldn’t open room 410 or any other room, at issuance or at any time. Identity is not authority, and authorization must be decided at the point of use by the service actually being accessed, every time and under strict guardrails.
“A valid authentication token alone should not grant authorization to access a particular service.
“To prevent cross-service authentication failures as AI agents gain access to more enterprise systems, organizations need to upgrade and confirm that audience validation is switched on, and then audit MCP servers in use.
“Next, validate everything on every request: signature, issuer, expiry, audience and scope. Reject any token that wasn’t minted for your service, and never pass tokens through to downstream systems.
“Lastly, make tokens short-lived and narrowly scoped, and bind them to a key the client holds, so a token that is stolen or sent to the wrong place is useless anywhere else. Never provide long-lived secrets like credentials or API keys to access agents unilaterally.
“Mobile security experts learned long ago that secrets embedded in software will always be extracted. The answer was to verify the software itself before issuing it credentials. AI agents should be held to this same standard: prove what you are, then get a short-lived credential for one specific job. Not a universal, non-expiring one.”
It’s time again to patch all the things if this is your use case. The real question is when is patching not a solution.
Related
This entry was posted on October 29, 2026 at 8:32 am and is filed under Commentary with tags GitHub. You can follow any responses to this entry through the RSS 2.0 feed.
You can leave a response, or trackback from your own site.
New MCP Python SDK Vulnerability: Shakey Authentication Enables Unintended Access
A newly discovered vulnerability in the official Model Context Protocol (MCP) Python SDK, CVE-2026-116684, could allow an MCP server to accept valid authentication tokens intended for other services through faulty validation of a token’s intended audience. When multiple services share an authorization server, a token issued for one service could potentially be used to access another.
For B2C brands serving consumers via mobile, the implications of the vuln go beyond AI infrastructure. Mobile apps rely on APIs to access customer accounts, personal information, loyalty points, payment-related functions, and other services. If authentication tokens are accepted cross-service, outside their intended context, attackers may exploit gaps between authentication and authorization to access services they shouldn’t.
Patched SDK versions are available, but administrators must explicitly enable audience validation. This vuln illustrates the need to protect API credentials and control which services are trusted to receive authenticated requests.
Approov CEO Ted Miracco, a mobile app security expert, offers perspective:
“A valid token only proves that a trusted issuer created it for someone, at some point, for some purpose.
“It doesn’t prove the three things the server needs to know: Was it issued for this service? Is the party presenting it the one it was issued to? Is the software presenting it genuine and unmodified?
“A hotel key card for room 312 is valid for certain dates, but it shouldn’t open room 410 or any other room, at issuance or at any time. Identity is not authority, and authorization must be decided at the point of use by the service actually being accessed, every time and under strict guardrails.
“A valid authentication token alone should not grant authorization to access a particular service.
“To prevent cross-service authentication failures as AI agents gain access to more enterprise systems, organizations need to upgrade and confirm that audience validation is switched on, and then audit MCP servers in use.
“Next, validate everything on every request: signature, issuer, expiry, audience and scope. Reject any token that wasn’t minted for your service, and never pass tokens through to downstream systems.
“Lastly, make tokens short-lived and narrowly scoped, and bind them to a key the client holds, so a token that is stolen or sent to the wrong place is useless anywhere else. Never provide long-lived secrets like credentials or API keys to access agents unilaterally.
“Mobile security experts learned long ago that secrets embedded in software will always be extracted. The answer was to verify the software itself before issuing it credentials. AI agents should be held to this same standard: prove what you are, then get a short-lived credential for one specific job. Not a universal, non-expiring one.”
It’s time again to patch all the things if this is your use case. The real question is when is patching not a solution.
Share this:
Like this:
Related
This entry was posted on October 29, 2026 at 8:32 am and is filed under Commentary with tags GitHub. You can follow any responses to this entry through the RSS 2.0 feed. You can leave a response, or trackback from your own site.