CVE-2026-19202: Google MCP Toolbox Token Exposure Explained

CVE-2026-19202: Google MCP Toolbox Token Exposure Explained

A vulnerability in Google's MCP Toolbox Python SDK could expose a Google ID token to a service it was never intended to reach. Tracked as CVE-2026-19202, the flaw involved a shared token cache that failed to distinguish credentials by their intended audiences.

The vulnerability was publicly disclosed on September 22, 2026, with a reported CVSS 4.0 score of 9.1, classified as Critical.

According to the published vulnerability record, an application authenticating to multiple services could retrieve a cached token intended for one service and transmit it to another. An attacker able to capture the token at the unintended destination could potentially replay it against the original service.

The vulnerability shows how a correctly issued credential can reach an unintended destination when an application selects the wrong token. For organizations operating applications and AI agents across multiple services, the relevant question is how credential boundaries are preserved throughout execution.

What Happened in CVE-2026-19202?

The vulnerability affected token caching in the toolbox-core package of Google's MCP Toolbox Python SDK.

The affected implementation maintained a module-level cache for Google ID tokens. However, the cache did not include the requested audience in its lookup key. When an application authenticated to services with different audiences within the same process, the SDK could return a previously cached token rather than one intended for the requested destination.

Consider an application communicating with two protected services.

Service A is an internal application requiring a Google ID token for authentication. Service B is another endpoint with a different audience and potentially a different trust boundary.

The application first requests a token for Service A. The SDK obtains the token and stores it in its shared cache. Later, the application needs to authenticate to Service B.

Instead of retrieving a token associated with Service B's audience, the vulnerable cache can return the previously stored token for Service A. The SDK then attaches Service A's credential to the outgoing request intended for Service B.

Even if Service B rejects the token, it has already received a credential intended for another service.

An attacker who operates, compromises, or monitors Service B could potentially capture the exposed token and attempt to replay it against Service A. Successful exploitation would depend on the token remaining valid, the attacker being able to reach Service A, and any additional security controls protecting the intended service.

The immediate vulnerability was incorrect credential selection. The SDK retrieved a token associated with the wrong audience and transmitted it to an unintended destination.

The published disclosure describes this potential attack path. It does not establish that attackers exploited the vulnerability in the wild.

Why Audience Binding Didn't Prevent Token Exposure

Google ID tokens contain an audience claim, represented as aud. This identifies the service or application for which the token was issued.

A receiving service should verify that the audience matches its expected identity before accepting the token as authentication.

A token issued for Service A can contain the correct audience and pass Service A's validation. Service B should reject that token because its audience does not match. However, rejecting the token does not prevent Service B from receiving it.

Audience validation occurs at the receiving service. It does not determine which credential the sending application retrieves or attaches to an outgoing request.

The resulting exposure matters because the affected ID tokens function as bearer credentials. Possession of a usable bearer token may allow another party to authenticate to its intended recipient, subject to token validity and additional restrictions.

Three security responsibilities are relevant:

• Credential selection: Retrieving the appropriate credential for the requested destination.
• Audience validation: Determining whether the receiving service should accept the credential.
• Credential isolation: Keeping credentials within their intended handling and destination boundaries.

The vulnerability originated in credential selection. Incorrect selection compromised isolation by transmitting a valid token to an unintended recipient.

The incident concerned Google ID tokens and their intended audiences rather than excessive OAuth permission scopes. Google's authentication documentation explains the differences between identity tokens and access tokens.

How the Token Cache Was Corrected

The SDK's token-caching implementation was changed to separate cached credentials according to their intended audiences.

The updated implementation includes the requested audience in the cache key. A request for Service A's credential therefore uses a different cache entry from a request for Service B's credential.

The correction also introduced tests involving token getters configured for different audiences. The relevant SDK correction was merged on June 5, 2026.

For organizations investigating potential exposure, the distinction between a merged correction and a corrected deployment matters. A merged code change does not establish that every application received the fix.

Organizations should identify the authentication components installed in their environments and verify that the deployed toolbox-core implementation contains the audience-aware caching correction.

Checking a higher-level integration package's version may not establish which authentication implementation is running.

What the Incident Reveals About Credential Handling

CVE-2026-19202 draws attention to the components responsible for credential retrieval and request construction.

Applications communicating with multiple services may use shared authentication libraries, token caches, and request-handling components. Those components can process credentials associated with different services and trust boundaries.

The vulnerability shows how a shared authentication component can become a point where those boundaries intersect. An implementation error can cause a credential intended for one service to reach another.

This risk does not necessarily depend on excessive permissions. Even a correctly issued, audience-bound credential can be exposed if an application sends it to an unintended destination.

Security reviews should therefore examine how shared components select credentials, associate them with destinations, and attach them to outgoing requests. Protecting credential storage and validating tokens at receiving services are necessary, but they do not replace correct handling between those controls.

A correctly issued credential still depends on the components that retrieve it, select it, and attach it to outgoing requests.

What Security Teams Should Examine

Organizations using the affected SDK should establish whether their deployments are vulnerable, verify the correction, and investigate potential historical exposure.

The first three checks address the immediate vulnerability investigation. The fourth extends the review to broader credential-handling practices.

1. Identify Potentially Affected Deployments

Inventory applications using Google's MCP Toolbox Python SDK. Prioritize processes that authenticate to multiple protected endpoints with different audiences, particularly when they use shared authentication components.

