Open actionable advisories and recorded vendor fixes. This public package view has no inventory attached and cannot establish whether your deployment is affected. A vendor fix never resolves your finding; verify your installed version and the source guidance.
Open advisories
2 actionable advisories, newest first. Withdrawn advisories and news are excluded. Coverage is partial.
I originally reported this through Google Bug Hunters. The Google Bug Hunters team said this is in OSS VRP scope but not reward-eligible due to the project tier, and asked me to file an issue or PR directly with this repository. I am reporting it privately here first because it is an unfixed security issue. 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…
Recommended action: Upgrade to 1.1.0 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
The chrome-devtools-mcp daemon writes its PID file with fs.writeFileSync() to a deterministic runtime path. On typical macOS environments, and on Linux sessions where $XDGRUNTIMEDIR is unset, that runtime path falls back to /tmp/chrome-devtools-mcp-<uid/daemon.pid. Because the write does not use ONOFOLLOW, a local low-privilege user on the same POSIX host can pre-create /tmp/chrome-devtools-mcp-<victimuid/daemon.pid as a symlink to a file writable by the victim. When the victim later starts daemon mode, fs.writeFileSync() follows the symlink and truncates the target file to the daemon PID string. This report is deliberately scoped to POSIX systems where the daemon falls back to /tmp: typical macOS environments and Linux sessions without $XDGRUNTIMEDIR. Windows is out of scope because the default temp directory is per-user and symlink creation has additional privilege requirements. Details Affected code: src/daemon/daemon.ts:38-42 src/daemon/utils.ts:49-68 The /tmp sticky bit…
Recommended action: Upgrade to 1.1.0 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.