CVE-2026-19202: Google mcp-toolbox-sdk-python · Use of a Shared Cache with Insufficient Key Granularity
Affects Google mcp-toolbox-sdk-pythonSource CVE Database V5
Not known to be exploited · CVSS 9.1 Critical.
Data as of 5 Nov 2026, 00:01 UTC
- EPSS
- 0.2% chance of exploitation in 30 days – higher than 13% of CVEsExploit Prediction Scoring System: the likelihood attackers will use this flaw soon.
CVSS:4.0/AV:N/AC:L/AT:P/PR:N/UI:N/VC:H/VI:H/VA:N/SC:N/SI:N/SA:NExploitation evidence
Disclosed: evidence found.
CVE published 22 Sep 2026
Detectable: no evidence on record.
No public nuclei template indexed
Weaponized: no evidence on record.
No public exploit code indexed in Metasploit or Exploit-DB
Exploited in the wildExploited: no evidence on record.
Not in CISA KEV and no source reports exploitation
Observed by OffSeq MirageSeen by Mirage: no evidence on record.
No attack traffic recorded by OffSeq Mirage sensors
A missing step is not evidence of safety. Sources: cve.org (opens in a new tab), the Metasploit, Exploit-DB and nuclei-templates index as of 5 Nov 2026.
What to do
Affected software
| Product | Affected | Fixed in |
|---|---|---|
| Googlemcp-toolbox-sdk-python | Affected
| Fixed in– |
PyPImcp-toolbox-sdk-pythonpkg:pypi/mcp-toolbox-sdk-pythonOther threats | Affected
| Fixed in– |
Check your own hosts for these packages with threat-finder (opens in a new tab), our free open-source scanner.
AI-suggested
Until a fix is available, avoid using the SDK to authenticate to multiple audiences within the same process or implement custom token caching keyed by audience to prevent token reuse across services.
Description
A caching flaw in the toolbox-core package of the mcp-toolbox-sdk-python SDK causes the same Google ID token to be cached and reused across different audiences. If an application uses the SDK to authenticate to two or more different audiences within the same process, the module-level token cache fails to key its cached tokens by the requested audience. Consequently, a valid, unexpired token minted for a sensitive service (Service A) can be retrieved from the cache and sent to a secondary service (Service B). An attacker who operates, compromises, or monitors traffic to Service B can capture this token and replay it to impersonate the victim application against Service A.