A token can be perfectly valid and still be sent to the wrong service. That is the uncomfortable part of CVE-2026-19202. The flaw is not about forging a Google ID token. It is about a Python SDK caching one token and reusing it across different audiences inside the same process. In an MCP deployment that talks to several services, that turns a performance optimization into a trust-boundary problem. A token minted for a sensitive backend can reach another service that was never supposed to see it. **In practical terms, it is a good time to:** - inventory applications using `mcp-toolbox-sdk-python` and identify the installed `toolbox-core` version - map every audience requested by each long-running agent or service process - inspect whether the same process authenticates to multiple Google-backed services - review outbound authentication telemetry for tokens appearing at unexpected service endpoints - upgrade affected SDK deployments and restart persistent processes so old in-memory state is cleared Where else are we assuming that a credential cache understands the same security boundary we do? #LinuxSecurity #CloudSecurity #DevSecOps #IdentitySecurity #OpenSource https://linuxsecurity.com/news/cloud-security/mcp-toolbox-flaw-could-expose-google-service-tokens