Vulnérabilités de sécurité des serveurs MCP en 2026 :
30 CVE, aucune authentification, aucun chiffrement

Entre janvier et février 2026, des chercheurs en sécurité ont divulgué 30 CVE affectant des serveurs Model Context Protocol (MCP) — la couche d'infrastructure qui relie les assistants de codage IA aux bases de données, API et systèmes de fichiers. La sévérité la plus élevée a atteint CVSS 9.6 (critique), permettant une exécution de code à distance sans authentification. C'est la crise de sécurité que les développeurs d'IA agentique doivent comprendre avant qu'elle n'atteigne la production.

What is MCP and why does it matter for security?

Model Context Protocol is Anthropic's open standard for connecting AI assistants to external tools and data sources. In practice, an MCP server is a local or remote process that your AI coding assistant (Cursor, Claude Desktop, VS Code with GitHub Copilot, Windsurf, Cline) communicates with via JSON-RPC to call tools like "read this file", "query this database", "fetch this API endpoint".

The security problem is structural. MCP was designed for developer convenience, not for production security. The specification has no built-in authentication mechanism, no transport encryption requirement, and no permission scoping standard. Every security control is left as an implementation detail — and many implementations skip them entirely.

Les 30 CVE : ce qui a été découvert

Des chercheurs en sécurité de plusieurs entreprises ont mené des audits systématiques de serveurs MCP populaires et du protocole lui-même entre janvier et février 2026. Les 30 CVE divulguées se répartissent en six catégories :

Why 38% of MCP servers have no authentication

The authentication gap is not developer negligence — it is a documentation and design problem. The official MCP specification does not mandate authentication, and the reference implementation examples do not include it. Developers following the quickstart documentation ship unauthenticated servers because the documentation does not tell them otherwise.

The situation is compounded by the deployment model. Most MCP servers run locally — on the developer's workstation, on localhost, in a Docker container. The implicit assumption is that local access equals trusted access. This assumption breaks in three common scenarios:

• Multi-user development environments (shared cloud VMs, pair programming setups) where "localhost" is accessible to multiple users
• Browser-based attacks where a compromised web page makes requests to 127.0.0.1:3000 from inside the browser sandbox
• Malware on the developer machine that discovers and communicates with MCP servers to extend its capabilities

Remote MCP deployments — where the server runs on a cloud host and the AI assistant connects via HTTPS — are rarer but face the full spectrum of web application vulnerabilities, compounded by the lack of standard auth in the MCP spec.

The PII risk in unprotected MCP deployments

MCP servers by design have access to developer context: the codebase, the database connection strings, the API keys, the customer data files. This is what makes them powerful. It also makes them high-value targets.

When an AI coding assistant calls an MCP server to query a database or read a file, it may be passing personal data — customer names, email addresses, financial records — through the MCP JSON-RPC transport. If that transport is unauthenticated and unencrypted, any observer on the local network (or any process on the local machine) can read that data.

Les CVE d'empoisonnement d'outil sont particulièrement dangereuses pour les données personnelles. Un attaquant capable d'injecter une description d'outil malveillante dans un serveur MCP — par exemple en modifiant un fichier de configuration MCP partagé dans un dépôt — peut ordonner à l'assistant IA de chaque développeur d'inclure des données sensibles dans son prochain appel d'outil sortant. Le développeur ne voit jamais l'exfiltration ; cela ressemble à un comportement normal de l'assistant IA.

Liste de contrôle pour le durcissement de la sécurité MCP

Tant que la spécification MCP n'est pas mise à jour pour inclure une authentification obligatoire et une sécurité du transport, les développeurs doivent implémenter des contrôles au niveau de la couche de déploiement. Voici la liste de contrôle minimale pour durcir les déploiements MCP en production :

