Vulnérabilités back-end MCP : les failles classiques refont surface dans les passerelles IA-bases de données

What is this?

Le 12 mai 2026, Tomer Peled (Akamai) a publié One Is a Fluke, 3 Is a Pattern: MCP Back-End Vulnerabilities, une divulgation coordonnée couvrant trois failles trouvées dans environ 300 serveurs MCP (Model Context Protocol) officiels. La recherche met en avant CVE-2025-66335 (injection SQL dans Apache Doris MCP, assignée le 7 janvier 2026, corrigée le 30 décembre 2025), un chemin d’exécution SQL non authentifié dans le serveur MCP Apache Pinot de StarTree (versions ≤ 1.1.0), et une divulgation d’information dans le composant RAG d’Alibaba RDS MCP qu’Alibaba a refusé de corriger.

Les bugs eux-mêmes sont des classiques : validation d’entrée absente, authentification manquante sur un transport HTTP, et un endpoint RAG non authentifié exposant des métadonnées de schéma. Ce qui rend ce rapport intéressant, c’est le motif. MCP, le protocole ouvert lancé par Anthropic en 2024 pour permettre aux LLM de dialoguer avec des systèmes externes, laisse aux développeurs presque toutes les décisions de sécurité back-end — authentification, gestion des credentials, périmètre de privilèges, validation des requêtes. Les trois serveurs cassés par Akamai ne sont pas des exceptions ; ce sont des échantillons.

How it works

Un serveur MCP s’intercale entre un agent IA et un système back-end (ici, une base de données). Chaque serveur expose des « tools » que le modèle peut invoquer, et chaque serveur décide seul de la manière dont il authentifie l’appelant et valide les paramètres avant de parler au back-end.

CVE-2025-66335 — injection SQL dans Apache Doris MCP. Doris MCP encapsule un Security Manager qui authentifie un JWT, attribue un niveau d’habilitation et lance un validateur SQL. La signature interne :

async def exec_query_for_mcp(
        self,
        sql: str,
        db_name: str = None,
        catalog_name: str = None,
        max_rows: int = 100,
        timeout: int = 30
    ) -> Dict[str, Any]:
    # Cinq paramètres, mais seul `sql` est envoyé au validateur.
    # `db_name` est concaténé tel quel dans la requête finale.

Le validateur parse l’argument sql et s’arrête là. Le paramètre db_name — également concaténé dans la requête finale — n’est jamais assaini. N’importe quel client connecté au serveur MCP peut donc passer dans db_name des valeurs contenant des points-virgules, des commentaires ou des instructions complètes, et exécuter du SQL arbitraire contre l’instance Doris. La pratique du validateur consistant à n’inspecter que le début de l’instruction analysée amplifie le problème. Apache a corrigé en v0.6.1 (30 décembre 2025) ; le CVE a été assigné le 7 janvier 2026.

Apache Pinot MCP — contournement de validation d’authentification. L’intégration Pinot de StarTree (≤ 1.1.0) supporte un transport HTTP lié à 0.0.0.0:8080. Quand HTTP est activé, le serveur ne requiert aucune authentification, et le « validateur » fourni vérifie uniquement que la requête commence par SELECT :

# Illustratif — paraphrasé depuis la divulgation.
if path == server_config.endpoint and method == "POST":
    await transport.handle_post_message(scope, receive, send)
# Pas de contrôle d'auth avant l'invocation des outils.
# Validateur : query.upper().startswith("SELECT")

Tout attaquant distant capable d’atteindre l’endpoint peut envoyer des requêtes SELECT arbitraires — suffisant pour de l’exfiltration de données complète et, combiné à des astuces de concaténation, à une prise de contrôle plus large. StarTree a ajouté OAuth comme option d’authentification le 14 octobre 2025, ce qui réduit la sévérité pour les déploiements correctement configurés mais n’élimine pas le défaut de validation SQL sous-jacent.

Alibaba RDS MCP — endpoint RAG non authentifié. Le serveur RDS MCP d’Alibaba embarque un composant RAG FastMCP qui écoute sur 0.0.0.0:8006 et expose un unique outil get_table_struct réalisant une recherche par similarité vectorielle sur un index interne de schémas de tables. Aucune authentification, aucune validation de requête : n’importe quel client capable d’atteindre l’endpoint peut extraire les métadonnées de schéma — noms de tables, structures de colonnes et autres éléments de fingerprinting opérationnel. Alibaba a marqué le problème comme « not applicable » pour un correctif ; Akamai a escaladé auprès du CERT/CC le 25 novembre 2025.

Why it matters

Trois observations rendent cette divulgation utile au-delà des bugs individuels.

Premièrement, MCP hérite des vulnérabilités web classiques et les amplifie. Une injection SQL dans un outil d’administration de base de données autonome est bornée par les personnes pouvant atteindre l’outil. Une injection SQL dans un serveur MCP est atteignable depuis tout ce qui peut parler à l’agent — y compris, dans certains déploiements, par du contenu injecté via prompt arrivant par un canal entièrement différent. La surface d’exposition s’étend à chaque nouveau connecteur.

