CVE-2026-46519 : quand un serveur MCP filtre les outils à l'affichage mais pas à l'exécution

De quoi s’agit-il ?

CVE-2026-46519 est un contournement de contrôle d’accès dans mcp-server-kubernetes, un serveur Model Context Protocol (MCP) très utilisé qui permet à des agents IA de piloter un cluster Kubernetes. La faille a été publiée via l’avis de sécurité GitHub GHSA-cr22-wjx7-2w6m et suivie dans le NVD avec un score CVSS 3.1 de 8.8 (élevé) et une classe de faiblesse CWE-863 (autorisation incorrecte). NeuralTrust a publié une analyse technique le 19 mai 2026, la GitLab Advisory Database l’a enregistrée le 21 mai 2026, et le correctif est arrivé en version 3.6.0.

Le paquet n’a rien de marginal : il totalise environ 20 000 téléchargements npm par semaine et constitue le pont standard auquel les organisations recourent pour qu’un agent lise ou gère l’état d’un cluster. C’est cette diffusion qui transforme un petit écart logique en problème à l’échelle du cluster.

Comment ça fonctionne

Le serveur expose trois variables d’environnement documentées comme des contrôles d’accès : ALLOW_ONLY_READONLY_TOOLS, ALLOW_ONLY_NON_DESTRUCTIVE_TOOLS et ALLOWED_TOOLS (une liste blanche explicite de noms d’outils). Un opérateur qui positionne ALLOW_ONLY_READONLY_TOOLS=true s’attend à ce qu’un agent connecté puisse regarder, mais jamais toucher.

MCP scinde l’usage des outils en deux opérations : tools/list (découverte — « que puis-je faire ici ? ») et tools/call (exécution — « fais ceci maintenant »). Le défaut : la logique de restriction ne vivait que dans tools/list.

Couche                 Requête        Restriction vérifiée ?
---------------------  -------------  ----------------------
Découverte (affichage) tools/list     OUI -> liste filtrée renvoyée
Exécution (action)     tools/call     NON -> tout outil nommé s'exécute

Quand un agent en lecture seule demandait sa liste d’outils, le serveur renvoyait bien un ensemble filtré — kubectl_get, kubectl_describe et consorts — sans les outils destructeurs comme kubectl_delete, exec_in_pod ou kubectl_generic. Mais le gestionnaire tools/call ne revérifiait jamais la politique. Tout client connaissant déjà le nom d’un outil restreint — et ces noms figurent dans le README du projet — pouvait l’appeler directement. Pas d’injection, pas de chaîne d’exploitation, pas de primitive d’élévation de privilèges : juste une requête pour un outil que l’interface prétendait inexistant.

vue de l'agent : [ kubectl_get, kubectl_describe ]        # ce que tools/list montre
portée réelle   : tools/call -> kubectl_delete([REDACTED])   # ce que le serveur fera

Dans les termes de l’avis, les contrôles étaient « cosmétiques » : ils cachaient les boutons mais laissaient le câblage connecté.

Pourquoi c’est important

Le rayon d’impact réel dépend d’une chose que la CVE ne corrige pas à votre place : les privilèges du Service Account Kubernetes sous lequel tourne le serveur MCP. Le contournement n’accorde jamais au serveur plus de droits qu’il n’en possède déjà — mais dans les clusters de développement et de pré-production, il est courant de faire tourner un tel serveur en cluster-admin « pour la commodité ». Dans cette configuration, quiconque atteint le point d’accès HTTP hérite de toute la puissance de ce compte : supprimer des namespaces, réécrire des déploiements, lire chaque Secret.

Deux enseignements dépassent le cas d’un seul paquet npm. D’abord, c’est un cas d’école d’autorisation à l’affichage vs à l’exécution — la même erreur qu’une application web qui masque un bouton d’admin mais laisse la route /admin non authentifiée. L’outillage des agents, parce qu’il est jeune, réinvente ces échecs. Ensuite, le modèle de menace de MCP ne se limite pas au « prompt malveillant ». Un agent honnête mais mal configuré, ou n’importe quel client sur le même réseau, déclenche ce défaut avec une requête normale. Au moment de la divulgation, il n’existait pas de preuve de concept publique, mais le bug ne demande aucune compétence particulière pour être reproduit.

Défenses

1. Mettez à jour maintenant. Passez à mcp-server-kubernetes 3.6.0 ou ultérieur, qui applique dans tools/call les mêmes restrictions qu’il appliquait déjà dans tools/list. C’est le seul correctif qui ferme réellement la faille.

2. Traitez le RBAC comme la vraie frontière. Le « mode lecture seule » applicatif est un confort, pas un contrôle. Donnez au Service Account du serveur le moindre privilège dont il a réellement besoin. Si un agent ne fait qu’observer des pods, son SA ne doit pas pouvoir les supprimer — quel que soit le réglage applicatif.

3. N’exposez pas le point d’accès. Gardez le serveur MCP hors de l’internet public, accessible uniquement depuis des réseaux de confiance ou via un tunnel sécurisé, et exigez une authentification forte (le projet prend en charge MCP_AUTH_TOKEN).

4. Auditez vos propres serveurs d’outils pour ce schéma. Si vous construisez ou exploitez des serveurs MCP, vérifiez que chaque décision d’autorisation est appliquée à tools/call, pas seulement à tools/list. Le filtrage à la découverte relève de l’UX ; le filtrage à l’exécution relève de la sécurité. Test rapide : appelez un outil censé être masqué et confirmez que le serveur le refuse.

5. Journalisez au niveau de l’exécution. Enregistrez les appels tools/call avec le nom de l’outil et le résultat, pour qu’une requête vers un outil « filtré » reste visible a posteriori, même si un contrôle manque.

Statut

Élément	Référence	Date	Notes
Avis de sécurité GitHub	GHSA-cr22-wjx7-2w6m	2026-05	Avis source, correctif en v3.6.0
Enregistrement CVE	NVD CVE-2026-46519	2026-05	CVSS 8.8 élevé, CWE-863
Analyse technique	NeuralTrust	2026-05-19	Découverte vs exécution
GitLab Advisory DB	GLAD	2026-05-21	Affecté : toutes versions < 3.6.0
Couverture presse	TheHackerWire	2026-06-11	Aucun PoC public à la publication
Version corrigée	mcp-server-kubernetes	v3.6.0	Contrôles ajoutés à l’exécution

Le titre n’est pas « MCP Kubernetes est dangereux ». C’est que l’autorisation doit s’appliquer là où l’action se produit, pas là où le menu est dessiné — une règle que le web a apprise il y a vingt ans et que l’outillage des agents réapprend, une CVE à la fois.