Liste de contrôle de durcissement de sécurité MCP : 1,467 serveurs exposés et les contrôles qui les ferment

Trend Micro a scanné internet et trouvé 1 467 serveurs MCP laissés ouverts — sans authentification, sans chiffrement, accessibles à quiconque. Practical DevSecOps a constaté que 82 % de 2 614 serveurs surveyed sont vulnérables au path traversal. Un protocole conçu pour connecter des agents d'IA à des systèmes d'entreprise a été livré sans une baseline de sécurité de production, et les patterns de déploiement le prouvent : la plupart des équipes ont exposé MCP à internet avant de le durcir. Cette checklist est la baseline qui aurait dû venir en premier — 12 contrôles couvrant le transport, l'authentification, l'enregistrement des outils, le runtime et l'audit, chacun vérifiable en moins de cinq minutes avant qu'un serveur MCP ne touche le trafic de production.

Points clés

• 1,467 serveurs MCP sont accessibles publiquement sans authentification ni chiffrement — scan corrigé de Trend Micro, juillet 2026. 1,227 d'entre eux utilisent le transport SSE déprécié que la spécification 2026-07-28 retire avec une horloge de dépréciation de 12 mois.
• 82% de 2,614 serveurs MCP surveyés sont vulnérables au path traversal, et seulement 8,5% utilisent OAuth — Practical DevSecOps MCP Security Statistics 2026 Report. Les classes d'attaque sont répandues dans les serveurs déployés, pas théoriques.
• 3 CVE ont atterri dans le SDK officiel Python de MCP en juillet 2026 — CVE-2026-59950 (DNS rebinding/CSRF), CVE-2026-52869 (requêtes de session non vérifiées), CVE-2026-52870 (gestionnaires de tâches ouverts). L'implémentation de référence a livré la même classe de défaut que les serveurs communautaires.
• 78,3% de taux de succès d'attaque quand 5 serveurs MCP se connectent à 1 agent — Palo Alto Networks Unit 42. Cinq serveurs est un déploiement typique, pas un grand. OX Security a identifié un RCE architectural affectant 150M+ téléchargements, et la Cloud Security Alliance a classé la sécurité MCP comme un problème de défaut de conception systémique.
• La spécification MCP 2026-07-28 est publiée comme finale le 28 juillet 2026 — les quatre SDK Tier 1 (TypeScript, Python, Go, C#) parlent le nouveau cœur sans état, avec une politique de dépréciation de 12 mois pour le transport SSE. La migration et le durcissement sont le même travail.

Un déploiement MCP de production qui passe les 12 contrôles de cette liste de contrôle n'est pas invulnérable — aucun système ne l'est — mais il n'est plus dans la population que Trend Micro a trouvée, que Practical DevSecOps a scannée, ou que la vague de CVE de juillet a attrapée. La liste de contrôle mappe chaque contrôle à la catégorie OWASP MCP Top 10 qu'il adresse, le CVE ou l'exposition qu'il prévient, et l'étape de vérification qu'un opérateur peut exécuter en moins de cinq minutes. Le Microsoft Agent Governance Toolkit — le premier runtime de gouvernance open-source livré par un hyperscaler avec une couverture 10/10 de l'OWASP MCP Top 10 — est l'implémentation de référence. Cet article est le complément opérationnel : une revue de durcissement scannable pour un Directeur de l'Ingénierie ou un responsable plateforme préparant l'exposition d'un serveur MCP au trafic de production.

La surface d'attaque, en nombres

L'OWASP MCP Top 10 (Beta Release v0.1, Phase 3 of 5) catalogue 10 catégories de risque nommées tout au long du cycle de vie du système activé par MCP. Les nombres derrière elles sont ce qui transforme « la gouvernance est une bonne pratique » en « la gouvernance est une porte de production » :

• 1,467 serveurs exposés — le scan corrigé de Trend Micro a trouvé 1,467 serveurs MCP accessibles publiquement sans authentification ni chiffrement, depuis un compte initial de 492. 1,227 utilisent le transport SSE déprécié. Au moins trois exposent des dossiers médicaux de patients via un outil progress_note. L'outil execute_sql apparaît sur 70 hôtes.
• 82% d'exposition au path traversal — Practical DevSecOps a mesuré 82% de vulnérabilité au path traversal et 8,5% d'adoption d'OAuth sur 2,614 serveurs surveyés. 97M+ de téléchargements mensuels MCP signifie que l'exposition passe à l'échelle de l'adoption.
• 150M+ téléchargements affectés par un RCE architectural — OX Security a cadré la cause racine d'injection de commande STDIO comme un défaut au niveau architectural, pas des CVE isolés. La Cloud Security Alliance l'a classé comme un problème de défaut de conception systémique dans l'infrastructure d'agents IA.
• 3 CVE dans le SDK en juillet 2026 — CVE-2026-59950 (manque de validation Host/Origin, DNS rebinding/CSRF), CVE-2026-52869 (requêtes de session non vérifiées), CVE-2026-52870 (gestionnaires de tâches ouverts). Le SDK officiel Python — l'implémentation de référence dont chaque serveur MCP Python hérite — a livré la même classe de défaut que les serveurs communautaires qu'il soutient.
• 3 nouvelles surfaces d'attaque dans la spécification finale — backslash.security a identifié trois nouvelles surfaces d'attaque introduites par la refonte sans état dans la spécification 2026-07-28. Les nouvelles capacités créent de nouveaux points d'entrée que la communauté de sécurité est encore en train de cartographier.

L'analyse de cataam.com cadre l'état de la sécurité MCP précisément : « La sécurité MCP se situe à peu près là où la sécurité web se trouvait il y a quinze ans — les attaques sont anciennes, seule la cible est nouvelle. » La liste de contrôle de durcissement ci-dessous est l'ensemble des contrôles qui a fait passer la sécurité web de 82% d'exposition au path traversal à une ligne de base où les systèmes de production sont censés passer. Les mêmes contrôles s'appliquent ici.

Les 12 contrôles de durcissement

La liste de contrôle s'organise autour de cinq couches qui mappent à l'OWASP MCP Top 10 et aux changements de la spécification MCP 2026-07-28 :

Couche 1 — Transport et réseau

Contrôle 1 : Migration de SSE vers Streamable HTTP. La spécification MCP 2026-07-28 est publiée comme finale le 28 juillet 2026, avec une politique de dépréciation de 12 mois pour le transport HTTP+SSE. Les quatre SDK Tier 1 (TypeScript, Python, Go, C#) parlent le nouveau cœur sans état à partir du jour de publication, avec des notes de migration pour les parties cassantes. Les 1,227 serveurs SSE dépréciés du scan de Trend Micro sont la population la plus affectée — ils utilisent un transport que la spécification retire. Vérification : vérifiez la configuration de transport du serveur. S'il sert SSE, il est sur l'horloge de dépréciation. Migrez vers Streamable HTTP avant que la fenêtre de 12 mois ne se ferme.

Contrôle 2 : Isolation réseau et validation d'origine. CVE-2026-59950 — confirmé dans la National Vulnerability Database — est un défaut de validation Host/Origin manquante dans le SDK officiel Python de MCP. Une page web que la victime visite peut piloter son serveur MCP local via DNS rebinding et CSRF. Le navigateur devient le proxy de l'attaquant vers un serveur loopback que l'opérateur croyait privé. Vérification : confirmez que le serveur valide les en-têtes Host et Origin sur chaque requête. Si le serveur est exposé à internet, confirmez qu'il se trouve derrière une frontière réseau qui empêche l'accès direct depuis des origines non fiables. Un serveur qui n'aurait jamais dû être accessible depuis l'internet public ne doit pas être accessible depuis l'internet public.

Couche 2 — Authentification et identité

Contrôle 3 : Application d'OAuth 2.1 + OIDC. La spécification 2026-07-28 rend OAuth 2.1 plus OpenID Connect obligatoires — un changement par rapport à l'approche précédente « apportez votre propre jeton ». Le guide de migration d'authentification de WorkOS détaille les exigences : RFC 8707 (Resource Indicators) pour prévenir le rejeu de jetons entre serveurs, Client ID Metadata Documents remplaçant Dynamic Client Registration, vérification d'émetteur (RFC 9207). La constatation de Practical DevSecOps — seulement 8,5% des serveurs surveyés utilisent OAuth — est la ligne de base que ce contrôle élève. Vérification : vérifiez la configuration d'authentification du serveur. S'il accepte des requêtes non authentifiées ou utilise des clés API statiques sans OAuth, il échoue. Confirmez que le serveur implémente les resource indicators RFC 8707.

Contrôle 4 : Séparation d'identité de l'agent. La NIST AI Agent Standards Initiative (février 2026) propose de traiter les agents comme des identités non humaines distinctes avec leur propre cycle de vie : provisionnement, attestation, révocation. La plupart des déploiements authentifient l'utilisateur humain et passent cette identité à l'agent. Quand l'agent prend une action, le journal d'audit dit que l'humain l'a faite. Vérification : confirmez que chaque agent a sa propre credential (jeton OAuth, SPIFFE SVID) distincte de celle de l'opérateur humain. Révoquer l'identité de l'agent devrait arrêter tous les appels de l'agent sans affecter l'accès de l'humain.

Couche 3 — Enregistrement d'outils et chaîne d'approvisionnement

Contrôle 5 : Scan d'empoisonnement d'outils. OWASP MCP03 nomme l'empoisonnement d'outils comme un risque top-10 : rug pulls (un outil de confiance mis à jour vers une version malveillante après installation), schema poisoning (la définition d'interface elle-même corrompue pour induire le modèle en erreur), tool shadowing (un faux outil intercepte les appels destinés au vrai). Le McpSecurityScanner du Microsoft Agent Governance Toolkit détecte l'empoisonnement d'outils, le typosquatting et les instructions cachées — un outil de démonstration nommé read_flie (typosquatting de read_file) avec injection dans sa description a marqué 85/100 de risque. Vérification : inspectez le processus d'enregistrement d'outils. Si les outils sont enregistrés sans scan de sécurité, il échoue. Le scan doit couvrir les motifs d'injection de prompt dans les descriptions, le typosquatting contre les noms d'outils connus, et les directives système cachées.

Contrôle 6 : Provenance signée et surveillance des dépendances. OWASP MCP04 couvre les attaques sur la chaîne d'approvisionnement et la falsification de dépendances. La porte dérobée Postmark MCP — le premier serveur MCP malveillant attrapé en liberté — était un paquet npm d'apparence légitime qui interceptait silencieusement les emails et les exfiltrait. Il a passé la revue du registre. La recherche d'UpGuard a trouvé qu'un serveur MCP sur 15 est un lookalike conçu pour usurper un service légitime. Vérification : confirmez que chaque serveur MCP dans le déploiement a un enregistrement de provenance signé et un inventaire AIBOM (AI Bill of Materials). Confirmez que la surveillance des dépendances est active et alerte sur les nouveaux CVE dans l'arbre des dépendances.

Contrôle 7 : Durcissement STDIO. La divulgation d'OX Security a identifié un RCE architectural dans les configurations STDIO affectant 150M+ téléchargements. La cause racine : shell: true dans le SDK TypeScript permettait l'injection de commande via des chaînes de configuration. La Cloud Security Alliance l'a classé comme un problème de défaut de conception systémique. Vérification : si le serveur utilise le transport STDIO, confirmez que shell: false ou le durcissement équivalent est défini. Confirmez que les allowlists de commandes vérifient les arguments, pas seulement les noms de binaires — les contournements d'Upsonic et Flowise (CVE-2026-30625, CVE-2026-40933) ont montré que npx -c <commande-malveillante> passe à travers une allowlist qui ne vérifie que le binaire.

Couche 4 — Runtime et exécution

Contrôle 8 : Limitation de débit. Chaque outil déclare sa propre limite de débit dans l'appel d'enregistrement. Le backbone applique les limites par-agent, par-outil et par-fenêtre. Quand une limite est atteinte, l'agent reçoit une réponse 429 avec un en-tête Retry-After. Un agent compromis ne peut pas épuiser les quotas d'API en amont parce que la limite de débit est appliquée à la frontière du module. Vérification : confirmez que chaque outil enregistré a une limite de débit. Confirmez que la limite est appliquée à la frontière du module, pas à l'API en amont. Un outil sans limite de débit est un outil qu'un agent compromis peut appeler sans limite.

Contrôle 9 : Frontière de contexte. OWASP MCP10 nomme l'injection de contexte et le sur-partage comme un risque top-10. Un agent avec un accès large au contexte fait fuir des informations à travers les tenants, sessions ou utilisateurs — un souci particulièrement aigu pour les déploiements B2B où le même agent sert plusieurs clients avec des droits d'accès aux données différents. Vérification : confirmez que chaque outil reçoit seulement le contexte dont il a besoin pour son opération spécifique. Confirmez que la fenêtre de contexte est délimitée par-outil, pas partagée globalement entre tous les outils. Un outil qui reçoit le contexte complet de session quand il n'a besoin que d'un seul champ est une surface de fuite de données.

Contrôle 10 : Kill-switch par module. Chaque module MCP doit être désactivable indépendamment sans toucher le backbone d'orchestration. Le kill switch est un changement de configuration, pas un déploiement de code. Quand une vulnérabilité est divulguée — comme la vague de CVE de juillet a divulgué 3 CVE du SDK et 7+ CVE de serveurs en une quinzaine — la première question de l'opérateur est : puis-je désactiver ce module sans faire tomber l'agent ? Dans un déploiement gouverné, la réponse est oui. Vérification : confirmez que chaque module peut être désactivé via un feature flag ou un changement de configuration. Confirmez que le chemin de désactivation a été testé — pas seulement configuré. Un kill switch qui n'a jamais été exercé est un kill switch qui échouera quand il sera nécessaire.

Couche 5 — Audit et télémétrie

Contrôle 11 : Journalisation d'audit par appel. OWASP MCP08 nomme le manque d'audit et de télémétrie comme un risque top-10. Sans journaux des invocations d'outils et des changements de contexte, le vol de jetons et l'injection restent invisibles. Chaque appel d'outil doit journaliser l'horodatage, l'ID d'agent, le nom de l'outil, le hash d'entrée (pas l'entrée brute — frontière PII), le statut de sortie, la durée et le système en amont. Les journaux sont du JSON structuré envoyé au pipeline d'observabilité. Vérification : confirmez que chaque appel d'outil produit une entrée de journal structurée. Confirmez que le journal inclut le hash d'entrée, pas l'entrée brute. Confirmez que le journal est immuable — un attaquant qui compromet le serveur ne peut pas réécrire la piste d'audit.

Contrôle 12 : Détection de serveurs fantômes. OWASP MCP09 couvre les serveurs MCP fantômes — déploiements non approuvés ou non supervisés invisibles à la gouvernance. UpGuard a trouvé qu'un serveur MCP sur 15 est un lookalike. Un ingénieur qui installe le mauvais mcp-server-postgress (notez la faute de frappe) obtient un paquet qui exfiltre silencieusement les clés SSH et les fichiers .env. Vérification : confirmez qu'il y a un inventaire de chaque serveur MCP dans le déploiement. Confirmez que l'inventaire est vérifié contre un registre de paquets connus-bons. Confirmez que la surveillance de dérive alerte quand un nouveau serveur apparaît qui n'était pas dans l'inventaire.

Comment les frameworks mappent à la liste de contrôle

Contrôle	OWASP MCP	Spec 2026-07-28	Microsoft AGT	NIST	CSA
1. Migration SSE	—	Dépréciation 12 mois	—	—	—
2. Isolation réseau	MCP07	Validation d'origine	—	—	—
3. OAuth 2.1 + OIDC	MCP07	Auth obligatoire	—	OAuth 2.0	—
4. Identité d'agent	MCP07	—	AgentMesh Identity	SPIFFE/SPIRE	—
5. Scan d'empoisonnement	MCP03	—	MCP Security Gateway	—	—
6. Provenance signée	MCP04	—	—	—	—
7. Durcissement STDIO	MCP05	—	—	—	Défaut de conception systémique
8. Limitation de débit	—	—	Policy Engine	—	—
9. Frontière de contexte	MCP10	—	Response sanitizer	—	—
10. Kill-switch par module	—	—	Hypervisor kill switch	—	—
11. Journalisation d'audit	MCP08	—	Audit + metrics	—	—
12. Détection de fantômes	MCP09	—	—	—	—

Aucun framework unique ne couvre les 12 contrôles. La liste de contrôle est l'intersection d'OWASP, de la spécification, de Microsoft, de NIST et de CSA — chacun contribuant les contrôles que les autres manquent. Le Microsoft Agent Governance Toolkit couvre 10/10 des catégories OWASP MCP Top 10 (7/10 complètes, 3/10 partielles avec feuille de route) et est le premier runtime open-source livré par un hyperscaler avec des mappages OWASP explicites — 68 tests dans l'Agent OS Policy Engine, 127 tests dans le MCP Security Gateway, 80 tests dans l'Agent Hypervisor Execution Control incluant le kill switch.

Noter la liste de contrôle

Un serveur MCP prêt pour la production passe les 12 contrôles. Un serveur partiellement prêt passe 8–11. Un serveur qui passe moins de 8 ne devrait pas être exposé au trafic de production sans un plan de remédiation documenté et une date cible pour chaque contrôle échoué.

Score	Statut	Action
12/12	Prêt pour la production	Déployer avec surveillance
8–11/12	Partiellement prêt	Déployer avec exceptions documentées et calendrier de remédiation
<8/12	Pas prêt	Ne pas déployer. Remédier d'abord les contrôles échoués

Le schéma d'échec le plus courant est de passer les contrôles 1–4 (transport, authentification, identité) tout en échouant les contrôles 5–12 (chaîne d'approvisionnement, runtime, audit). Les quatre premiers sont architecturaux et reçoivent de l'attention dans les revues de conception. Les huit derniers sont opérationnels et sont manqués jusqu'à ce qu'un incident ou un audit les mette en lumière. La vague de CVE de juillet 2026 — 3 CVE du SDK et 7+ CVE de serveurs en une quinzaine — est ce qui arrive quand les contrôles opérationnels sont absents.

Lecture connexe

• Le paradoxe MCP : pourquoi sans friction est fragile — l'analyse de risque au niveau protocole que les contrôles 5, 7 et 9 de cette liste de contrôle adressent. Couvre l'OWASP MCP Top 10, le taux d'attaque de 78,3% de Palo Alto Unit 42, et la divulgation d'injection de commande STDIO d'OX Security.
• Sécurité MCP : pourquoi 200 000 instances vulnérables font des modules gouvernés un critère d'achat — la couche de gouvernance que cette liste de contrôle opérationnalise. Couvre l'estimation de 200 000 instances d'OX Security, la chronologie des brèches 2026, et le point de preuve de 38 outils.
• MCP Module Code Standard — le standard de code qui rend les contrôles 8, 9, 10 et 11 applicables dans le module lui-même. Couvre la structure de répertoire, l'enregistrement d'outils, la gestion d'erreurs, la limitation de débit et les règles de frontière PII.
• Liste de contrôle de gouvernance d'agents IA : une revue pré-déploiement — la liste de contrôle plus large de 10 contrôles de gouvernance d'agents que cette liste de contrôle spécifique à MCP complète. Couvre l'identité NIST, OWASP, les niveaux d'autonomie Gartner, Stanford AILCCP et le paquet législatif Warner.

---

Un build représentatif : un distributeur de taille moyenne déployant un module MCP qui lit un catalogue NetSuite, génère des devis, maintient la disponibilité d'inventaire et réécrit la commande acceptée vers l'ERP. Les contrôles 1–4 (migration SSE, isolation réseau, OAuth, identité d'agent) sont l'architecture. Les contrôles 5–8 (scan d'empoisonnement, provenance signée, durcissement STDIO, limitation de débit) sont la couche de chaîne d'approvisionnement et de runtime. Les contrôles 9–12 (frontière de contexte, kill switch, journalisation d'audit, détection de fantômes) sont la couche opérationnelle qui détermine si le module fonctionne pendant une semaine ou un an. La phase Discovery d'une semaine produit l'inventaire système et la carte de flux de travail qui rend chaque contrôle vérifiable avant que le module ne touche le trafic de production.

Discovery d'une semaine. Vous obtenez un inventaire système, une carte de flux de travail et un périmètre fixé — que vous construisiez avec nous ou non.