+ "details": "### Summary\n\nThis issue allows unintended local file exfiltration through LLM-controlled tool invocation, where sensitive files on the MCP server can be accessed and uploaded to an attacker-controlled endpoint without explicit user intent or sufficient isolation controls.\n\nPlaywright MCP exposes a `browser_file_upload` tool that accepts arbitrary absolute paths on the server's filesystem. Combined with the `browser_navigate` + `browser_take_screenshot` + `browser_click` + form-submission tool chain, an attacker who can influence the agent's prompt stream — directly, or indirectly via attacker-controlled content the agent is asked to read (indirect prompt injection) — can cause the MCP server to read any file readable by its process and exfiltrate it to an attacker-controlled HTTP endpoint as a standard multipart upload.\n\nIn locally-run deployments this enables arbitrary file disclosure from the server process. In hosted deployments where a single MCP server process is shared across tenants, the same primitive has the potential to cross tenant isolation, depending on deployment topology. The PoCs were exercised against single-host deployments; the multi-tenant implication is derived from the tool-chain semantics, not independently demonstrated.\n\n### Details\n\nThe MCP server registers a `browser_file_upload` tool whose `paths` parameter accepts arbitrary absolute filesystem paths. Before commit `d47197f4`, `paths` was not constrained to any workspace root, and navigation to `file://` URLs was not blocked. No validation prevented the server from reading and transmitting files such as `/etc/passwd`, container mount points, cached credentials from the Playwright profile directory, and any other file readable by the MCP process.\n\nThe tool is invoked solely based on LLM-driven tool selection. There is no user confirmation step between the MCP client's tool call and the server's filesystem read + HTTP upload. Any payload that successfully influences the LLM is sufficient to trigger exfiltration.\n\nA second path is implied by the MCP protocol itself: any party that can establish an MCP transport connection to the server can invoke `browser_file_upload` directly through the standard MCP `tools/call` interface, bypassing the LLM entirely. The upstream fix (`allowUnrestrictedFileAccess` default-false) addresses both paths, because the path restriction is enforced at the tool invocation layer regardless of caller.\n\nThis behavior is reachable under default configuration in affected versions, without requiring any non-default flags, elevated privileges, or explicit user confirmation.\n\n### Fix\n\nThe upstream fix introduces an `allowUnrestrictedFileAccess` configuration option (default `false`), which restricts filesystem access to workspace root directories and blocks `file://` navigation.\n\nFix commit: microsoft/playwright-mcp@d47197f41fb79a6db8d8f593e7548918c0872b47\n\nFirst patched npm release: `@playwright/mcp@0.0.55`.\n\n### Impact\n\n**Locally-run deployments.** Arbitrary file disclosure from the process running `@playwright/mcp`. MCP agents are typically run by developers under accounts with broad filesystem access, so this routinely includes SSH keys, cloud credentials, browser session stores, `.env` files, and project source.\n\n**Hosted deployments with shared MCP processes.** In deployments where a single MCP server process handles requests from multiple tenants without strict OS-level isolation, the same primitive enables cross-tenant data access. This implication follows from the absence of path restrictions and process-level isolation, and was not independently tested against a production multi-tenant deployment.\n\n### References\n\nFull advisory with PoC and timeline: https://github.com/mmzha2013/security-research/security/advisories/GHSA-fhw2-h46x-v2mj",
0 commit comments