Deuxièmement, la flexibilité du protocole est la classe de vulnérabilité. MCP laisse délibérément les décisions de sécurité back-end aux implémenteurs. Ce choix est raisonnable au niveau du protocole mais lourd de conséquences en pratique : la revue d’Akamai du parc officiel a trouvé une grande variance dans l’authentification, l’autorisation et le traitement des paramètres. L’OWASP GenAI Security Project a publié un Practical Guide for Secure MCP Server Development — mais son adoption est en retard sur le rythme de déploiement.

Troisièmement, refuser de patcher est une décision de politique aux conséquences en aval. La position « not applicable » d’Alibaba sur RDS MCP signifie qu’un index vectoriel de métadonnées de schéma client reste accessible sans authentification pour tout opérateur déployant le serveur officiel tel quel. Les utilisateurs finaux qui embarquent cette intégration en production héritent de la décision.

Defenses

La publication Akamai et le guide OWASP convergent vers un petit ensemble de contrôles. Aucun ne suffit isolément, mais ensemble ils neutralisent la classe publiée.

1. Exiger une authentification au niveau du transport. Tout serveur MCP lié à une interface réseau au-delà de localhost doit exiger une authentification avant d’exposer ses outils. Traitez le transport HTTP nu (0.0.0.0:8080, 0.0.0.0:8006) comme une mauvaise configuration de sévérité critique, indépendamment du caractère « interne » apparent du réseau.
2. Valider chaque paramètre côté serveur. Des validateurs qui n’inspectent qu’un argument sur cinq (Doris) ou qui se contentent de vérifier qu’une requête commence par SELECT (Pinot) sont des cases à cocher, pas des contrôles. Utilisez des requêtes paramétrées ou des query builders qui ne peuvent pas concaténer des chaînes non fiables dans le SQL final.
3. Appliquer le moindre privilège sur les credentials back-end. Le compte de service MCP ne doit détenir que les droits dont les outils exposés ont besoin : lecture seule sur les tables précises en périmètre, pas de DDL, pas d’accès cross-schema. Une injection SQL réussie contre un compte au moindre privilège reste confinée au schéma ; contre un compte admin, elle est totale.
4. Auditer le serveur MCP officiel que vous distribuez. Les serveurs MCP édités par un fournisseur ne sont pas implicitement sûrs. Lisez le code d’authentification, le binding de transport, le traitement des paramètres, et figez-vous sur une version connue corrigée. Pour Doris spécifiquement : mettre à niveau en v0.6.1 ou plus récent (correctif de CVE-2025-66335). Pour Pinot : activer OAuth et envisager de bloquer le transport HTTP. Pour Alibaba RDS MCP : n’exposez pas l’endpoint RAG au-delà de réseaux authentifiés et de confiance.
5. Segmenter le serveur MCP au niveau réseau. Même avec authentification, un serveur MCP qui fait face à une base de données doit se trouver derrière les mêmes contrôles réseau que la base elle-même. Si votre base de données n’est pas exposée directement sur Internet, le serveur MCP qui la fronte ne doit pas l’être non plus.
6. Traiter les paramètres d’outils MCP comme des entrées utilisateur. Le modèle n’est pas votre validateur d’entrée. Toute chaîne que le modèle passe à un outil est, du point de vue du back-end, contrôlée par l’attaquant — parce que le modèle peut lire un contexte contrôlé par l’attaquant. Validez à la frontière de l’outil, à chaque fois.

Status

Élément	Référence	Date	Notes
Divulgation Pinot (StarTree)	Chronologie Akamai	2025-09-30	Éditeur contacté
Mitigation Pinot (ajout OAuth)	StarTree	2025-10-14	Réduit la sévérité, ne ferme pas la classe SQLi
Divulgation Alibaba RDS MCP	Chronologie Akamai	2025-11-17	Éditeur contacté
Alibaba refuse de patcher	Chronologie Akamai	2025-11-25	Escalade CERT/CC initiée
Divulgation Doris MCP	Chronologie Akamai	2025-11-27	Apache contacté
Correctif Doris (v0.6.1)	Apache	2025-12-30	Valide db_name
CVE-2025-66335 assigné	NVD	2026-01-07	Injection SQL (CWE-89)
Issue publique Pinot MCP ouverte	GitHub	2026-05-04	Étape publique coordonnée
Publication Akamai	Blog Akamai	2026-05-12	Recherche complète, avec un outil de détection
Couverture The Register	The Register	2026-05-13	Reportage indépendant
Présentation de la recherche	x33fcon	2026-06 (prévue)	Outillage attendu en publication

L’apport durable de cette divulgation n’est pas les trois bugs de classe CVE — ils seront patchés, ignorés ou contournés au cas par cas. C’est la démonstration que le tier serveur MCP est une nouvelle surface d’attaque qui hérite de décennies de problèmes de sécurité back-end non résolus, habillés d’un outillage neuf et déployés plus vite que ne se diffuse la guidance de sécurité. La prochaine vague d’intégrations MCP répétera le motif tant que l’authentification, la validation et le moindre privilège ne seront pas conçus dès le premier commit du connecteur.