A CVSS 10.0 MCP bug came down to two defaults: listen on every interface, make auth optional. In UI-TARS-desktop's mcp-http-server (CVE-2026-81735), the listen address defaulted to '::' when no host was given, and the authentication middleware was applied only when a caller supplied it. The commands and filesystem servers passed no middleware, so neither required a credential. run_command handed its string to child_process.exec, which meant any unauthenticated client that could reach the port could run arbitrary commands as the user running the server. The fix made 127.0.0.1 the default. The MCP Python SDK's OAuth client (GHSA-qx49-fqc8-xw99, high 7.5) let the MCP server a client connected to decide where the client's OAuth credentials were sent. A malicious or compromised server could steer the client_secret, authorization code and PKCE code_verifier to a token endpoint of its choosing. Patched in 2.2.0 and 1.30.0. If you use PrivateKeyJWTOAuthProvider, pass issuer explicitly. mcp-remote 0.1.32 through 0.1.38 (CVE-2026-51994, critical 9.1) is vulnerable to SSRF via the resource_metadata URL extracted from a remote MCP server's WWW-Authenticate header. Three advisories with one shared pattern: convenience defaults that skip identity checks. Banks learned this with API defaults years ago. Bind loopback, require auth, pin the issuer, validate discovery URLs. In my experience that short list is how MCP servers actually get hardened in regulated environments, and none of it is exotic. For anyone running MCP servers in production, which of those four does your setup actually enforce today?
