Advisory published for a roots boundary bypass in Google's Chrome DevTools MCP server, fixed three months earlier
The GitHub Advisory Database published GHSA-8qf9-62x2-82pp on 2026-08-17, covering CVE-2026-53766 in chrome-devtools-mcp. The server enforced client-declared workspace roots by comparing resolved path text, which does not follow symbolic links, so a symlink inside a root could reach files outside it for both reads and writes. Google fixed it on 2026-05-26 in v1.1.0 as an ordinary release bullet; the NVD record dates from 2026-06-24.
The GitHub Advisory Database published GHSA-8qf9-62x2-82pp on 2026-08-17, the first public write-up of CVE-2026-53766 in chrome-devtools-mcp, the MCP server Google maintains for driving a live Chrome browser from a coding agent. The server ranks fourth on the 2026-08-14 MCP 500.
The flaw is in how the server enforced workspace boundaries.
McpContext.validatePath() took the client-declared roots, resolved
the requested path with path.resolve(), and checked whether the result
started with a root path. path.resolve() normalizes text such as .
and ..; it does not call realpath(), so it does not follow symbolic
links. A symlink sitting inside a declared root therefore passed the
check while pointing anywhere on the filesystem, and the file operations
downstream followed it. The advisory is explicit that this applied even
when a client declared roots correctly with a non-empty list, which
separates it from the documented behaviour where a client that declares
no roots gets no restriction.
Both directions were affected. Tools that write to a filePath could
overwrite files outside the root, and upload_file could read through
the symlink and attach the target to a file input on the page the agent
was driving. The advisory lists credentials files, SSH keys and project
secrets as the kind of target reachable if such a symlink exists, and
notes the upload path leaves no record of the canonical file.
Exploitation depends on a workspace-internal symlink already existing or
being creatable by something the user trusts. The reporter proposed a
network-vector estimate on that basis; the vector recorded against the
CVE is local, AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:H/A:L, scoring 6.1
medium.
The fix long predates the advisory. Pull request #2127, "use realpath for MCP roots validation", merged 2026-05-26 and shipped the same day in v1.1.0, listed among that release's fixes with no security framing. NVD published the CVE record on 2026-06-24. Affected versions run from 0.24.0 through 1.0.1; current is 1.7.0, released 2026-08-10. Credit for the report goes to enable7997, who states in the advisory that Google Bug Hunters ruled the finding in scope for its open-source program but not reward-eligible, and asked for it to be filed with the project directly.
Related servers and clients
- Chrome DevTools MCP - server
Related publishers
How was this verified, and what are the sources?
Published · last verified · confidence 1.00.
- GitHub advisory GHSA-8qf9-62x2-82pp (published 2026-08-17T21:56Z, severity moderate, CVSS 3.1 6.1) - "chrome-devtools-mcp: validatePath() does not canonicalize symlinks before enforcing roots"; states path.resolve() only normalizes path text and does not call realpath(), that the bypass applies "even when the MCP client correctly declares the roots capability with a non-empty list", that filePath-writing tools can overwrite out-of-root files and upload_file can read through the symlink and send the file to the selected web page; npm chrome-devtools-mcp >= 0.24.0 <= 1.0.1, first patched 1.1.0; credited to reporter enable7997 - accessed
- chrome-devtools-mcp v1.1.0 release notes (published 2026-05-26T15:42Z) - lists "use realpath for MCP roots validation (#2127)" among its fixes, with no security framing - accessed
- Pull request #2127 "fix: use realpath for MCP roots validation" - merged 2026-05-26T13:09Z as commit 176eb695137d9c46a61e2d4d5571880c5145cf46 - accessed
- NVD record for CVE-2026-53766 (published 2026-06-24, status Analyzed, source security-advisories@github.com, CWE-22) - CVSS 3.1 6.1 medium (AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:H/A:L), affected from 0.24.0 until 1.1.0 - accessed