Identify the installed toolbox-core package and examine its dependencies. Record the affected services, their expected audiences, and the authentication package versions deployed in each application.

The affected implementation used a module-level cache. Investigate processes that authenticate to multiple audiences through the shared authentication component, including applications that create multiple client instances.

Checking a higher-level integration package's version may also be insufficient if the authentication component is separately versioned.

2. Verify the Audience-Aware Caching Correction

Confirm that the deployed toolbox-core implementation includes the requested audience in its cache key.

Use the merged SDK correction as the technical reference when examining the installed implementation.

Use controlled test credentials and endpoints to verify that the SDK selects a token for the requested audience. Test consecutive requests for different audiences, then reverse their order to confirm that previously cached credentials do not affect subsequent selection.

Where relevant, test concurrent requests as an additional assurance measure. The disclosure identified an audience-insensitive cache key, not a separate concurrency vulnerability.

Verification should establish that requests for different audiences remain isolated regardless of which credential was cached first.

3. Investigate Potential Historical Exposure

For potentially affected deployments, determine whether credentials could have been transmitted to unintended endpoints.

Map the audiences used by each affected process to the endpoints it contacted. Where telemetry permits, investigate requests in which the intended destination differed from the audience associated with the transmitted credential.

Review available request logs and relevant telemetry. Determine whether secondary services received or recorded authentication material intended for another service.

The absence of recorded authorization headers does not establish that credentials were never transmitted. Log retention, redaction, and available telemetry may limit what investigators can determine.

Where an unexpected credential transmission is identified, establish whether the receiving service was controlled by the organization, a trusted third party, or an untrusted destination. Assess the validity of potentially exposed tokens, possible replay, and appropriate containment measures.

If necessary, investigate whether the intended service received requests that could have used an exposed credential.

Avoid introducing additional exposure during the investigation. Do not copy live bearer tokens into diagnostic logs or test artifacts.

4. Review the Broader Credential-Handling Path

Beyond the immediate vulnerability, examine which components, processes, and tools can access sensitive credentials.

Review shared credential stores, process memory, authentication libraries, token caches, proxies, and request-handling components.

Trace how the application selects a credential, retrieves it from the cache, and attaches it to an outgoing request. Confirm that each step preserves the requested audience and destination.

Where appropriate, restrict credential availability and separate components operating across different trust boundaries.

These checks apply to multi-service applications more broadly. They are not limited to the affected SDK.

Runtime Enforcement in Multi-Service Agent Environments

Consider an engineering agent investigating a failed deployment. It retrieves application logs, examines repository changes, and interacts with internal infrastructure.

These activities may involve different tools, MCP servers, authentication systems, and permissions. Although the agent is performing one task, its execution path may cross several security boundaries.

Correct credential handling ensures that credentials remain associated with their intended destinations. A separate security responsibility is determining whether the agent is authorized to perform each proposed action.

The correction for CVE-2026-19202 addresses the credential-selection failure described in the vulnerability. Runtime authorization addresses a separate challenge: controlling agent actions as they move between services.

The Google ID tokens involved in CVE-2026-19202 were restricted by audience. The vulnerability concerned incorrect credential selection, not excessive OAuth permission scopes. Narrowing an agent's permissions would not correct the SDK's caching defect.

In broader agent environments, however, the authority available during execution remains an important security consideration.

An engineering agent retrieving application logs does not necessarily require permission to modify production infrastructure. Where the underlying credential model supports narrower permissions, organizations can limit the authority available for individual tool actions.

As agents operate across different tools, MCP servers, and infrastructure environments, authorization decisions may need to remain consistent across those execution paths. A horizontal runtime access-control layer can complement each platform's native security mechanisms by evaluating agent actions against organizational policy and task intent.

AgntID provides policy- and task-intent-driven runtime access control for AI agents. It evaluates individual tool actions before execution and supports just-for-task credential narrowing for approved actions. Its customer-hosted architecture integrates with existing IAM systems and applies consistent enforcement to agent actions routed through supported tools and MCP servers, without requiring organizations to replace their existing infrastructure.

Runtime enforcement provides an additional authorization boundary for agent actions routed through supported integrations. It does not fix credential-selection defects inside underlying libraries or SDKs.

An exposed bearer token may also remain usable if an attacker can present it directly to its intended service without passing through the enforcement layer.

Credential Security Across Agent Environments

CVE-2026-19202 illustrates why credential security depends on correct handling throughout execution. Applications must preserve the relationship between credentials and their intended destinations during retrieval and transmission.

For enterprises deploying AI agents, secure credential handling is one part of a broader responsibility. Agents may perform different actions across multiple tools and infrastructure environments, requiring authorization decisions appropriate to each action.

Horizontal runtime enforcement provides a complementary way to apply consistent policy- and task-based authorization across supported environments while retaining the security controls provided by individual platforms.

Frequently asked questions

Further reading

• MCP Security Best Practices — A practical guide to MCP authentication, authorization, credential handling, and production security controls.
• Runtime Access Control for AI Agents — An explanation of runtime authorization at the agent tool-call boundary, including task intent, policy enforcement, and just-for-task access.

Sources

• CVE-2026-19202 vulnerability record — The published vulnerability description, affected component, exploitation conditions, severity, and potential security impact.
• Google MCP Toolbox SDK correction, Pull Request #675 — The code correction separating cached credentials according to their intended audiences.
• Google Cloud Authentication: Token Types — Technical documentation covering identity tokens, access tokens, and their security properties.