mcp-pinot : un serveur MCP non authentifié en député confus

De quoi s’agit-il ?

Le 18 juin 2026, une vulnérabilité critique a été publiée dans mcp-pinot, un serveur Model Context Protocol (MCP) open source qui permet à un agent LLM d’interroger et d’administrer un cluster d’analytique temps réel Apache Pinot. Dans la version 3.0.1 et les antérieures, le serveur démarrait un point d’accès MCP HTTP lié à 0.0.0.0:8080 avec l’authentification désactivée par défaut. Tout appelant capable d’atteindre ce port — une machine sur le même réseau, un conteneur voisin, ou n’importe quoi derrière un pare-feu mal configuré — pouvait invoquer chaque outil exposé par le serveur, sans s’authentifier.

Les mainteneurs (StarTree) ont corrigé le problème dans la version 3.1.0, publiée le 25 mai 2026, avant la divulgation publique. La faille est notée 10.0 (critique) et constitue un cas d’école de député confus (confused deputy) : ce sont les identifiants du serveur, et non ceux de l’attaquant, qui font les dégâts.

Comment ça marche

Il s’agit d’un défaut de configuration et de conception, pas d’une corruption mémoire ; le mécanisme s’énonce donc sans payload exploitable.

Le serveur mcp-pinot se connecte à son cluster Pinot au moyen d’un compte de service chargé depuis des variables d’environnement (un jeton, ou un couple identifiant/mot de passe). Ces identifiants sont généralement privilégiés, car le serveur doit lire des tables, lister des schémas et parfois écrire de la configuration. Quand un client MCP appelle un outil comme read_query, le serveur transmet cet appel à Pinot en utilisant ses propres identifiants.

Dans la configuration par défaut vulnérable, rien ne filtrait ce relais. L’écouteur HTTP répondait sur toutes les interfaces (0.0.0.0) au lieu de la boucle locale (127.0.0.1), et OAuth était désactivé. Une requête non authentifiée pouvait donc atteindre directement la couche outils et emprunter l’identité du serveur jusque dans la base. Les outils exposés couvraient toute la surface du cluster : read_query exécute des requêtes SELECT arbitraires, list_tables et les divers outils de métadonnées énumèrent schémas et configuration, et create_schema, update_schema et update_table_config modifient le cluster là où le compte de service a des droits d’écriture. Un outil, reload_table_filters, renvoyait même à l’appelant les listes de filtres précédente et nouvelle du serveur — divulguant l’allowlist censée contraindre les requêtes.

C’est la portée qui en fait un député confus plutôt qu’un simple point d’accès exposé : le composant MCP vulnérable se trouve sur une frontière de sécurité, mais ses identifiants agissent sur une autre (le cluster Pinot). L’attaquant n’a jamais besoin de connaître le mot de passe de la base ; le député le dépense pour lui.

Pourquoi c’est important

Les serveurs MCP deviennent la colle standard entre les agents et les systèmes réels, et chacun est un petit proxy qui détient des identifiants pour une ressource de valeur. La posture réseau par défaut de ces serveurs est donc une décision de sécurité, pas un réglage de confort. Se lier à 0.0.0.0 « pour que ça marche depuis une autre machine » transforme discrètement un outil local en service réseau — et si ce service met en avant un compte de base de données privilégié sans authentification, le rayon d’impact est tout le backend.

Ce n’est pas un dérapage isolé. La même forme — un serveur HTTP proche de l’IA à l’écoute sur toutes les interfaces, authentification désactivée par défaut — a produit un autre défaut critique d’exécution de code à distance dans l’inspecteur MCP MCPJam plus tôt en 2026, et fait écho au schéma de la « triade létale » où un système combine accès privilégié, entrée non fiable et voie d’exfiltration. Les orientations nationales ont rattrapé le sujet : de récentes recommandations de conception MCP de la NSA et d’agences alliées insistent sur l’authentification, la confiance dans les serveurs et les contrôles de transport, justement parce que ces proxys continuent d’être livrés ouverts. La leçon, pour quiconque déploie un serveur MCP, est que sa configuration par défaut fait partie de votre surface d’attaque, avant même qu’un agent fasse quoi que ce soit d’astucieux.

Défenses

Se lier à la boucle locale par défaut. Un serveur MCP de développement ou mono-hôte devrait écouter sur 127.0.0.1, jamais 0.0.0.0, sauf choix explicite et revu d’exposer le service. Pour mcp-pinot en particulier, définissez MCP_HOST=127.0.0.1 si vous ne pouvez pas encore mettre à jour.

Ne jamais exposer un serveur d’outils non authentifié sur le réseau. Si l’accès distant est réellement nécessaire, exigez d’abord une authentification. mcp-pinot 3.1.0 refuse l’HTTP/HTTPS non-loopback tant qu’OAuth n’est pas activé ; activez-le (OAUTH_ENABLED=true) et placez le point d’accès derrière un VPN ou un tunnel SSH plutôt que sur l’internet ouvert.

Accorder au serveur le moindre privilège nécessaire. Traitez le compte de service derrière un serveur MCP comme exposé à internet. Réduisez ses droits en lecture seule quand c’est possible, restreignez-le aux tables strictement nécessaires à l’agent, et séparez lecture et écriture pour qu’un outil de lecture ne gagne pas silencieusement un pouvoir d’écriture.

Contraindre les outils, pas seulement le réseau. La validation des requêtes côté serveur compte même avec l’authentification activée. Le correctif 3.1.0 a ajouté pour read_query une validation, appuyée sur un parseur, mono-instruction et en lecture seule, afin qu’un outil de « lecture » ne puisse être détourné vers un comportement multi-instructions ou d’écriture. Appliquez la même rigueur à tout outil acceptant une entrée libre.

Rendre l’exposition opt-in dans votre outillage de déploiement. La version corrigée a aussi rendu son exposition Helm opt-in et conditionnée à OAuth. Configurez par défaut vos manifestes Kubernetes et conteneurs en mode fermé, pour qu’un chart copié-collé ne publie pas un proxy à identifiants par accident.

Statut

Élément	Référence	Date	Notes
Avis	GHSA-73cv-556c-w3g6 / CVE-2026-49257	18 juin 2026	Authentification manquante pour une fonction critique (CWE-306) ; CVSS 3.1 = 10.0 (AV:N/AC:L/PR:N/UI:N/S:C/C:H/I:H/A:H)
Affecté	mcp-pinot < 3.1.0	—	Serveur MCP HTTP lié par défaut à 0.0.0.0:8080, OAuth désactivé par défaut
Corrigé	v3.1.0	25 mai 2026	Liaison par défaut 127.0.0.1 ; non-loopback refusé sans OAuth ; exposition Helm opt-in et conditionnée OAuth ; validation lecture seule mono-instruction pour read_query
Cause racine	Député confus	—	Identifiants du compte de service Pinot côté serveur utilisés pour servir des appelants non authentifiés

La leçon pratique est étroite et transposable : un serveur MCP est un proxy à identifiants, et son adresse d’écoute et sa posture d’authentification par défaut sont des contrôles de sécurité. Vérifiez pour chaque serveur MCP que vous exécutez où il se lie et s’il authentifie avant de transmettre un appel d’outil — car les identifiants qu’il prête sont les vôtres.