Breach anatomy
Authorization endpoint from untrusted metadata run as a command
mcp-remote, the proxy that lets desktop MCP clients reach remote servers, discovers the authorization server from the MCP server it was pointed at and hands the metadata's authorization_endpoint to the operating system to open in a browser. A hostile or hijacked server could answer with a value that was not an https URL, and the proxy passed it on unchecked, which on the client machine led to command execution. Every endpoint an authorization server advertises must be https, and a client must refuse metadata that says otherwise before it acts on it.
- Class
- Untrusted metadata
- Disclosed
- Fixed
- mcp-remote 0.1.16
- Affects
- mcp-remote 0.0.5 to 0.1.15
- Desktop MCP clients that connect to an untrusted or plain-http MCP server through it
- Sources
The control that was missing
All endpoints served over HTTPSAuthorization serverMUST
Every authorization server endpoint listed in its metadata uses HTTPS.
Security Considerations › Communication SecurityMCP Authorization 2026-07-28
Listed servers under MCP Authorization 2026-07-28: 34 supported, 0 partial, 0 unsupported, 2 unknown, 3 not applicable.
Replay in the explorer
The MCP server Alex's host was pointed at is hostile or hijacked. It names an authorization server the attacker controls, whose metadata lists an authorization_endpoint that is not an https URL. The client hands that value to the operating system to open, as it would a web address, without checking the scheme first. What should have been a browser navigation to a consent screen becomes whatever the operating system does with that string. This is the pattern behind CVE-2025-6514.