Vulnérabilités de sécurité du MCP : vérifiez que votre système est concerné avant d'appliquer le correctif

Lorsqu’une vulnérabilité MCP apparaît dans votre flux d’actualités, la première question opérationnelle n’est pas « quelle est la gravité de cette alerte ? », mais : cet avis concerne t il un composant qui est effectivement en cours d’exécution dans mon chemin d’agent ? Répondez à cette question avant de lancer une attaque, de mettre à jour en masse tous les paquets ou de considérer qu'un scan sans anomalie est suffisant. Un verdict défendable s'appuie sur cinq éléments de preuve : 1. l'identifiant exact de l'avis et du paquet ; 2. la version installée et lancée ; 3. le résultat de l'éditeur de l'avis concernant la plage concernée ; 4. l'accessibilité du point d'entrée vulnérable et toute mesure d'atténuation temporaire ; 5. un outil de contrôle post remédiation ainsi qu'un justificatif attestant du résultat escompté de la tâche. Cette jointure génère un petit ensemble d'états utiles : absent , unknown , not affected , affected not reachable , exposed , patched unverified , remediation regression ou remediated . Elle empêche également deux raccourcis dangereux : considérer la présence d'un paquet comme une exposition confirmée, et considérer une commande de mise à jour réussie comme une récupération. Définissez la jointure d'exposition avant de choisir la réponse Un catalogue de vulnérabilités est utile pour le dépistage, mais il ne constitue pas votre inventaire d'exécution. L'avis de sécurité peut mentionner un paquet qui n'apparaît que dans un fichier de verrouillage, un environnement abandonné, une couche de conteneur qui n'est jamais lancée ou une dépendance de développement transitive. Le cas inverse est encore pire : un client MCP peut lancer un paquet via un wrapper ou une installation globale que l'analyse de votre référentiel n'a jamais inspectée. Récupérez les éléments de preuve provenant de l'environnement d'exécution hébergeant le processus MCP. Ne téléversez pas les invites, les arguments d'outils, les jetons, les chemins d'accès absolus ni les données métier. Voici à quoi peut ressembler un rapport succinct : Le code matchStatus doit provenir d'un gestionnaire de paquets, d'un outil SBOM ou d'un flux d'alertes structuré prenant en charge la syntaxe des versions de l'écosystème. Ne comparez pas les chaînes de version d'un point de vue lexical. L'alerte GitHub examinée pour mcp remote , par exemple, indique que = 0.0.5, < 0.1.16 est concerné et que 0.1.16 est la première version corrigée. L'avis examiné concernant @modelcontextprotocol/server filesystem comprend à la fois une plage historique et une ligne basée sur les dates, 2025.7.1 étant la première version corrigée de cette ligne. Un comparateur écrit à la main n'est pas l'outil le plus adapté pour normaliser ces deux schémas. Les informations relatives au paquet et à la version ne permettent toujours pas de déterminer l'accessibilité. La version actuelle MCP : bonnes pratiques en matière de sécurité illustre pourquoi la configuration est importante. Son analyse dite « du fonctionnaire désorienté » énumère plusieurs conditions qui doivent être réunies, notamment l'utilisation par un proxy d'un identifiant client statique tiers, l'enregistrement dynamique des clients, un cookie de consentement et l'absence de consentement individuel par client. Les mêmes recommandations et le Spécification d'autorisation MCP interdire le transfert de jeton et exiger que le serveur de ressources vérifie qu'un jeton a bien été émis pour celui ci. Ces contrôles devraient prendre la forme de champs dans un rapport spécifique à l’exposition, et non d’une simple case à cocher générique « sécurité activée ». Pour un avis d’autorisation, il convient de recueillir les informations relatives à la validation du public cible, à la correspondance des redirections, à la propriété du consentement et au comportement du proxy. Pour un avis concernant le système de fichiers, il faut recueillir la version du serveur lancé, les répertoires racine autorisés, la surface d’outils accessible, ainsi que la mesure d’atténuation exacte qui rend le point d’entrée affecté indisponible. Pour un avis concernant une injection de commande, collectez les informations relatives au wrapper client, à la version, à la limite de confiance du serveur distant, ainsi que la possibilité d’invoquer ou non cet itinéraire de connexion. Le composant concerné dont le point d'entrée a été vérifié comme étant désactivé est affected not reachable , et non not affected . Il s'agit d'un élément de preuve utile pour la maîtrise du risque, mais celui ci a une durée de validité limitée. Enregistrez le nom du responsable et la date limite pour l'application du correctif, car une modification de la configuration, une annulation du déploiement ou l'ajout d'un nouveau client pourrait rendre ce chemin à nouveau accessible. Utilisez un classificateur sans contenu, pas un exploit Il n'est pas nécessaire que la charge utile soit malveillante pour traiter l'incident. La règle de décision suivante est délibérément prudente : Les noms d'états indiquent la décision suivante : État Ce que démontrent les éléments de preuve Action suivante limitée absent Le composant en question n'est pas présent à la limite d'exécution inspectée. Enregistrer l'étendue de l'inventaire et clôturer pour cette zone unknown L'identité, la version, la correspondance de l'avis ou l'accessibilité sont manquantes ou en conflit. Conserver l'incertitude ; remplir le premier champ manquant not affected Le composant installé ne fait pas partie de la gamme concernée par l'éditeur. Conserver la source et la fraîcheur ; ne pas déduire qu'un produit est protégé simplement parce que le nom de l'emballage est similaire affected not reachable Le code concerné existe, mais le point d'entrée indiqué est bloqué par un confinement vérifié Maintenir le confinement, désigner un responsable du correctif et définir une date d'expiration exposed La version concernée et le point d'entrée accessible coïncident Limiter l'accès, révoquer les autorisations superflues et appliquer les correctifs patched unverified La version est sortie de la zone de couverture, mais les preuves de son bon fonctionnement sont incomplètes Exécutez un test de sécurité à l'aide d'un outil « canary » et vérifiez que la destination correspond bien à celle attendue. remediation regression Le correctif ou la mesure de confinement a endommagé l'outil ou le résultat requis. Limitez l'impact de la voie risquée ; rétablissez la compatibilité ou utilisez une version de secours validée remediated La version, le comportement sécurisé de l'outil et le résultat escompté sont tous validés Vérifiez la fraîcheur et clôturez l'opération à l'aide du reçu de preuve J'ai appliqué cette règle à huit cas sans contenu, un pour chaque État. Les huit cas correspondaient au résultat attendu. C'est le cas « gênant » qui est le plus instructif : @modelcontextprotocol/server filesystem figure dans la version corrigée mentionnée dans l'avis de sécurité, mais le test de sécurité de l'outil échoue. Le classificateur renvoie remediation regression , et non remediated . Cette distinction est importante, car les interventions de sécurité peuvent entraîner un incident affectant le bon fonctionnement de l'agent. Une mise à jour des dépendances peut modifier une commande de lancement, un schéma de capacités, une racine autorisée, un flux OAuth ou la compatibilité avec les clients. Le code vulnérable peut avoir disparu alors que le fonctionnement requis de l'agent reste perturbé. Cette attestation présente certaines limites. Elle ne prouve pas qu’une faille inconnue ne puisse pas affecter le composant. Elle ne remplace pas les preuves techniques en cas de suspicion de compromission. Elle repose également sur l’identification précise du paquet et sur des données d’alerte à jour ; en cas de divergence entre deux sources, renvoyez le code unknown et conservez les deux références. Le Fiche NVD pour CVE 2025 6514, par exemple, fournit une entrée datée supplémentaire concernant la vulnérabilité d'injection de commande mcp remote , mais la plage de paquets doit tout de même correspondre à celle de l'avis de sécurité examiné utilisé par votre outil de correspondance. Appliquer un correctif selon une séquence qui préserve l'intégrité de l'agent Les mesures de confinement et d'assainissement nécessitent des autorisations distinctes, car leurs rayons d'action diffèrent. Voici une séquence pratique : 1. Enregistrer les informations d'identification. Notez l'identifiant de l'avis, le package, la version déployée, le propriétaire du client ou du serveur, ainsi que l'heure de l'événement. 2. Contenir le chemin d'accès indiqué. Désactiver le serveur, la connexion à distance, l'outil ou la voie d'autorisation vulnérable en apportant la modification réversible la plus minime possible. 3. Limiter les privilèges. Retirez les droits d'accès et autorisations superflus associés à ce composant. Ne procédez à la rotation d'un secret que lorsque des indices de compromission ou la politique en place l'exigent ; la rotation peut détruire des preuves utiles et provoquer des interruptions de service sans rapport avec le problème initial. 4. Installez le correctif fourni par l'éditeur. Utilisez la version corrigée indiquée, et non une version récente choisie au hasard, et conservez le résultat généré par le gestionnaire de paquets. 5. Redémarrez le véritable propriétaire. La mise à jour d'un fichier de verrouillage ou d'une balise d'image ne suffit pas si un client agent en exécution depuis longtemps détient toujours la propriété de l'ancien processus. 6. Effectuez un test de sécurité de l'outil. Utilisez une cible synthétique disposant des privilèges minimaux. Ne relancez pas l'exploit et ne dirigez pas le « canary » vers les données de production. 7. Vérifiez le résultat final. Assurez vous que le fichier, le billet, l'enregistrement, le message ou tout autre résultat attendu existe bien et est correct. 8. Surveillez la fenêtre de stabilité. Vérifiez que le composant reste accessible comme prévu, qu'il ne retombe pas dans la plage de vulnérabilité et qu'il ne présente pas de défaillances répétées après l'application du correctif. Il convient de distinguer clairement le test de l'outil du reçu de résultat. Un outil de système de fichiers peut renvoyer un message de réussite alors qu'il a écrit dans la racine autorisée incorrecte. Un outil de gestion des tickets peut accepter une demande alors que l'enregistrement est rejeté par la suite. Un transport MCP peut rester opérationnel alors que le livrable de l'agent est manquant. Le premier reçu prouve que la fonctionnalité réparée peut s'exécuter en toute sécurité ; le second prouve que le travail de l'utilisateur est bien parvenu à destination. Ne clôturez l'incident que lorsque tous les éléments de preuve les plus solides disponibles concordent : l'avis de sécurité ne correspond plus au composant déployé, la voie auparavant vulnérable est maîtrisée, le « canary » de sécurité passe avec succès et le résultat escompté est atteint. Si un champ est obsolète ou contradictoire, conservez l'état explicite au lieu de le marquer en vert. Sidewisp est actuellement en préversion privée. Son orientation produit consiste à fournir une couche de surveillance pour les environnements d'exécution d'agents existants : mettre en évidence des preuves concrètes, distinguer les états « en cours d'exécution » de ceux « en attente » ou « bloqués », maintenir la validation humaine à la limite de l'action et vérifier les résultats après intervention. L'expérience publique actuelle est une démonstration en accès anticipé, et non un scanner MCP, un adaptateur de surveillance ou un moteur de récupération automatisé commercialisés.