A desktop client uses a local proxy service that spawns stdio MCP servers on request, authenticated by a token the client holds. An attacker achieves XSS in the client through a malicious authorization URL. Why is this dangerous, and what mitigates it?

The security best practices describe stdio transport security in proxy scenarios. The stdio transport itself is not inherently vulnerable, but a local proxy that spawns MCP servers as child processes creates an escalation path. An attacker who achieves XSS or other client-side code execution, for instance through a script-scheme authorization URL a malicious server supplied, can read the proxy authentication token from the client's environment, make authenticated requests to the proxy, and have it spawn arbitrary commands with the user's privileges. Mitigation starts with preventing the vulnerability: validate authorization URLs and allow only http and https schemes, avoid shell execution when opening URLs, use Content Security Policy, and sanitise server input. Proxies should then sandbox or containerise spawned processes, restrict file system access and require extra authorization for dangerous commands. Blaming stdio and switching transports fails because the guidance states stdio is not inherently vulnerable; the problem is a proxy that will launch anything an authenticated caller asks for. Calling it mere data leakage fails by concept, since annotations are untrusted hints and cannot restrict a newly spawned process. Short token lifetimes fail because XSS runs inside the client and can read the current token. Exam caveat: this applies only to proxy architectures. Operational check: confirm the proxy refuses commands outside an allowlist.