EUVD-2026-39104
GHSA-8qf9-62x2-82pp
Severity by source
AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:H/A:L
C upgraded to H from C:N because upload_file demonstrably exfiltrates out-of-root file contents; all other metrics consistent with local, low-privilege symlink placement.
Primary rating from Vendor (GitHub_M).
CVSS VectorVendor: GitHub_M
Lifecycle Timeline
3DescriptionCVE.org
Chrome DevTools for agents (chrome-devtools-mcp) lets your coding agent control and inspect a live Chrome browser. From 0.24.0 until 1.1.0, McpContext.validatePath() enforces workspace roots by checking whether path.resolve(filePath) textually falls under one of the configured root paths. path.resolve() does not canonicalize symbolic links. As a result, a symlink inside a configured workspace root can point to a file outside that root, pass validation, and then be followed by downstream file read/write operations. This bypass applies even when the MCP client correctly declares the roots capability with a non-empty list. It is separate from the documented legacy behavior where missing roots capability allows all paths. The practical impact is a workspace-boundary bypass. In the write direction, filePath-writing tools can overwrite out-of-root files through an in-root symlink. In the read direction, upload_file can read through the symlink and send the file to the currently selected web page. This vulnerability is fixed in 1.1.0.
AnalysisAI
Symlink-based workspace boundary bypass in chrome-devtools-mcp (versions 0.24.0 through before 1.1.0) allows a local low-privileged actor - including an AI coding agent itself - to read or overwrite files outside the configured workspace root. The McpContext.validatePath() function performs only a lexical prefix check on the resolved path and never canonicalizes symbolic links, so an in-root symlink whose target lies outside the root passes validation and causes downstream file operations to act on the real out-of-workspace target. No public exploit has been identified and the CVE is not listed in CISA KEV; a vendor-released patch is available in version 1.1.0.
Technical ContextAI
chrome-devtools-mcp is a Node.js MCP (Model Context Protocol) server package (CPE: cpe:2.3:a:chromedevtools:chrome-devtools-mcp:*:*:*:*:*:*:*:*) that exposes Chrome browser control and inspection capabilities to AI coding agents. The vulnerability is a classic CWE-22 (Improper Limitation of a Pathname to a Restricted Directory) variant rooted in the behavior of Node.js path.resolve(): it normalizes path separators and resolves . and .. components lexically but does NOT follow or resolve symbolic links. McpContext.validatePath() calls path.resolve(filePath), then checks whether the result begins with one of the configured root path strings. A symlink residing at workspace/link whose POSIX target is /etc/shadow produces a resolved path of /workspace/link - which passes the prefix check - but when downstream fs operations open the path the OS kernel follows the symlink to the real target. This applies to both read operations (upload_file exfiltrates the symlink target's content to the active web page) and write operations (filePath-writing tools overwrite the out-of-root target). The bypass is distinct from the documented legacy behavior where an MCP client that omits roots capability altogether allows all paths; here the roots capability IS correctly declared and populated, but the symlink escapes the declared boundary.
RemediationAI
Upgrade chrome-devtools-mcp to version 1.1.0, the vendor-released patch that fixes validatePath() by canonicalizing symbolic links before performing the workspace root prefix check. Details are in the security advisory at https://github.com/ChromeDevTools/chrome-devtools-mcp/security/advisories/GHSA-8qf9-62x2-82pp. If immediate upgrade is not possible, apply OS-level controls to prevent symlink creation within workspace directories: on Linux, mount workspace volumes with the nosymfollow option (available in kernels 5.10+) to cause symlinks to fail at the VFS layer rather than be followed - note this will break any legitimate tooling that relies on symlinks inside the workspace. Alternatively, enforce a seccomp or AppArmor/SELinux policy that denies symlink(2) calls by the agent process. Disabling the upload_file tool in the MCP configuration mitigates only the confidentiality (read) direction and does not address the write-direction bypass. Audit existing workspace directories for unexpected symbolic links before relying on compensating controls, as malicious symlinks may have already been placed.
Same weakness CWE-22 – Path Traversal
View allSame technique Path Traversal
View allShare
External POC / Exploit Code
Leaving vuln.today