Threat Intelligence Database

A Server-Side Request Forgery (SSRF) vulnerability exists in Google mcp-toolbox versions 0.3.0 through 1.4.0. The vulnerability arises because the HTTP client used by the toolbox does not enforce restrictive redirect policies or validate target IPs, allowing crafted requests to cause unauthorized internal or external requests. This can lead to information disclosure or unauthorized interactions with internal systems. The vulnerability has a CVSS score of 6.1, indicating a high severity level.

CVE-2026-14541 is a high severity authentication bypass and audience confusion vulnerability in the Google OAuth provider component of Google mcp-toolbox version 1.4.0. When initialized with mcpEnabled: true but without an explicitly defined audience or clientId, the token validation process skips audience checks. This allows acceptance of any valid Google OAuth access token, even those intended for unrelated applications, potentially granting unauthorized access to protected tools and data backends.

Google mcp-toolbox versions v1.3.0 and v1.4.0 contain an incorrect authorization vulnerability in the direct HTTP API tool invocation endpoint. This flaw allows an unauthenticated attacker to invoke tools that should be protected by the scopeRequired feature by sending requests through legacy HTTP endpoints when the --enable-api flag is enabled. The vulnerability has a high severity with a CVSS score of 9.8, indicating critical impact on confidentiality, integrity, and availability.

CVE-2026-15829 is a high-severity SQL injection and security boundary bypass vulnerability in Google MCP Toolbox for Databases version 0.13.0. The vulnerability exists in the BigQuery forecasting tool component, where certain client-controlled parameters are interpolated directly into SQL queries without proper escaping. This allows attackers to inject arbitrary SQL, bypass dataset restrictions, and read unauthorized BigQuery tables.

An authenticated authorization bypass vulnerability exists in MCP Toolbox for Databases due to missing scope enforcement across older protocol handlers. While the 2025-11-25 protocol version handler correctly enforces per-tool restrictions defined by scopesRequired, older supported protocol versions (2025-06-18, 2025-03-26, and 2024-11-05) omit this check. An authenticated client with low-privilege tokens (e.g., read) can bypass the intended per-tool scope restrictions and execute high-privilege tools (e.g., admin) simply by specifying an older protocol version in the MCP-Protocol-Version header, or by omitting the header entirely (which causes the server to default to the vulnerable 2024-11-05 handler).

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.

An authentication bypass vulnerability exists in the generic opaque token validation path (validateOpaqueToken) of googleapis/mcp-toolbox. When verifying an unparsed opaque token via an OAuth 2.0 introspection endpoint (RFC 7662), the toolbox decodes the response into an introspectResp struct where the Active field is declared as a pointer to a boolean (*bool). The code only explicitly rejects a token if the response contains a populated active field set to false (if introspectResp.Active != nil && !*introspectResp.Active). If an introspection endpoint responds with a payload that completely omits the mandatory active key, the internal variable remains nil, causing the conditional check to short-circuit. As a result, Toolbox accepts authorization tokens missing the "active" field, granting access to protected tools and underlying data sources.