Un tour d’horizon en langage clair des dix risques de l’OWASP MCP Top 10, des jetons exposés à l’empoisonnement d’outils, en passant par les serveurs fantômes et le surpartage du contexte. Chaque entrée présente une attaque documentée, une correction claire et un plan d’une semaine pour les appliquer dans l’ordre.
Un seul serveur MCP peut confier à un agent d’IA vos dépôts, votre boîte de réception et votre base de données en un après-midi, et l’approuver ne demande souvent qu’un clic. C’est précisément cette facilité que l’OWASP MCP Top 10 cherche à freiner. Il recense les dix risques les plus susceptibles de compromettre un déploiement du Model Context Protocol, des jetons exposés aux serveurs dont personne dans l’équipe de sécurité n’a connaissance. Cet article passe en revue chaque entrée dans l’ordre, montre à quoi ressemble l’attaque à partir d’un exemple réel ou documenté, et termine chaque section par la correction à appliquer en priorité.
La liste provient du projet OWASP MCP Top 10, version 2025, dirigé par Vandana Verma Sehgal. La page du projet le présente actuellement en phase de test bêta et pilote, si bien que la formulation et l’ordre peuvent encore évoluer. Considérez les dix entrées comme un vocabulaire commun plutôt que comme un standard finalisé.
MCP est le protocole qui permet à un modèle d’appeler des outils. Un client MCP (l’application qui héberge le modèle) se connecte à un ou plusieurs serveurs MCP, et chaque serveur expose des outils, des ressources et des prompts que le modèle peut utiliser. Chacune de ces connexions repose sur une décision de confiance : le serveur fait confiance au client pour se comporter correctement, le client fait confiance aux descriptions et aux sorties du serveur, et le modèle fait confiance à tout texte qui arrive dans sa fenêtre de contexte.
Le Top 10 cartographie les endroits où cette confiance se brise. Voici les dix en un coup d’œil :
| ID | Risque | Signification simple | Première correction la moins coûteuse |
|---|---|---|---|
| MCP01 | Gestion défaillante des jetons et exposition des secrets | Les identifiants fuient via le code, les journaux ou le contexte | Jetons à courte durée de vie et analyse des secrets |
| MCP02 | Élévation de privilèges par extension de périmètre | Les permissions dépassent ce dont la tâche a besoin | Moindre privilège avec expiration |
| MCP03 | Empoisonnement d’outils | La description ou la sortie d’un outil contient des instructions cachées | Épingler et hacher les définitions d’outils |
| MCP04 | Attaques sur la chaîne d’approvisionnement logicielle et altération des dépendances | Un paquet malveillant ou détourné devient votre serveur | Inventorier et épingler chaque dépendance |
| MCP05 | Injection de commandes et exécution | Du texte non fiable atteint un shell | Pas de shell, listes d’arguments, validation |
| MCP06 | Détournement du flux d’intention | Le contenu récupéré réoriente l’objectif de l’agent | Traiter le texte récupéré comme des données, approuver les écritures |
| MCP07 | Authentification et autorisation insuffisantes | Les serveurs ne vérifient pas qui appelle | OAuth 2.1 et contrôles par outil |
| MCP08 | Absence d’audit et de télémétrie | Personne ne voit ce que l’agent a fait | Journaliser chaque appel d’outil |
| MCP09 | Serveurs MCP fantômes | Des serveurs non approuvés fonctionnent hors de tout cadre de gouvernance | Inventaire et liste d’autorisation |
| MCP10 | Injection de contexte et surpartage | Le contexte fuit entre utilisateurs ou tâches | Isoler le contexte par utilisateur |
💡 Note sur les noms : la page de présentation du projet désigne la sixième entrée « Prompt Injection via Contextual Payloads », alors que sa page de détail pour MCP06 s’intitule « Intent Flow Subversion ». Les deux renvoient au même emplacement, et cet article utilise le titre de la page de détail.
C’est le plus vieux problème de sécurité, sous un habit neuf. Des secrets d’API codés en dur, des jetons de longue durée et des identifiants collés dans des prompts ou des fichiers de configuration finissent dans les journaux, l’historique des conversations et la mémoire du modèle. Une fois qu’un secret se trouve dans la fenêtre de contexte, une injection de prompt n’a plus qu’à demander au modèle de le répéter.
Scénario de l’OWASP : un développeur envoie un secret dans le dépôt pendant des tests, le serveur MCP le lit au démarrage, et l’assistant l’affiche plus tard dans une réponse destinée à quelqu’un d’autre.
Que faire :
💡 Astuce : les secrets qui commencent par un préfixe fixe sont faciles à repérer. Les secrets d’API de PicassoIA commencent par
pia_sk_, donc une règle de scanner d’une seule ligne peut les signaler dans n’importe quel dépôt. Ajoutez le même type de règle pour chaque fournisseur que vous utilisez.
Les permissions commencent serrées puis se relâchent avec le temps. Un jeton créé pour un seul dépôt est élargi « juste pour ce sprint », un agent obtient un accès en écriture parce que l’accès en lecture était gênant, et personne ne révoque rien. Le modèle finit par détenir bien plus de pouvoir que n’en exige une tâche, si bien qu’une seule mauvaise instruction cause beaucoup plus de dégâts.
Scénario de l’OWASP : une injection de prompt cachée dans une issue GitHub publique réoriente un agent disposant d’un large accès aux dépôts, et l’agent copie du code privé dans une pull request publique.
Que faire :
Les modèles choisissent les outils en lisant leurs noms et leurs descriptions, ce qui fait de ces descriptions une surface d’attaque. Un outil empoisonné dissimule des instructions dans ses métadonnées, son schéma ou sa sortie. En avril 2025, Invariant Labs a démontré l’attaque avec un outil d’addition anodin dont la description cachée demandait à l’agent de lire un fichier de configuration MCP local et un fichier de clé privée SSH, puis de transmettre leur contenu dans un paramètre inutilisé, pendant que la réponse ne parlait que d’arithmétique.
Une variante plus sournoise est le rug pull : un outil se comporte bien au moment où vous l’approuvez, puis modifie sa description après l’installation.
Que faire :
Un serveur MCP est du code écrit par quelqu’un d’autre et téléchargé depuis un registre. Un paquet compromis ou usurpé obtient le même accès que celui que vous accordez au véritable. En septembre 2025, un paquet npm nommé postmark-mcp a copié une intégration Postmark authentique et ajouté une seule ligne qui envoyait une copie cachée de chaque e-mail sortant à une adresse contrôlée par l’attaquant. Des chercheurs de Koi Security l’ont signalé comme le premier serveur MCP malveillant observé dans la nature, et l’analyse de Snyk en détaille les mécanismes. Il a été téléchargé environ 1 500 fois par semaine avant d’être retiré.
Que faire :
Les agents construisent des commandes à partir de texte. Lorsque ce texte est contrôlé par un attaquant (un commentaire d’issue, un nom de fichier, une page web), le shell fait le reste. Selon l’analyse de la liste par Cycode, la CVE-2025-6514 dans mcp-remote avait un score CVSS de 9,6, touchait un paquet comptant plus de 437 000 téléchargements et permettait une injection de commandes système. Elle se situe à la frontière entre cette entrée et MCP04.
La différence entre un code risqué et un code sûr tient souvent à une seule ligne :
import re
import subprocess
# Risky: untrusted text is spliced into a shell string
subprocess.run(f"git log --author={author}", shell=True)
# Safer: fixed command, argument list, validated input, no shell
if not re.fullmatch(r"[A-Za-z0-9._@][A-Za-z0-9 ._@-]{0,63}", author):
raise ValueError("invalid author")
subprocess.run(["git", "log", "--author", author], shell=False, check=True)
Que faire :
L’agent lit une page web, une issue ou un PDF, et ce contenu contient des instructions. Un modèle ne peut pas distinguer de façon fiable les données des commandes, il peut donc les suivre. Le résultat est un détournement d’objectif : l’agent semble toujours accomplir votre tâche alors qu’il sert quelqu’un d’autre.
Le cas réel le plus clair vient d’Invariant Labs en mai 2025, à propos du serveur MCP GitHub officiel. Un attaquant ouvre une issue malveillante dans un dépôt public. Lorsque le propriétaire demande à son agent d’examiner les issues ouvertes, l’agent lit l’issue, se fait injecter, récupère des données de dépôts privés dans son contexte et les publie dans une pull request sur le dépôt public. Les chercheurs ont appelé cela un « flux d’agent toxique », ont affirmé qu’il s’agissait d’un problème d’architecture plutôt que d’un bogue dans le code du serveur, et ont soupçonné que beaucoup d’utilisateurs choisissaient une politique d’approbation « toujours autoriser », qui supprime le contrôle humain.
Que faire :
💡 Astuce : un classifieur n’est qu’une couche, pas la défense complète. Llama Guard 4 12B sur PicassoIA est un modèle de modération de contenu qui peut filtrer le texte avant qu’il n’atteigne votre agent, mais c’est un classifieur de sécurité et non un détecteur d’injection dédié, donc conservez les approbations et le moindre privilège en place.
Certains serveurs MCP ne demandent jamais qui les appelle. Un point d’accès exposé sans authentification permet à n’importe qui d’invoquer ses outils, et un serveur qui vérifie l’identité une fois mais ne contrôle jamais les permissions à chaque appel permet à un utilisateur à faibles privilèges de déclencher des actions à privilèges élevés.
Un cas concret est la CVE-2025-49596 dans MCP Inspector d’Anthropic, notée CVSS 9,4. Les versions antérieures à 0.14.1 n’avaient aucune authentification entre le client Inspector et son proxy, de sorte que des requêtes non authentifiées pouvaient lancer des commandes via stdio. Associé à une faille du navigateur et à une falsification de requête intersite, il suffisait de visiter un site malveillant pour exécuter du code sur la machine d’un développeur.
Que faire :
Sans journaux, chaque autre risque de cette liste devient invisible. Le vol de jetons, l’injection de commandes et l’injection de prompt peuvent tous se produire sans qu’aucune trace ne soit conservée, et la réponse à incident se réduit à des conjectures. Cette entrée amplifie les neuf autres.
Un journal d’appels d’outils utile tient en peu de champs. Pour chaque appel, enregistrez :
| Champ | Pourquoi c’est important |
|---|---|
| Qui ou quoi a fait l’appel | Relie l’action à un utilisateur, un agent ou un service |
| Quel serveur et quel outil | Montre quelle capacité a été utilisée |
| Arguments (hachés ou masqués) | Permet de rejouer l’intention sans stocker de secrets |
| Taille et statut du résultat | Révèle les lectures en masse et les échecs silencieux |
| Horodatage et identifiant de session | Reconstitue l’ordre des événements |
Que faire :
Un développeur lance un serveur expérimental un vendredi, il continue de tourner avec des identifiants par défaut et des paramètres ouverts, et dès lundi il contient de vraies données. Personne ne l’a approuvé, personne ne le surveille, et il n’apparaît dans aucun inventaire. C’est ce qu’on appelle un serveur MCP fantôme.
Où chercher en premier :
Que faire :
Les fenêtres de contexte partagées ou persistantes fuient. Lorsqu’un même agent sert plusieurs utilisateurs ou locataires et que le contexte n’est pas isolé, les données d’une personne peuvent apparaître dans la session d’une autre. Le scénario de l’OWASP est un agent unique servant de nombreux utilisateurs, qui laisse les données personnelles de l’un fuiter dans une session différente.
Cela s’est déjà produit sur un produit réel. BleepingComputer a rapporté qu’Asana avait averti ses utilisateurs en juin 2025 qu’une faille logique dans sa nouvelle fonctionnalité MCP exposait les données de certaines organisations à d’autres. Environ 1 000 clients ont été touchés, et Asana a désactivé la fonctionnalité du 5 au 17 juin, le temps de corriger le bogue. Il s’agissait d’une erreur de logique, et non d’un piratage, et la faille était active depuis environ un mois avant qu’Asana ne la découvre.
Que faire :
Vous ne pouvez pas fermer les dix en une semaine, alors commencez là où les dégâts sont les plus grands et le travail le plus réduit.
| Jour | Tâche | Risques couverts |
|---|---|---|
| Lundi | Inventorier chaque serveur MCP et chaque configuration client | MCP09 |
| Mardi | Analyser les dépôts à la recherche de secrets, renouveler les anciens, raccourcir la durée de vie des jetons | MCP01 |
| Mercredi | Ajouter l’authentification et les contrôles de permissions par outil | MCP07, MCP02 |
| Jeudi | Épingler les versions, hacher les descriptions d’outils, configurer des alertes de changement | MCP03, MCP04 |
| Vendredi | Activer la journalisation des appels d’outils et exiger une approbation pour les écritures | MCP08, MCP06 |
💡 Erreurs courantes : approuver « toujours autoriser » pour réduire les clics, faire confiance à un serveur parce qu’il a beaucoup de téléchargements, et tout journaliser sauf les arguments d’outils qui comptent.
Une liste de contrôle de sécurité frappe davantage les esprits quand on peut se la représenter. Chaque image de cet article utilise un substitut physique simple pour un défaut abstrait : un anneau surchargé de badges pour l’extension de périmètre, une porte calée ouverte pour une authentification faible, un registre vierge pour l’absence de piste d’audit. Vous pouvez construire le même type de visuels pour vos propres modèles de menace, vos supports de formation et vos wikis internes.
Essayez-le sur PicassoIA. Ouvrez un modèle de texte vers image comme Seedream 5 Pro, Qwen Image 3 ou GPT Image 2, décrivez un objet réel qui représente votre risque et ajoutez l’éclairage et l’objectif souhaités. Générez quelques variantes, retenez la plus nette et intégrez-la à votre prochaine revue. Si vous rédigez aussi la documentation, les grands modèles de langage de PicassoIA peuvent vous aider à rédiger une première version avant de la retoucher à la main.
Choisissez votre langue