• Authentification par jeton sur chaque point de terminaison — ajoutez une validation par jeton bearer sur toutes les routes du serveur MCP. Générez un secret aléatoire de 32 octets au démarrage, stockez-le uniquement dans des variables d'environnement, et validez-le à chaque requête. Ne le codez jamais en dur.
• TLS pour tous les déploiements distants — si votre serveur MCP ne s'exécute pas sur localhost, il doit utiliser HTTPS. Utilisez Let's Encrypt ou un certificat géré. Ne déployez jamais le MCP en HTTP non chiffré vers un hôte distant.
• Liaison à localhost uniquement — les serveurs MCP locaux doivent se lier à 127.0.0.1, et non à 0.0.0.0. Se lier à toutes les interfaces expose le serveur à l'ensemble du réseau local.
• Intégrité des descriptions d'outils — si votre serveur MCP charge des descriptions d'outils depuis des sources externes (fichiers de configuration, URL distantes, saisies utilisateur), validez-les et nettoyez-les avant utilisation. N'exécutez jamais de descriptions d'outils provenant de sources non fiables sans révision.
• Principe du moindre privilège pour les outils — chaque outil MCP doit disposer des permissions minimales requises. Un outil de lecture de fichiers ne doit pas avoir de permissions d'écriture. Un outil de base de données doit utiliser une connexion en lecture seule pour les opérations de lecture.
• Anonymisation des données personnelles au niveau du protocole — faites transiter toutes les entrées et sorties MCP par un proxy conscient des données personnelles (comme le serveur MCP d'anonymize.dev) qui supprime les données personnelles avant qu'elles n'entrent dans le contexte du modèle IA et avant qu'elles n'apparaissent dans les paramètres d'appel d'outil.
• Journalisation d'audit des appels d'outil — journalisez chaque appel d'outil avec l'horodatage, le nom de l'outil, l'identité de l'appelant (si authentifié) et un hachage des paramètres (pas les paramètres complets, qui peuvent contenir des données sensibles). Surveillez les schémas d'appel d'outil anormaux.
• Fixation des dépendances et contrôles d'intégrité — les paquets de serveurs MCP sont des dépendances npm/pip. Fixez des versions exactes et vérifiez les sommes de contrôle. La surface d'attaque de la chaîne d'approvisionnement des outils MCP n'est actuellement pas auditée.
• Instances MCP distinctes par projet — ne réutilisez pas une configuration de serveur MCP unique pour des projets ayant des niveaux de sensibilité des données différents. Un serveur ayant accès aux données clients de production ne doit pas servir le même contexte d'agent qu'un bac à sable de développement.
• Veille régulière des CVE — abonnez-vous aux avis de sécurité GitHub de @modelcontextprotocol ainsi qu'aux avis de sécurité des paquets concernés (@modelcontextprotocol/server-*, paquets communautaires). La vague de 30 CVE est la première, pas la dernière.

Comment anonymize.dev comble la faille de sécurité structurelle du MCP

Le serveur MCP d'anonymize.dev fonctionne comme un proxy de confidentialité dans la chaîne du protocole MCP. Plutôt que de connecter votre assistant IA directement à vos outils, vous acheminez la connexion via le serveur MCP d'anonymize.dev, qui :

1. intercepte tous les paramètres d'appel d'outil entrants et les analyse à la recherche de données personnelles à l'aide de plus de 267 détecteurs de types d'entités couvrant 48 langues
2. remplace les données personnelles identifiées par des jetons structurés ([PERSON_1], [EMAIL_1], etc.) avant transmission à l'outil sous-jacent
3. intercepte toutes les réponses d'outil et les désanonymise avant de les renvoyer à l'assistant IA
4. maintient un magasin de correspondances de session chiffré afin que la désanonymisation aller-retour soit sans perte

Cette architecture signifie que même si le serveur MCP sous-jacent est compromis — par empoisonnement d'outil, traversée de chemin ou accès non authentifié — l'attaquant ne voit que des jetons anonymisés, pas de véritables données personnelles. La cible d'exfiltration la plus précieuse (les données personnelles) est structurellement absente de la couche protocolaire.

tool_call("query_db", {"where": "email = 'alice@company.com'"})

tool_call("query_db", {"where": "email = '[EMAIL_1]'"})

L'approche d'anonymize.dev n'élimine pas le besoin d'authentification et de TLS — ces contrôles doivent tout de même être implémentés. Mais elle apporte la défense critique au niveau de la couche de données que la spécification MCP elle-même ne peut pas imposer : garantir que même un déploiement MCP entièrement compromis n'a aucune donnée personnelle à exfiltrer.