Contexte et problème

Les serveurs MCP (Managed Cloud Platform) utilisent le flux OAuth standard : un client s’enregistre, indique une URI de redirection, l’utilisateur approuve, puis le serveur renvoie un code d’autorisation à cette adresse. Historiquement, les opérateurs de serveurs limitent les URI à une liste blanche globale (ex. Claude, ChatGPT, Cursor, VS Code). Cette contrainte empêche les agents autonomes – bots Slack, services VPS ou clients développés en interne – d’utiliser leurs propres points d’entrée, car l’enregistrement renvoie l’erreur invalid_redirect_uri. L’alternative, ouvrir la liste à n’importe quelle URI, crée un open redirector exploitable pour du phishing.

Scénario d’attaque et données d’étude

Une étude de mai 2026 a analysé 119 serveurs MCP : 114 (95,8 %) acceptaient des valeurs redirect_uri arbitraires provenant d’enregistrements anonymes. L’attaque typique se déroule en quatre étapes : (1) enregistrement d’un client factice avec https://evil.example/cb, (2) envoi d’un lien /oauth/authorize légitime à l’utilisateur, (3) approbation du consentement réel, (4) réception du code d’autorisation sur le domaine malveillant, qui est ensuite échangé contre un jeton d’accès. PKCE ne bloque pas ce vecteur, car le client initiateur est l’attaquant. Un incident réel a été rapporté en janvier 2026 contre le serveur MCP de Square : l’enregistrement ouvert a permis à un acteur de récupérer le profil marchand, les transactions et les coordonnées bancaires d’un utilisateur en un seul clic. La correction de Square n’a concerné que les nouveaux clients, laissant les anciens vulnérables.

Spécifications et exigences RFC

Le MCP spec cite explicitement le risque d’enregistrement non authentifié et impose que les serveurs d’autorisation valident les URI de redirection exactes. RFC 9700, section 4.11.2, précise que les serveurs « MUST » valider les URI et « SHOULD » ne rediriger automatiquement que vers des domaines de confiance. La spécification introduit le concept de Client ID Metadata Document (CIMD), où l’identifiant du client est une URL pointant vers un document listant les URI autorisées, mais cela ne résout pas le problème d’enregistrement anonyme.

Solution proposée par Stream Vessel

Stream Vessel conserve la liste blanche globale (incluant les boucles locales localhost ou 127.0.0.1) et ajoute une couche de confiance par utilisateur. Chaque compte peut enregistrer jusqu’à dix URI HTTPS précises via l’interface « Trusted app addresses ». Le processus d’enregistrement accepte initialement n’importe quelle URI HTTPS ; la validation réelle se fait lors de la page d’autorisation, où le serveur compare l’URI demandée à la liste personnelle de l’utilisateur. Si l’adresse n’est pas approuvée, l’utilisateur voit un message d’erreur explicite au lieu d’une redirection silencieuse, éliminant ainsi le vecteur d’open‑redirect. Cette approche respecte les exigences RFC tout en offrant la flexibilité nécessaire aux développeurs d’applications autonomes.

https://agent.yourhost.example/callback