CVE-2026-14537 is an incorrect authorization flaw in Google's mcp-toolbox, scored 9.8 (critical). In v1.3.0 and v1.4.0, with the API flag enabled, an unauthenticated caller can invoke tools protected by scopeRequired through legacy HTTP endpoints. The project fixed it by refusing to start with both settings. Confirm the released version that contains the fix.
What's affected
- Product: MCP Toolbox for Databases (
mcp-toolbox), from Google. - Affected: v1.3.0 and v1.4.0.
- Condition: the server runs with the
enable-apiflag active, which exposes the direct HTTP tool invocation endpoint, and relies on thescopeRequiredfeature to protect some tools. - Fixed: the project merged a change on 18 June 2026 titled "fail if MCP auth is enabled together with enable-api". The record does not name a fixed release number, so check the project's releases page and advisory for the first version that includes the change.
- Severity: 9.8 with the record's CWE-863 (incorrect authorization). Not on the CISA Known Exploited Vulnerabilities list.
How to check if you're exposed
Find out which version you run and how it is started. If you run the binary directly, ask it for its version. If you run a container, read the image tag, and check deployment files and process arguments:
ps aux | grep -i toolbox
grep -rn "enable-api" deploy/ docker-compose.yml 2>/dev/null
The two facts that put you in scope are a version of v1.3.0 or v1.4.0 and the API flag being active. Also check your tool configuration for the scopeRequired setting, since that is what the bypass defeats. If you use the legacy HTTP invocation endpoint on purpose, for example from scripts, you may have the flag on without remembering it.
If the server is reachable from outside a trusted network, look at its access logs for tool invocation requests that did not carry credentials.
What to do now
- Inventory every mcp-toolbox deployment with its version and start up flags.
- Move to a release that includes the fix, once you have confirmed the version in the project's advisory or release notes.
- If you must stay on v1.3.0 or v1.4.0 for a short time, do not run with the API flag together with scope based protection, and keep the service off untrusted networks.
- Put the server behind network controls so only the clients that need it can connect.
- Review database credentials the toolbox uses. Give them the least access the tools need.
- Look for unauthenticated tool calls in logs from the period you ran the affected versions.
Why it matters
The weakness is CWE-863, incorrect authorization. The system had a rule, that some tools require a scope, and it enforced the rule on one route into the tools but not on another. The record describes the unprotected route as the legacy direct HTTP tool invocation endpoint, reachable when the API flag is on. Anyone who could send requests there could call tools that were meant to be restricted.
For a server whose job is to give AI agents controlled access to databases, that matters. Tools are the way queries reach your data. If a scope check is the thing that separates a read tool from a write tool, or one dataset from another, then skipping the check changes what a stranger can do with your database credentials.
The project's fix is instructive. Rather than quietly patching one path, it makes the server refuse to start when MCP authentication and the legacy API flag are enabled together. That removes the unsafe combination instead of trusting operators to avoid it. It also means that after upgrading, a configuration that used to start may fail, and the error is the signal to choose one mode.
This pattern shows up often when a product keeps an old interface for compatibility. Every entry point needs the same authorization check, and an API scan that compares behavior across endpoints is a good way to find the one that does not.
Try it yourself
This bug is an authorization gap in an HTTP API. The demo shows how an API scan looks for endpoints that skip the checks other endpoints enforce.
Click through it at your own pace, or open it full screen.
Quick check
Which release contains the fix?
The record does not state a release number. The project merged the fix on 18 June 2026, so check the releases page for the first version after v1.4.0 that includes it.
Do I need the API flag?
Only if you use the legacy direct HTTP invocation endpoint. If you do not, leaving it off removes the exposure described in the record.
Sources
Last reviewed: 19 October 2026.
