système : OPÉRATIONNEL
← retour à tous les hacks
SUPPLY CHAIN MEDIUM NEW

Scans MCP propres, serveurs malveillants : ce que les scanners ratent

Pluto Security a conçu deux serveurs MCP nuisibles qui ont chacun passé au moins un des cinq scanners testés. Un scan propre est un indice, pas une décision de confiance.

2026-10-11 // 7 min affects: mcp, mcp-scanners, claude-code, cursor, vs-code

What is this?

Le 15 septembre 2026, Yotam Perkal et Eitan Chassid, de Pluto Security, ont publié « Malicious Servers, Clean Scans ». Ils ont construit deux serveurs Model Context Protocol (MCP) délibérément nuisibles et les ont soumis à cinq scanners MCP et skills : Cisco mcp-scanner, Snyk agent-scan, Ventrova sentinel-scan-cli, mcp-shield et NVIDIA SkillSpector. Chaque scanner a renvoyé un résultat propre ou sans alerte dans au moins une configuration testée.

Les deux serveurs se faisaient passer pour un simple outil météo, et l’utilisateur recevait toujours une réponse météo normale. L’un lisait des fichiers d’identifiants locaux et les envoyait à un collecteur. L’autre récupérait une commande auprès d’un second serveur, l’exécutait et renvoyait le résultat. Les tests se sont déroulés dans un environnement isolé avec de faux identifiants. Une précision : Pluto vend des produits de sécurité MCP, ce que l’article ne mentionne que brièvement en conclusion.

Une seconde source va dans le même sens. Un article arXiv du 16 septembre 2026 de Murali Ediga et Sudipta Chattopadhyay indique que sept outils tiers de sécurité MCP n’ont pas détecté des charges d’injection réparties sur plusieurs canaux.

How it works

Les serveurs ne cachaient rien d’ingénieux dans leurs métadonnées. Les noms, descriptions et schémas d’outils paraissaient bénins. La logique nuisible se trouvait dans le code des handlers, que beaucoup de scanners n’inspectent jamais. Pluto attribue les échecs à plusieurs lacunes récurrentes :

  • Contrôles limités aux métadonnées. Certains contrôles n’examinent que les noms, descriptions, schémas ou manifestes, qui ne contenaient rien de suspect.
  • Analyse incomplète. Le budget de prompt d’un analyseur de Cisco laissait trop peu de place aux éléments du serveur. La revue LLM de SkillSpector a ignoré un fichier trop volumineux : le même code noyé dans un gros bloc de texte inoffensif donnait « CAUTION / 0 » avec une couverture partielle.
  • Règles statiques fragiles. Les règles à base de mots-clés ou de syntaxe se contournent par des variantes équivalentes.
  • Indices dispersés. Des signaux liés étaient analysés dans des champs distincts, sans règle pour les relier.
  • Comportement fourni à l’exécution. La commande arrivait après le scan : aucun scan ne pouvait la voir.
  • Contenu hors périmètre. Le texte renvoyé par les appels d’outils échappe aux scans de la liste d’outils.

La revue LLM par défaut de SkillSpector a été la seule à détecter les deux serveurs avec une taille de fichier normale. L’analyseur comportemental de Cisco a renvoyé un résultat propre même pour un serveur témoin qui décrivait ouvertement son vol d’identifiants dans la description de son outil.

Why it matters

Les équipes traitent de plus en plus le verdict d’un scanner comme une barrière d’installation. Cette recherche montre qu’une barrière qui se dégrade silencieusement (fichiers ignorés, contexte tronqué, délais dépassés) signale quand même un succès. Elle rejoint aussi le constat antérieur de Trail of Bits sur les scanners de skills : un scanner est une cible fixe, et l’attaquant joue en second. Le risque est maximal lorsqu’un serveur MCP s’exécute avec accès aux clés SSH, aux identifiants cloud ou à la configuration Kubernetes d’un poste de développeur.

Defenses

  • Vérifiez ce que chaque scan a couvert. Considérez les fichiers ignorés, les délais dépassés ou l’analyse dégradée comme un échec de la barrière, non comme un succès.
  • Sélectionnez et épinglez. Utilisez des sources vérifiées, épinglez les versions ou les hashes de commit, et relisez les changements avant toute mise à jour.
  • Relisez tout le code exécutable, y compris le code chargé à l’exécution.
  • Testez les serveurs inconnus en isolation avec de faux identifiants, en observant leur activité fichiers et réseau.
  • Appliquez le moindre privilège aux fichiers, identifiants et sorties réseau de chaque serveur.
  • Surveillez après l’installation les changements de définition d’outils et le comportement des processus.
  • Combinez plusieurs types d’analyse et traitez un scan comme un indice, jamais comme une décision de confiance.

Status

ÉlémentDétail
Recherche publiéePluto Security, 15 septembre 2026 ; article arXiv, 16 septembre 2026
Scanners testésCisco mcp-scanner, Snyk agent-scan, Ventrova sentinel-scan-cli, mcp-shield, NVIDIA SkillSpector
Correctifs amontDeux pull requests SkillSpector approuvées, CI au vert ; deux pull requests Cisco ouvertes. Aucune fusionnée ni publiée à la date de rédaction
Exploitation dans la natureNon précisée

Sources