Securing MCP Clients Against Phishing and Open Redirect Vulnerabilities
Balancing user-defined agent flexibility with robust OAuth redirect URI security protocols.
1The MCP Authentication Dilemma
Model Context Protocol (MCP) agents often require access to private data, such as S3 buckets. Standard OAuth flows rely on redirect URIs to return authorization codes. However, servers face a binary choice: either restrict connections to a pre-approved allowlist, blocking custom user agents, or remain open, creating significant phishing and security vulnerabilities.
2The Risks of Open Registration
A May 2026 study revealed that 95.8% of 119 tested MCP servers allowed arbitrary registration and redirect addresses. This flaw enables attackers to register malicious clients, tricking users into approving access. Once approved, the attacker intercepts the authorization token, effectively hijacking the user's account and gaining unauthorized access to sensitive data.
3Real-World Security Failures
Security incidents confirm these risks are not merely theoretical. In January 2026, Obsidian Security identified a vulnerability in Square’s MCP server where self-registration allowed redirecting merchant data to attacker-controlled endpoints. Similar issues were discovered in company SSO proxies, where attackers exploited open redirectors to steal 14-day refresh tokens via simple social engineering.
4The Open Redirector Problem
Beyond phishing, servers accepting any redirect URI become open redirectors. If a request fails validation, the server sends error messages to the provided address. Attackers can craft malicious links that bounce visitors to external sites using the trusted domain's hostname, a vulnerability explicitly described and warned against in the RFC 9700 standard.
5Limitations of Current Standards
The MCP specification delegates security policy to individual server operators, citing RFC 9700. While it suggests validating exact URIs, it lacks strict enforcement. Current registration methods, such as Client ID Metadata Documents (CIMD), verify who publishes a client but fail to confirm if the specific user actually intended to connect that client.
6A User-Centric Security Model
Stream Vessel addresses this by implementing a tiered trust system. It maintains a global operator allowlist for standard clients while enabling individual users to register up to ten trusted HTTPS redirect addresses for their own accounts. This approach balances the need for custom agent flexibility with strict, per-user security boundaries.
7Preventing Unauthorized Redirects
The system delays redirect validation until the authorization page, where the user identity is confirmed. No code or error is ever sent to an unverified address. This design mitigates risks like CVE-2026-42230, where denial of consent previously triggered a redirect to an attacker's address, ensuring that even failed requests remain contained.
8Balancing Access and Defense
While this model does not eliminate social engineering, it provides essential guardrails. By requiring explicit user trust for custom addresses and providing clear warnings, the system binds potential damage. This strategy acknowledges that users require full access for their agents, prioritizing user-controlled security over restrictive, one-size-fits-all server policies.