Attack ChainAIDerived
Hypothetical attack flow derived from CVE metadata – not a confirmed exploit chain
-
AccessObtain authorized tool-execution access to Toolbox
-
DeliveryPlace or reference symlink inside an allowed root
-
ExploitInvoke cloud-storage download/upload tool
-
ExecutionLexical validation passes, symlink resolved at open
-
ImpactRead or overwrite arbitrary file outside root
Vulnerability Assessment
| Weakness |
CWE
OWASP Top 10:2025
A01:2025 - Broken Access Control
ASVS 5.0
V5 - File Handling Symlink resolution safety
|
| Exploitation Conditions | Requires Google MCP Toolbox for Databases 1.2.0-1.9.0 deployed with the cloud-storage source, where allowedLocalRoots is configured as a filesystem boundary for cloud-storage-upload-object / cloud-storage-download-object. The attacker must be a remote but AUTHENTICATED principal holding tool-execution permissions, and must be able to reference (or cause creation of) a symbolic link inside an allowed root that resolves to a target outside it. Limiting factors: exploitation is impossible without valid tool-execution authorization (PR:L); if allowedLocalRoots is omitted entirely the setting provides no restriction at all (a separate misconfiguration, not this bypass); and per the vendor notes hard links and a TOCTOU swap window remain as residual issues even after the fix, so the guardrail is explicitly secondary to OS-level file permissions. |
| Impact | This is a genuine, well-substantiated integrity/confidentiality issue rather than an inflated high-CVSS score. The vendor CVSS 4.0 vector (AV:N/AC:L/AT:N/PR:L/UI:N/VC:H/VI:H/VA:N, base 8.6) is internally consistent with the description: a network-reachable, authenticated attacker who holds tool-execution permissions can read (VC:H) and overwrite (VI:H) arbitrary files, with no availability impact claimed. The one dampening signal is PR:L - this is NOT an unauthenticated internet-wide bug; the attacker must already be an authorized principal able to invoke the cloud-storage upload/download tools. No EPSS score, no CISA KEV listing, and no public POC were provided, so exploitation is 'no public exploit identified at time of analysis'; this is a fresh, vendor-reported (Google) issue with a merged fix (PR #3810), consistent with pre-weaponization disclosure. Note a conflict in the input metadata: the CVE is tagged 'Authentication Bypass' but the CWE (CWE-59/CWE-22) and description describe symbolic-link/path-traversal sandbox escape by an ALREADY-authenticated user - it does not bypass authentication, so that tag is misleading for triage. Overall: real priority for anyone running MCP Toolbox with the cloud-storage source and allowedLocalRoots as a security boundary, but bounded by the authenticated-attacker precondition. |
| Exploit ScenarioDerived | An attacker who holds tool-execution permissions on a Google MCP Toolbox for Databases instance (1.2.0-1.9.0) plants or abuses a symbolic link inside a configured allowedLocalRoots directory that points to a sensitive file outside it (e.g. /etc/passwd, credentials, or config). They then invoke cloud-storage-download-object to exfiltrate that file, or cloud-storage-upload-object to overwrite an out-of-bounds file, because path validation only compares the lexical path before resolving the link. No public POC is identified, but the fix PR includes explicit symlink-escape test cases that effectively demonstrate the technique. |
Get an e-mail when this CVE is exploited, patched or re-scored. Free account.
Alert meAnalysisAIv1 – Sep 29, 2026
Symbolic-link path resolution flaw in Google MCP Toolbox for Databases 1.2.0 through 1.9.0 lets an authenticated remote attacker who holds tool-execution permissions read or overwrite arbitrary local files outside the directories configured in allowedLocalRoots. The affected tools, cloud-storage-upload-object and cloud-storage-download-object, validate a caller-supplied path lexically before following it, so a symlink planted inside an allowed root that points outside that root is accepted. Exploitation requires valid tool-execution authorization (CVSS PR:L) and a symlink reachable inside an allowed root, so no public exploit code has been identified at time of analysis and the issue is not confirmed actively exploited (CISA KEV); the vendor describes the control as a guardrail that must be layered on top of OS file permissions.
RemediationAI
Vendor-released patch status: the upstream fix is available at https://github.com/googleapis/mcp-toolbox/pull/3810, which adds symbol-link resolution (ResolveSymlinks) to validateLocalPath so a path must remain inside an allowed root both as written and after links are resolved; because this reference points to a GitHub pull request rather than a tagged release, the first released patched version is not independently confirmed and should be verified against the project's release notes before upgrading. Until that version is applied, compensating controls must be specific: run the Toolbox process under a dedicated low-privilege OS account that can only read and write the exact files it needs, since the vendor explicitly positions allowedLocalRoots as a guardrail layered on top of file permissions rather than a replacement for them; restrict allowedLocalRoots to a directory that no attacker-controlled or tool-executable process can write into, because the bypass requires planting or referencing a symlink inside a root (trade-off: constrains legitimate upload/download targets and may break workflows that rely on shared scratch directories); and if the cloud-storage source is not required, do not enable it, which removes cloud-storage-upload-object and cloud-storage-download-object and the associated read/write primitive entirely (trade-off: loss of cloud storage integration). Note that these controls do not eliminate all residual risk: hard links created inside an allowed root to targets outside it remain readable even after the fix, and a time-of-check-to-time-of-use window persists for any principal that can write to an allowed root, so path swaps between validation and open remain theoretically possible. Setting allowedLocalRoots is not itself a mitigation if it is left unset, since omitting it allows every absolute path the server process can reach.
Affected VersionsENISA
Affected Packages
Source: OSV (Open Source Vulnerabilities)
Affects your stack
Affects 1 package in euvd
Checking this CVE against your own stacks and servers is part of the Basic plan and up.
Technical ContextAI · show details
The vulnerable component is the Go cloud-storage source in Google MCP Toolbox for Databases, specifically the validateLocalPath function in internal/sources/cloudstorage/cloudstorage.go that enforces the allowedLocalRoots configuration. The root cause is CWE-59 (Improper Link Resolution Before File Access, 'Link Following'), a variant of CWE-22 path traversal: the check compares the caller-supplied path against each configured root after only lexical normalization (cleaning the string) and does not call filepath.EvalSymlinks or equivalent before the file is opened. The pre-fix code therefore verified where a path appears to point rather than where it actually resolves. Because cloud-storage-upload-object reads a local file and cloud-storage-download-object writes one, a symlink placed inside an allowed root that targets a file or directory outside it can be used for both disclosure and overwrite of files the Toolbox process can reach. The upstream fix (PR #3810) adds a second comparison using cloudstoragecommon.ResolveSymlinks on both the path and each allowed root, requiring the path to stay inside a root both as written and after symlink resolution; the vendor documentation now states this explicitly. Notably, the resolved comparison also resolves the roots themselves so that a root legitimately reached through a symlink (for example /tmp on macOS or a symlinked workspace) still matches. The advisory notes two residual limitations that the fix does not close: hard links are indistinguishable from ordinary files and remain readable across the boundary, and the check runs immediately before the open, leaving a time-of-check-to-time-of-use window for a process that can write to an allowed root. If allowedLocalRoots is omitted entirely, all absolute paths the process can reach are permitted, which is a separate misconfiguration rather than this bypass. The affected package is identified by the wildcard CPE cpe:2.3:a:google:mcp_toolbox_for_databases:*:*:*:*:*:*:*:*.
Know when Mcp Toolbox For Databases gets its next vulnerability
- Watch products and get an email when something new is published
- Check this CVE against your own stack and servers
- Exploit and PoC references, threat intelligence from 22 sources
No credit card · 7-day full trial
Severity by source
CVSS:4.0/AV:N/AC:L/AT:N/PR:L/UI:N/VC:H/VI:H/VA:N/SC:N/SI:N/SA:N
Network-reachable tool API with authorized tool-execution permissions gives PR:L and AC:L; arbitrary file read and overwrite yield C:H/I:H, no availability claim so A:N, same authority context so S:U.
Primary rating from Vendor (Google).
CVSS VectorVendor: Google
DescriptionCVE.org
Improper link resolution (CWE-59 / CWE-22) in the allowedLocalRoots path validation in Google MCP Toolbox for Databases versions 1.2.0 through 1.9.0 allows a remote authenticated attacker with tool execution permissions to bypass directory boundary restrictions via symbolic links. Because path validation checks directories lexically without resolving symbolic links first, an attacker can access or overwrite arbitrary local files located outside the permitted root directories.
Executive ViewAI
Google MCP Toolbox for Databases versions 1.2.0 through 1.9.0 contain a path-resolution flaw that lets a user who already holds tool-execution permissions read or overwrite files anywhere on the host, defeating the allowedLocalRoots guardrail the vendor intended as a layered control. Because this component sits in the data-access path for AI and agent workloads and often runs with credentials to production data stores, a single over-privileged or compromised internal account could expose configuration secrets or corrupt operational files. No vendor patch is currently available, so protection depends on tightening authorization and OS-level file permissions in the interim.
No vendor-released patch identified at time of analysis. Interim mitigations: enforce OS-level file permissions as the authoritative boundary (the vendor describes allowedLocalRoots as a guardrail to be layered, not a substitute), run the toolbox as a dedicated least-privilege account with read-only and narrowly scoped filesystem mounts, isolate the service in a container with a restricted mount namespace, remove any symlinks present inside configured allowed roots and monitor for new ones, disable the cloud-storage-upload-object and cloud-storage-download-object tools where not required, and restrict tool-execution authorization to the fewest possible trusted identities.
Threat Intelligence Overview
How this decision was reached
The engine reads each signal below and applies a fixed list of rules from top to bottom. The first rule that matches sets the recommended action – like a statement, every line is shown.
What every action level means
SSVC AssessmentENISA
Priority Score
More in Mcp Toolbox For Databases
View allCross-origin data exposure in Google's MCP Toolbox for Databases stems from the SSE initialization handler unconditional
Missing Origin/Host header validation in Google's MCP Toolbox for Databases (Model Context Protocol server) prior to v0.
Path traversal in the HTTP tool URL builder of googleapis/mcp-toolbox allows unauthenticated remote attackers to escape
Server-side request forgery in Google's MCP Toolbox for Databases (googleapis/mcp-toolbox) versions 0.19.1 through 1.4.0
EUVD-2026-89186
GHSA-3gp8-hjh6-xf3r
NVD
CVE.org
EPSS
Vulnrichment
Exploit-DB