CVE-2026-11717 is a critical authentication bypass (CVSS 9.1) in googleapis/mcp-toolbox, Google MCP Toolbox for Databases. When it checks an opaque token with an OAuth introspection endpoint, it accepts a response that leaves out the active field. The fix, pull request 3341, is in release v1.4.0. Upgrade and review who can reach your toolbox.
What's affected
From the CVE record, the pull request and the release notes:
- Product: googleapis/mcp-toolbox (Google MCP Toolbox for Databases), when generic OAuth with opaque token validation is configured.
- Component: the
validateOpaqueTokenfunction in the generic opaque token validation path. - Cause: the code decodes the introspection response into a struct where
Activeis a pointer to a boolean. It rejects a token only whenactiveis present and false. When the field is missing, the pointer stays nil and the check is skipped. - Fixed in: pull request 3341, merged 4 June 2026 and listed in the v1.4.0 release notes ("separate Google and Generic MCP OAuth verification"). The pull request states that it enforces the
activefield in the generic provider. - Affected versions: the record does not give a version range. Treat releases before v1.4.0 as in scope.
- Weakness class: CWE-287 (improper authentication).
- Severity: CVSS 9.1: network reachable, no privileges, no user interaction, High impact on confidentiality and integrity.
How to check if you're exposed
You are exposed if you run a release before v1.4.0 and have configured the generic OAuth path that validates opaque tokens through an introspection endpoint.
- Find every place the toolbox runs: servers, containers, developer machines that expose it, and CI jobs. Read the version from the binary or the image tag.
toolbox --version
- Look at your toolbox configuration for an auth service that uses a generic OAuth provider with an introspection endpoint. Google type auth is handled by a separate code path.
- Check what the introspection endpoint returns for a token that is invalid. Your provider should return
activeset to false. Record what it does, because the flaw matters when a response omits the field. - Make a list of the tools and data sources behind the toolbox. That list is what an accepted forged token could reach.
What to do now
- Upgrade to v1.4.0 or later. The newest release we saw at review time was v1.14.0, published 8 October 2026.
- Review the tools and data sources the toolbox can reach, and remove database access it does not need. Use read only database accounts where the tools only read.
- Do not expose the toolbox to the internet. Put it behind a network control so that only the clients that need it can connect.
- Check access logs for tool calls that you cannot tie to a known client, for the period before you upgraded.
- Also apply the fix for CVE-2026-11718, the issuer check in the same code path, which is fixed in the same release.
Why it matters
This is a fail-open check. The code was meant to reject tokens that the introspection endpoint says are not active, but it wrote the rule as "reject when active is present and false". A response with no active field at all falls through. In the OAuth introspection standard, RFC 7662, active is a required field, so a response without it is not a valid answer, and the safe reading is to reject.
The pointer to a boolean is the small detail that makes the bug. In Go, a missing JSON field leaves a pointer nil, and nil is neither true nor false. The condition checked for the false case only, so nil was treated like true. The same shape of bug appears whenever security code distinguishes "unset" from "denied" but handles only one of them. In a review, search for conditions that reject on an explicit negative and otherwise accept.
The impact is access to the tools a toolbox exposes. Per the record, a token that lacks the field is accepted, "granting access to protected tools and underlying data sources". Those tools talk to databases, which is why the vector gives High confidentiality and integrity impact. The CVE is not in the CISA Known Exploited Vulnerabilities catalog.
The pull request also separates the Google verification from the generic one, because the Google tokeninfo endpoint returns a non-standard response.
Try it yourself
Click through it at your own pace, or open it full screen.
Quick check
Does this affect the Google token type?
The pull request separates the Google and generic verification paths, because Google's tokeninfo response is not standard. The flaw described in the record is in the generic opaque token path.
What should my introspection endpoint return?
Per RFC 7662, an active field that is true or false. The record calls the field mandatory. An endpoint that omits it can trigger this flaw in unfixed releases.
Sources
- Gold entry and CVE record: CVE-2026-11717.
- Pull request 3341 in googleapis/mcp-toolbox, merged 4 June 2026.
- mcp-toolbox v1.4.0 release notes, published 4 June 2026.
- mcp-toolbox releases page, used to identify the newest release.
Last reviewed: 19 October 2026.
