Le serveur Argo CD MCP — argocd-mcp, publié sous argoproj-labs — a reçu CVE-2026-82456 le 29 août 2026 à 15:30:21 UTC, avec un score de 10.0 à la fois sur CVSS 3.1 et CVSS 4.0. C’est le maximum permis par l’échelle. C’est aussi, sur le fond, quelque chose de déjà connu.
Le correctif précède la CVE de 18 jours
Les mainteneurs ont publié leur propre avis sur la faille identique le 11 août à 15:47:14 UTC, avec la mention « No known CVE », et ont livré le correctif dans la version v0.9.0 quinze minutes plus tôt, à 15:32:50 UTC le même jour. Ils lui ont eux-mêmes attribué un score de 10.0. L’enregistrement du 29 août montre simplement le système de numérotation du secteur rattrapant un correctif rendu public depuis plus de deux semaines.
Ce que le score ne dit pas
C’est là que le chiffre du titre devient trompeur. La vulnérabilité — classée CWE-1327, liée à une liaison sur une adresse non restreinte — concerne la version 0.8.0 lorsqu’elle est exécutée avec le transport HTTP ou SSE : le listener se liait à toutes les interfaces et acceptait des sessions MCP sans authentification. Mais ce transport n’est pas celui que l’on vous incite à utiliser par défaut. Les exemples d’installation du projet configurent stdio, qui n’est pas accessible sur le réseau. Un 10.0 décrit le pire cas pour une configuration que la documentation ne vous propose pas.
Le vrai problème de conception est ailleurs
La version 0.9.0 fait trois choses : elle lie par défaut le listener HTTP et SSE à 127.0.0.1, elle ajoute un MCP_AUTH_TOKEN distinct pour authentifier les appels entrants, et elle cesse de considérer la présence d’un identifiant Argo CD comme une forme de contrôle d’accès. Ce dernier point est la vraie leçon. ARGOCD_API_TOKEN est un identifiant d’authentification sortant — il permet au serveur de s’authentifier auprès de Argo CD. Il n’a jamais authentifié quiconque appelant le serveur. La version 0.8.0 est sortie le 11 juin, si bien que les opérateurs utilisant le transport réseau ont subi une fenêtre d’exposition de 61 jours.
Et, une fois encore, l’enregistrement est illisible pour les outils
Exactement comme pour l’avis Skyvern publié quatre minutes plus tôt, l’enregistrement d’avis GitHub pour CVE-2026-82456 contient un tableau structuré des vulnérabilités vide — aucune plage de paquets, aucune première version corrigée. Deux failles d’importance maximale ou quasi maximale sur des infrastructures d’agents sont tombées le même après-midi, et aucune ne peut être rapprochée automatiquement d’un lockfile.