Skip to main content

MCP Toolbox CVE-2026-11718

| EUVDEUVD-2026-37880 CRITICAL
Improper Authentication (CWE-287)
2026-06-18 Google GHSA-wcpr-6g7x-p44r
9.3
CVSS 4.0 · Vendor: Google
Share

Severity by source

Vendor (Google) PRIMARY
9.3 CRITICAL
CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:H/VI:H/VA:N/SC:N/SI:N/SA:N/E:X/CR:X/IR:X/AR:X/MAV:X/MAC:X/MAT:X/MPR:X/MUI:X/MVC:X/MVI:X/MVA:X/MSC:X/MSI:X/MSA:X/S:X/AU:X/R:X/V:X/RE:X/U:X
vuln.today AI
9.1 CRITICAL

Network-reachable auth bypass with no privileges or user interaction; full read/write access to protected MCP operations gives C:H/I:H, while availability is unaffected.

3.1 AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:N
4.0 AV:N/AC:L/AT:N/PR:N/UI:N/VC:H/VI:H/VA:N/SC:N/SI:N/SA:N
SUSE
CRITICAL
qualitative

Primary rating from Vendor (Google).

CVSS VectorVendor: Google

Attack Vector
Network
Attack Complexity
Low
Privileges Required
None
User Interaction
None
Scope
X

Lifecycle Timeline

2
Source Code Evidence Fetched
Jun 18, 2026 - 12:33 vuln.today
Analysis Generated
Jun 18, 2026 - 12:33 vuln.today

DescriptionCVE.org

An authentication bypass vulnerability exists in the generic opaque token validation path (validateOpaqueToken) of googleapis/mcp-toolbox.

When the toolbox validates an opaque token via an OAuth 2.0 introspection endpoint (RFC 7662), it decodes the response into an introspectResp struct. However, the subsequent claim-checking logic (validateClaims) evaluates the issuer condition as if a.issuer != "" && iss != "". If the external OAuth provider's introspection response omits the optional iss (issuer) field completely, the variable iss defaults to an empty string. This causes the conditional block to evaluate to false and be skipped silently. Consequently, the application accepts tokens issued by unauthorized or unintended third-party identity providers.

AnalysisAI

Authentication bypass in googleapis/mcp-toolbox allows remote unauthenticated attackers to gain access by presenting opaque OAuth tokens issued by unauthorized identity providers. The flaw lives in validateOpaqueToken's claim-checking logic, which silently skips issuer validation when an OAuth 2.0 introspection response omits the optional iss field. No public exploit identified at time of analysis, but the upstream fix in PR #3360 confirms the defect and CVSS 4.0 scores it 9.3 (Critical).

Technical ContextAI

MCP Toolbox is Google's open-source Model Context Protocol toolbox for databases (written in Go), which brokers authenticated requests from MCP clients to backend data sources. Its generic OAuth handler supports RFC 7662 token introspection, where the toolbox sends an opaque bearer token to an external authorization server and decodes the JSON response into an introspectResp struct. The root cause is CWE-287 (Improper Authentication): in internal/auth/generic/generic.go, validateClaims gated the issuer comparison on 'a.issuer != "" && iss != ""', so when an introspection endpoint omitted the optional 'iss' claim, iss defaulted to empty string and the entire issuer check was skipped rather than failing closed. The fix in PR #3360 inverts the logic to reject any token whose introspection response is missing an issuer, and additionally hardens discoverOIDCConfig to refuse OIDC configurations that lack an issuer.

RemediationAI

Upstream fix available (PR/commit); released patched version not independently confirmed - operators should track googleapis/mcp-toolbox PR #3360 (https://github.com/googleapis/mcp-toolbox/pull/3360) and upgrade to the first tagged release that includes its commits, which adds an explicit 'missing issuer in token validation' rejection in validateClaims and a fail-closed check in discoverOIDCConfig. Until that release is consumed, compensating controls include disabling the generic opaque-token introspection path and falling back to signed JWT validation where the issuer is part of the cryptographically protected payload, configuring the toolbox's a.issuer to a strict trusted value and only pointing it at introspection endpoints known to always emit the iss claim (most major IdPs like Google, Okta, and Auth0 do), or fronting the toolbox with a reverse proxy/gateway that enforces issuer validation independently. Trade-offs: disabling opaque tokens breaks clients that cannot present JWTs, and proxy-level enforcement adds operational complexity and a second place to keep issuer lists in sync.

Vendor StatusVendor

SUSE

Severity: Critical
Product Status
SUSE Linux Enterprise Server 16.1 Affected
SUSE Linux Enterprise Server for SAP applications 16.1 Affected
SUSE Linux Enterprise Module for Package Hub 15 SP5 Affected
SUSE Linux Enterprise Module for Package Hub 15 SP6 Affected
openSUSE Leap 15.5 Affected

Share

CVE-2026-11718 vulnerability details – vuln.today

This site uses cookies essential for authentication and security. No tracking or analytics cookies are used. Privacy Policy