9 min de lecture
Le 18 août 2026, une injection de prompt est publiée sous CVE-2026-75130 dans Context7, l’un des serveurs MCP de documentation les plus installés au monde. Une requête de doc parfaitement banale peut ramener des instructions non filtrées dans le contexte de l’agent de code, jusqu’à l’exfiltration du .env et la suppression de fichiers sur la machine.
Deux détails rendent ce cas intéressant bien au-delà de l’advisory
Le serveur MCP le plus inoffensif du monde (oupas)
Context7, fait une chose et une seule : quand votre agent de code a besoin de la documentation à jour d’une bibliothèque, il interroge Context7 plutôt que d’ halluciner une API qui n’existe plus depuis trois versions majeures. C’est utile, c’est propre, et c’est installé par défaut dans un nombre considérable de configurations de développement.
C’est aussi, du point de vue du threat model, la définition exacte d’un canal de confiance implicite. L’agent envoie une question, reçoit du texte, et met ce texte dans son contexte. Personne, dans cette boucle, ne se demande si le texte reçu contient des instructions.
Note du PandaRedacteur : le serveur MCP dont personne ne se méfie parce qu’il « ne fait que lire de la doc ». C’est exactement le raisonnement qu’on tenait sur les fichiers PDF en 2005, sur les macros Office en 2010, et sur les extensions de navigateur en 2018. À un moment, il faudra accepter que tout ce qui entre dans un interpréteur est du code.
La faille se situe dans la fonctionnalité Custom AI Instructions. Elle permet d’associer à une bibliothèque des consignes personnalisées, censées aider l’agent à mieux utiliser la doc. Ces consignes ne sont pas assainies. Quand un développeur demande la documentation d’une bibliothèque piégée, elles arrivent telles quelles dans le contexte de l’agent connecté ; et l’agent, lui, a des outils.
C’est le point à bien saisir : le serveur MCP n’exécute rien, c’est l’agent qu’il sert qui agit. Le serveur est le vecteur, la victime est le poste du développeur, et les deux systèmes n’ont rien à voir l’un avec l’autre en termes de périmètre de sécurité. Retenez ça, on y revient pour le scoring.
Le chemin d’attaque
sequenceDiagram
participant A as Attaquant
participant C7 as Serveur MCP Context7
participant AG as Agent de code (IDE)
participant M as Machine du dev
A->>C7: Publie des Custom AI Instructions piégées<br/>sur une entrée de bibliothèque
Note over AG,M: Le développeur travaille normalement
AG->>C7: resolve-library-id + query-docs<br/>(requête de doc banale)
C7-->>AG: Documentation + instructions non assainies
Note over AG: Les instructions entrent dans le contexte<br/>sans marqueur de provenance
AG->>M: Lecture de .env / fichiers de credentials
AG->>A: Exfiltration vers un service contrôlé par l'attaquant
AG->>M: Suppression destructive de fichiers
Les impacts documentés sont :
- l’exfiltration de credentials depuis les fichiers d’environnement vers un service contrôlé par l’attaquant,
- et la suppression destructive de fichiers sur la machine de la victime.
Aucune interaction inhabituelle n’est requise du développeur. Il demande de la doc. C’est tout. On est exactement dans le schéma de l’injection de prompt via charge contextuelle que je décrivais dans MCP06, et dans la logique de tool poisoning de MCP03 ; sauf qu’ici, l’outil empoisonné n’est pas un outil douteux téléchargé sur un registre obscur.
Analyse STRIDE
| Catégorie STRIDE | Applicable | Explication |
|---|---|---|
| Spoofing | Élevé | Les instructions injectées arrivent dans le contexte de l'agent sans marqueur de provenance. Pour le modèle, elles ont exactement le même statut qu'une consigne de son opérateur. |
| Tampering | Critique | Altération du contexte de l'agent, puis suppression destructive de fichiers sur le poste de développement via les outils dont l'agent dispose. |
| Repudiation | Élevé | Les actions destructives sont effectuées par l'agent, sous l'identité du développeur. Sans traçabilité du contexte injecté, l'analyse post-incident conclut à une erreur de l'agent, pas à une attaque. |
| Information Disclosure | Critique | Exfiltration des fichiers .env et des credentials du poste vers un service contrôlé par l'attaquant. C'est l'impact principal documenté. |
| Denial of Service | Secondaire | Pas un objectif du vecteur, mais la suppression de fichiers produit un déni de service local sur le poste et sur le travail non commité. |
| Elevation of Privilege | Critique | Un contenu distant, sans aucun privilège, obtient les privilèges complets de l'agent sur le poste : lecture, écriture, exécution, réseau sortant. |
Le correctif de février était dans le périmètre
Le détail chronologique mérite qu’on s’y arrête.
La version 2.1.2 de Context7 est publiée le 23 février 2026. C’est précisément la version dans laquelle Noma Security documentait la correction d’une injection très voisine, passant par la fonctionnalité Custom Rules.
Six mois plus tard, la CVE-2026-75130 annonce comme affectées « les versions jusqu’à** 2.1.2 incluse** ». Autrement dit : la version qui corrigeait le premier bug se retrouve dans la plage vulnérable du second. Deux lectures possibles, une régression ou une variante non couverte par le correctif initial ; dans les deux cas, la conclusion opérationnelle est la même. Le correctif de février traitait un chemin d’entrée, pas la classe de vulnérabilité.
C’est le schéma classique du patch qui ferme la porte et laisse la fenêtre. Tant qu’on assainit champ par champ au lieu de poser une frontière de confiance entre « contenu récupéré » et « instruction », on rejouera le même incident à chaque nouvelle fonctionnalité qui accepte du texte utilisateur.
Note du PandaRedacteur : « on a corrigé l’injection ». Non. Vous avez corrigé UNE injection. La différence tient en un article défini, et c’est ce qui sépare six mois de tranquillité d’une CVE de plus.
Point qui me gêne franchement : le statut du correctif n’est pas documenté. Aucun GitHub Security Advisory, aucune note de release, aucune déclaration éditeur ne dit si les versions 2.2.x, 3.x ou la 4.0.x actuelle contiennent un correctif. Le package npm est passé en 4.0.x entre-temps, mais « c’est une version plus récente » n’est pas une réponse de sécurité.
L’écart de scoring : 9.0 contre 6.4
Le même bug, deux frameworks, deux verdicts :
| Framework | Score | Verdict |
|---|---|---|
| CVSS 3.1 | 9.0 | Critique |
| CVSS 4.0 | 6.4 | Moyen |
Ce n’est pas une erreur d’analyste, c’est structurel ; et ça mérite d’être compris, parce que ça va vous arriver de plus en plus souvent.
CVSS 3.1 dispose du mécanisme Scope : quand la vulnérabilité d’un composant produit un impact sur un autre périmètre de sécurité, le changement de scope est compté à plein poids. Ici, le serveur MCP est vulnérable, la machine du développeur est impactée : scope changed, impacts au maximum, 9.0.
CVSS 4.0 a supprimé le Scope et l’a remplacé par une séparation explicite entre impact sur le système vulnérable (VC/VI/VA) et impact sur les systèmes subséquents (SC/SI/SA). Sur le système vulnérable, le serveur Context7 lui-même, il ne se passe rien : aucun impact. Tout le dégât est subséquent. Résultat : 6.4.
CVSS 4.0 est plus honnête sur où se produit le dommage, et nettement moins alarmant sur combien il coûte.
Pour une vulnérabilité classique, c’est un progrès. Pour toute la famille des vulnérabilités agentiques, où le composant faillible n’est jamais celui qui souffre, c’est un biais systématique à la baisse. Un serveur MCP, un connecteur, une passerelle d’outils : ces composants ne subissent jamais rien. Ils transmettent. Et dans un modèle de scoring qui pondère d’abord le système vulnérable, transmettre ne coûte presque rien.
C’est précisément l’argument que je développais dans SSVC : arrêter de scorer, commencer à décider. Si votre processus de priorisation lit « 6.4 medium » et range le ticket dans le sprint d’après, vous venez de reporter le traitement d’une exfiltration de credentials d’un mois, sur la foi d’un chiffre calculé par un modèle qui n’a pas été conçu pour ce type de chaîne. La question utile n’est pas « quel est le score ? » mais « est-ce exploitable chez moi, et qu’est-ce que ça touche ? ».
Impact potentiel
| Dimension | Niveau | Conséquence concrète |
|---|---|---|
| Confidentialité | Critique | Fichiers .env et credentials du poste de développement exfiltrés vers un service tiers. |
| Intégrité | Élevé | Suppression de fichiers, et plus largement toute action que l'agent peut effectuer sur le dépôt courant. |
| Disponibilité | Modéré | Perte de travail non commité, poste à réinstaller si la suppression est étendue. |
| Réputation | Élevé | Les credentials volés sur un poste de dev ouvrent la porte des environnements amont ; la brèche client ne portera pas le nom du serveur MCP. |
Ce que je ferai, concrètement
Côté poste de développement :
- Traitez tout serveur MCP de documentation comme une source non fiable. Y compris celui que vous avez installé vous-même il y a six mois, y compris celui recommandé dans tous les tutoriels.
- Vérifiez la version de Context7 dans votre configuration MCP ; toute version ≤ 2.1.2 est explicitement dans la plage affectée. Sur les versions ultérieures, l’absence d’advisory ne vaut pas absence de vulnérabilité.
Note du PandaRedacteur : au mieux supprimer Context7…mais ca va crisser…
- Coupez l’exécution automatique des outils sur un agent qui consomme des serveurs MCP externes. C’est fastidieux, c’est la seule barrière qui tient devant une injection non détectée.
Côté architecture :
- Interdisez au poste de dev de lire le
.envde production. Le vrai correctif de cette CVE n’est pas dans Context7, il est dans le fait que le fichier exfiltré ne devrait pas contenir de secret exploitable.Note du PandaRedacteur : honnetement on devrait pas avoir un
.envpour la production, mais plutot un vault qui inject…mais bon…. - Segmentez le réseau sortant de l’agent. Une exfiltration a besoin d’une destination ; une politique d’egress sur allowlist casse la chaîne à la dernière étape, quelle que soit l’injection en amont.
- Journalisez ce qui entre dans le contexte, pas seulement ce qui en sort. Sans ça, l’analyse post-incident se termine par « l’agent a mal interprété la demande », ce qui est faux et confortable.
Sur la partie authentification et attestation des serveurs MCP, je renvoie à MCP : authentifier clients, agents et attester qui fait quoi ; et pour la classification du vecteur, à la taxonomie de la prompt injection dans les référentiels publics.
📚 Références
- CVE-2026-75130 : analyse détaillée
- Noma Security : recherche sur les serveurs MCP
- OWASP GenAI Security Project
- Sur ce blog : OWASP MCP Top 10 · MCP03 Tool Poisoning · MCP06 Prompt Injection via charges contextuelles · AgentBaiting · SSVC