Which versions of MCP Toolbox are affected by CVE-2026-14537?

Google mcp-toolbox versions 1.3.0 and 1.4.0 contain an authorization bypass (CVE-2026-14537) enabling unauthenticated attackers to access protected tools and backend data in specific server…

How to fix or mitigate CVE-2026-14537?

Within 24 hours, identify all systems running Google mcp-toolbox 1.3.0 or 1.4.0 with the --enable-api flag enabled and inventory which scope-protected tools are deployed. Within 7 days, implement network segmentation by restricting access to legacy HTTP API endpoints via firewall rules or IP allowlisting, and enable comprehensive logging of tool-invocation requests to detect unauthorized access attempts. Within 30 days, develop an upgrade plan to versions beyond 1.4.0 pending vendor patch release; until patched, disable the --enable-api flag on affected instances if operationally feasible, or maintain persistent network-level access controls and monitoring.

MCP Toolbox CVE-2026-14537

Q: What is the CVSS score of CVE-2026-14537?

CVE-2026-14537 has a CVSS 4.0 base score of 8.1 (High). CVSS vector: CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:H/VI:H/VA:H/SC:N/SI:N/SA:N/E:U/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. EPSS exploitation probability: 0.2%.

EUVD-2026-51371 HIGH

Incorrect Authorization (CWE-863)

2026-07-31 Google

GHSA-f8h2-c55w-8m5p

Authentication Bypass Google Mcp Toolbox

8.1

CVSS 4.0 · Vendor: Google

Severity by source

Vendor (Google) PRIMARY

8.1 HIGH

CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:H/VI:H/VA:H/SC:N/SI:N/SA:N/E:U/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.8 CRITICAL

Network-reachable, unauthenticated bypass of tool authorization (AV:N/PR:N/UI:N, AC:L); invoked tools can read and alter backend data giving full C/I/A impact; scope unchanged as impact stays within the toolbox system.

3.1 AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H

4.0 AV:N/AC:L/AT:N/PR:N/UI:N/VC:H/VI:H/VA:H/SC:N/SI:N/SA:N

Primary rating from Vendor (Google).

CVSS VectorVendor: Google

Attack Vector

Network

Attack Complexity

Low

Privileges Required

None

User Interaction

None

Scope

Lifecycle Timeline

Source Code Evidence Fetched

Jul 31, 2026 - 02:14 vuln.today

Analysis Generated

Jul 31, 2026 - 02:14 vuln.today

CVE Published

Jul 31, 2026 - 01:38 cve.org

HIGH 8.1

DescriptionCVE.org

Incorrect Authorization in the direct HTTP API tool invocation endpoint in Google mcp-toolbox versions v1.3.0 and v1.4.0 allows an unauthenticated attacker to invoke tools protected by the scopeRequired feature via sending tool invocation requests through legacy HTTP endpoints when the --enable-api flag is active.

AnalysisAI

Authorization bypass in Google mcp-toolbox v1.3.0 and v1.4.0 lets an unauthenticated remote attacker invoke tools that were meant to be protected by the scopeRequired MCP-auth feature by routing tool-invocation requests through the legacy direct HTTP API endpoints, which do not honor those scope checks. Exploitation requires the server to be started with the --enable-api flag alongside scope-protected tools. There is no public exploit identified at time of analysis (CVSS 4.0 exploit maturity is Unproven), but the flaw carries high confidentiality, integrity, and availability impact because the exposed tools can act on backend data sources.

Technical ContextAI

mcp-toolbox (Google's MCP Toolbox for Databases) is a server that exposes configured 'tools' - typically database and API operations - to LLM/agent clients over both a modern MCP transport and a set of legacy direct HTTP API endpoints. The MCP-auth layer supports a scopeRequired mechanism (OAuth-style scope enforcement via GetScopesRequired/ValidateMCPAuth) that gates tool invocation on the MCP path. The root cause is CWE-863 (Incorrect Authorization): the legacy HTTP API tool-invocation path, enabled by --enable-api, does not run the same scope/authorization enforcement, so requests that should be rejected for lacking the required scope are executed anyway. The upstream fix in PR #3435 does not add scope checks to the legacy path; instead it makes the two mutually exclusive, returning a startup error ('MCP Auth cannot be enabled together with the legacy HTTP API') when both MCP auth (IsMCPEnabled) and EnableAPI are configured, both at CLI parse time and in InitializeConfigs. The single affected CPE is cpe:2.3:a:google:mcp-toolbox.

RemediationAI

Upstream fix available (PR/commit); released patched version not independently confirmed - the corrective change is in https://github.com/googleapis/mcp-toolbox/pull/3435, which blocks starting the server when MCP auth and the legacy HTTP API are enabled together, so upgrade to a build that includes this PR once a tagged release is published. As an immediate compensating control that does not require the patch, stop passing the --enable-api flag (disable the legacy HTTP API entirely) and rely only on the MCP transport where scopeRequired is enforced; the trade-off is that any clients depending on the legacy direct HTTP endpoints will break and must migrate to the MCP path. If the legacy API cannot be disabled, restrict network access to the API endpoints (firewall/reverse-proxy allowlist or mTLS) so only trusted clients can reach them, and avoid relying on scopeRequired as the sole protection for sensitive tools while the legacy path remains active. Verify the running configuration after any change by confirming the server rejects the combined --enable-api + MCP-auth startup.