Deux avis de sécurité publiés par AWS le 9 septembre 2026 donnent une forme concrète à un risque souvent décrit de manière abstraite : lorsqu’un outil d’IA peut interroger une base de données de production, une règle de correspondance sur une chaîne de caractères ne doit jamais être sa dernière ligne de défense. Les avis concernent deux serveurs Model Context Protocol open source et auto-hébergés d’AWS Labs, l’un pour PostgreSQL et l’autre pour MySQL. Tous deux proposent un mode lecture seule censé empêcher un assistant d’émettre du SQL modifiant l’état de la base. Dans les deux cas, le compte de base de données reste le contrôle qui décide, en dernier ressort, de ce qui peut réellement se produire.

Illustration abstraite d’un réseau d’IA et d’une base de données séparés par une barrière d’avertissement, représentant les limites des filtres textuels en lecture seule.

Le problème PostgreSQL est le plus grave des deux. AWS a attribué CVE-2026-87911 à une faiblesse pouvant permettre l’exécution de commandes du système d’exploitation lorsqu’une combinaison précise est réunie : version du paquet, méthode de connexion, privilèges de base de données et interaction utilisateur. La version corrigée est la 1.1.7.

La divulgation MySQL, CVE-2026-85788, décrit une autre défaillance dans la vérification de lecture seule : dans certaines conditions, des commentaires SQL intégrés pouvaient contourner le filtre. Les versions affectées sont la 1.0.21 et les versions antérieures, et AWS indique que le problème est corrigé en 1.0.23.

Il ne s’agit pas de vulnérabilités côté service dans Aurora, RDS ou un autre plan de contrôle managé par AWS. Ce sont des problèmes dans des paquets côté client que les clients installent et exploitent eux-mêmes. Cette distinction compte pour la réponse à incident, mais elle ne rend pas ces avis secondaires. Ces paquets relient un assistant d’IA à des bases de données, à des identifiants et, dans certaines configurations, à l’hôte sur lequel le serveur s’exécute. Une petite erreur de parseur peut donc devenir un problème de contrôle d’accès au point exact où des demandes en langage naturel sont transformées en opérations de base de données.

Ce qu’AWS a divulgué

Les deux bulletins sont arrivés ensemble, mais ils décrivent des conditions techniques différentes et doivent être triés séparément. Les traiter comme une seule vulnérabilité MCP générique rendrait la réponse moins précise.

Pour awslabs.postgres-mcp-server, AWS indique que les versions antérieures à 1.1.7 contiennent une faiblesse d’injection de commandes du système d’exploitation dans l’application du mode lecture seule par le composant de validation SQL. Le bulletin désigne une instruction PostgreSQL COPY ... TO PROGRAM spécialement construite comme la fonctionnalité de base de données pertinente. Dans un déploiement vulnérable, du contenu traité lorsqu’un utilisateur authentifié interagit avec le serveur MCP pouvait atteindre ce chemin, alors même que le serveur fonctionnait dans son mode lecture seule par défaut.

Le bulletin ne dit pas que chaque installation est exploitable à distance. Il décrit un profil de déploiement plus restreint : un serveur PostgreSQL auto-géré utilisant la méthode de connexion PG_WIRE_PROTOCOL, avec un rôle de base de données configuré disposant des privilèges de superutilisateur ou du rôle pg_execute_server_program. AWS décrit la conséquence possible comme une exécution de commandes du système d’exploitation sur l’hôte du serveur PostgreSQL auto-géré. Le mot « possible » compte ici. L’avis établit l’existence d’une vulnérabilité dangereuse et les conditions qui la rendent pertinente ; il n’établit pas que des clients ont été attaqués.

La documentation de PostgreSQL explique pourquoi la condition de privilège change la gravité. Une commande PROGRAM est exécutée par le serveur de base de données plutôt que par le client, et PostgreSQL réserve cette capacité aux superutilisateurs ou aux utilisateurs auxquels le rôle d’exécution de programme serveur a été accordé. Autrement dit, le privilège de base de données est déjà puissant par conception. La faiblesse MCP est importante parce qu’elle peut laisser une entrée franchir une limite que le mode lecture seule du paquet était supposé faire respecter.

Pour awslabs.mysql-mcp-server, AWS indique que les versions jusqu’à 1.0.21 peuvent laisser une instruction s’exécuter alors que la vérification de lecture seule devait la bloquer, au moyen de commentaires SQL intégrés dans certaines conditions. Le bulletin ne décrit pas le même chemin vers l’exécution de commandes du système d’exploitation que l’avis PostgreSQL. Il précise que le paquet est auto-hébergé et que le problème n’affecte pas la confidentialité ou l’intégrité d’un service AWS. Le risque pratique est qu’un compte de base de données disposant de privilèges plus larges que prévu puisse effectuer une écriture que la vérification applicative tentait de rejeter.

Les versions corrigées sont les premiers faits opérationnels à consigner : PostgreSQL 1.1.7 ou version ultérieure, et MySQL 1.0.23 ou version ultérieure. Il ne faut pas déduire que la mise à niveau d’un paquet corrige l’autre. Ce sont des distributions distinctes, avec des lignes de publication distinctes, et un parc peut très bien contenir les deux.

Pourquoi l’expression « lecture seule » a semé la confusion

Beaucoup d’outils de base de données emploient « lecture seule » comme s’il s’agissait d’une propriété unique. Ce n’est pas le cas. Au moins trois contrôles différents se cachent derrière cette expression.

Le premier est un parseur ou un filtre dans l’application. Il examine le texte SQL et rejette les jetons associés aux écritures, aux changements de session ou à d’autres opérations sensibles. C’est rapide et utile pour le retour utilisateur. Cela peut arrêter des erreurs ordinaires, par exemple lorsqu’un assistant produit un UPDATE alors que l’utilisateur demandait un rapport.

Le deuxième est le mode de session ou de transaction de la base de données. PostgreSQL et MySQL disposent chacun de mécanismes pouvant contraindre ce qu’une session peut faire, même si le comportement exact et les exceptions dépendent du moteur, de la méthode de connexion et du compte. Un réglage au niveau de la session peut ajouter une couche, mais il ne remplace pas les privilèges du compte et doit être testé avec la charge de travail exacte.

Le troisième est l’identité de base de données elle-même : le rôle ou l’utilisateur qui s’authentifie auprès du serveur. Cette identité possède des droits, des propriétés d’objets, des appartenances à des rôles, des accès à des procédures stockées et parfois des capacités spéciales côté serveur. C’est la frontière durable, car la base de données l’évalue après le passage de la requête par le client, le serveur MCP, le parseur SQL et toute politique intermédiaire.

Le README actuel d’AWS pour le serveur PostgreSQL dit explicitement que l’application du mode lecture seule est une protection au mieux, pas une frontière de sécurité. Il recommande un rôle de base de données dédié et déconseille l’usage d’un superutilisateur, de rds_superuser ou de l’utilisateur maître du cluster. Le README MySQL formule le même point : la garde fondée sur le texte SQL est une défense en profondeur, tandis que le rôle de base de données configuré constitue la vraie frontière.

Ces divulgations rendent cette documentation opérationnelle, et non théorique. Les filtres textuels travaillent sur la représentation qu’ils reconnaissent. SQL possède des commentaires, des identifiants entre guillemets, des syntaxes conditionnelles, des routines stockées, des fonctionnalités propres aux versions, des instructions multiples et des comportements de parseur qui évoluent avec le temps. Un LLM ajoute une autre source de variation : il peut produire une entrée inhabituelle mais syntaxiquement valide, et il peut être influencé par du contenu renvoyé par une base de données ou par un autre outil. On ne peut pas attendre d’une expression régulière qu’elle modélise toutes ces interactions.

Une conception robuste pose donc deux questions différentes. « Le serveur MCP rejettera-t-il cette demande ? » est utile pour réduire les écritures accidentelles. « Si le serveur l’accepte, que peut faire le compte de base de données ? » est la question qui limite l’impact. La deuxième réponse doit rester acceptable lorsque le premier contrôle est contourné, mal configuré, obsolète ou simplement incomplet.

Qui doit traiter ce sujet comme une revue urgente

L’avis PostgreSQL concerne d’abord les organisations qui ont installé le paquet AWS Labs avant la version 1.1.7 et qui se connectent à un déploiement PostgreSQL auto-géré au moyen du protocole filaire. Le rôle de base de données mérite une attention immédiate s’il est superutilisateur ou s’il possède pg_execute_server_program. Un déploiement utilisant Aurora ou un autre profil managé peut ne pas correspondre au profil affecté tel que décrit dans l’avis, mais les opérateurs doivent tout de même mettre à niveau le paquet : les versions font partie de la chaîne d’approvisionnement logicielle, et les recommandations de sécurité du serveur s’appliquent au-delà d’une condition d’exploitation précise.

L’avis MySQL s’applique aux installations en version 1.0.21 ou antérieure. Comme ce paquet est souvent lancé via une plage de versions ou une référence flottante latest, les équipes ne doivent pas supposer qu’une configuration fonctionnelle leur dit quel code s’exécute. Il faut déterminer la version réellement installée depuis l’environnement client, l’image de conteneur, le fichier de verrouillage ou l’artefact de déploiement. Le résultat doit être consigné, plutôt que déduit à partir d’un nom de paquet dans un fichier de configuration.

Les équipes doivent aussi revoir la manière dont les identifiants sont choisis. La documentation d’AWS Labs décrit des connexions qui utilisent des identifiants AWS pour découvrir des ressources de base de données et des identifiants Secrets Manager pour s’authentifier auprès de la base. Un serveur MCP connecté à une base peut donc avoir deux plans de permission : les permissions AWS IAM et les permissions de base de données. Un rôle IAM restrictif ne rend pas automatiquement une connexion de base de données en lecture seule, et un rôle de base de données en lecture seule n’empêche pas automatiquement le serveur MCP de lire des métadonnées AWS sensibles ou des fichiers locaux si la configuration alentour lui accorde ces capacités.

Le risque augmente lorsque le serveur s’exécute sur un poste de développeur contenant aussi du code source, des identifiants cloud, du matériel SSH, des artefacts de build ou des sessions de navigateur. Il augmente également lorsque le serveur MCP est exposé sur un réseau, partagé entre plusieurs utilisateurs ou lancé avec un identifiant d’administrateur étendu. La documentation du serveur AWS API MCP, bien qu’elle concerne un paquet lié mais distinct, avertit que sa conception locale via STDIO suppose un seul utilisateur et un accès direct à l’hôte ; elle précise aussi qu’IAM demeure le contrôle principal et que les classifications en lecture seule ne garantissent pas que la sortie d’une commande soit inoffensive. Ce sont aussi de bons avertissements d’architecture pour les déploiements MCP reliés à des bases de données.

La première réponse doit être l’inventaire, pas la spéculation

Un opérateur qui répond à ces bulletins n’a pas besoin de commencer par prouver l’exploitabilité. Le premier objectif consiste à établir si le code vulnérable et les conditions de privilèges existent. Un inventaire court peut répondre à la plupart des questions à forte valeur.

  • Identifier chaque installation de awslabs.postgres-mcp-server et de awslabs.mysql-mcp-server, y compris les configurations locales des développeurs, les conteneurs, les workers CI, les bastions partagés et les environnements IDE empaquetés.
  • Consigner la version exacte, la méthode de lancement, la méthode de connexion, le moteur de base de données et le profil du point de terminaison de base de données pour chaque installation.
  • Relier l’utilisateur ou le rôle de base de données utilisé par chaque serveur à ses droits et appartenances. Chercher en particulier le statut de superutilisateur PostgreSQL, pg_execute_server_program, les privilèges administratifs MySQL, les droits larges sur les schémas, l’exécution de procédures stockées et la propriété d’objets de production.
  • Déterminer si le serveur est strictement local ou joignable sur un réseau, et si plusieurs personnes ou locataires peuvent invoquer le même processus.
  • Vérifier si le serveur peut écrire dans la base, lire des fichiers locaux, invoquer des API cloud ou renvoyer des secrets dans la sortie d’outil.
  • Préserver les manifestes de paquets pertinents, les digests de conteneurs, l’historique de configuration, les journaux d’authentification, les enregistrements d’audit de base de données et les journaux du client MCP avant de modifier l’environnement.

L’objectif est de construire une trame factuelle. « Nous utilisons un assistant d’IA » ne suffit pas à évaluer le problème. Un serveur PostgreSQL auto-géré avec un rôle de reporting à faibles privilèges est un cas différent d’un ordinateur portable de développeur utilisant un identifiant maître de cluster contre une base de production. Les deux peuvent pourtant exécuter le même nom de paquet.

Mettre à niveau, puis réduire les privilèges

La remédiation immédiate consiste à passer aux versions corrigées par le fournisseur : serveur MCP PostgreSQL 1.1.7 ou ultérieur, et serveur MCP MySQL 1.0.23 ou ultérieur. Il faut épingler la version dans le mécanisme qui lance réellement le serveur. Si une configuration utilise @latest, une plage de versions large ou une balise de conteneur non épinglée, la prochaine mise à jour peut être plus sûre, mais l’état actuel restera difficile à reproduire et à auditer. Utilisez un fichier de verrouillage, un digest d’image immuable ou un mécanisme de publication contrôlé équivalent.

Après la mise à niveau, modifiez les permissions de base de données si elles dépassent ce que la tâche exige. Pour un flux de reporting, un rôle dédié ne devrait généralement avoir accès qu’à la base, aux schémas, aux tables, aux vues et aux routines strictement nécessaires. La documentation PostgreSQL et le README d’AWS Labs écartent tous deux les superutilisateurs et les privilèges d’exécution de programmes serveur pour ce type d’intégration. Un rôle qui doit seulement lire des vues de reporting approuvées ne devrait pas hériter d’un rôle capable d’administrer le cluster ou d’exécuter des programmes sur l’hôte de la base.

Le même principe vaut pour MySQL. Le README d’AWS Labs recommande un compte dédié doté uniquement des droits nécessaires, par exemple SELECT sur la base pertinente et EXECUTE seulement pour des procédures précisément approuvées. Il explique aussi que le filtre côté serveur est conçu pour détecter les instructions modificatrices courantes, mais qu’il ne peut pas garantir une protection contre tous les cas limites de grammaire ou les futures fonctionnalités SQL. Le mode de défaillance fiable doit être une erreur de base de données causée par un privilège manquant, pas un message assuré de l’assistant affirmant qu’une écriture a été bloquée.

Il ne faut pas « corriger » le problème en ajoutant une règle de prompt plus élaborée. Les instructions de prompt peuvent améliorer le comportement, mais elles ne sont pas du contrôle d’accès. Les fichiers d’orientation, les messages système, les listes d’approbation et les confirmations humaines ont tous leur place dans une conception en couches ; aucun ne doit être la seule barrière protégeant les données de production. Un utilisateur ou un document injecté peut influencer le texte envoyé au modèle, et un modèle peut produire une demande que l’auteur du prompt n’avait pas prévue. Le compte qui exécute la demande doit rester incapable de dépasser le périmètre voulu.

Vérifier séparément le plan de permissions AWS

Certaines équipes se concentreront sur le filtre SQL et manqueront les permissions AWS utilisées par le processus MCP. Le README PostgreSQL indique que le serveur peut utiliser un profil AWS pour découvrir des clusters ou des instances et, pour le chemin RDS Data API, peut avoir besoin de l’autorisation d’exécuter des instructions. Il utilise aussi Secrets Manager pour récupérer les identifiants de base de données dans les configurations documentées. Ces décisions sont séparées des droits de l’utilisateur de base de données.

Employez un rôle ou un profil IAM conçu pour ce processus. Limitez l’accès aux ressources lorsque le service AWS le permet, et évitez d’attacher des politiques d’administrateur simplement parce que l’assistant pourrait devoir inspecter l’infrastructure. Les recommandations IAM d’AWS préconisent le moindre privilège, des identifiants temporaires pour les charges de travail lorsque c’est possible, une revue régulière des permissions inutilisées et l’usage d’IAM Access Analyzer pour affiner les politiques à partir de l’activité observée.

Souvenez-vous que « lecture seule » au niveau de l’API AWS n’est pas synonyme de « sortie sûre ». Certaines opérations de lecture peuvent renvoyer de la configuration, des identifiants, des documents de politique ou d’autres éléments sensibles. La documentation du serveur AWS API MCP le signale directement. Un assistant de base de données capable de combiner découverte cloud, récupération de secrets, requêtes de base et opérations sur les fichiers locaux possède une autorité effective bien plus large que ne le suggèrent les mots « SQL en lecture seule ».

Séparez les fonctions lorsque c’est possible. Un outil qui répond à des questions sur des données approuvées n’a pas nécessairement besoin de créer des clusters, de modifier des contrôles réseau, de récupérer des secrets arbitraires ou d’écrire des fichiers. Si un flux de travail a besoin de ces capacités, placez-les derrière un outil et une identité approuvés séparément, au lieu de les ajouter au processus de reporting généraliste.

Auditer l’usage des versions vulnérables

Les avis n’établissent pas que les failles ont été exploitées dans la nature. Une discussion publique autour d’un CVE n’est pas la preuve d’un incident, et la présence d’un paquet vulnérable ne prouve pas qu’un attaquant l’a atteint. Il reste raisonnable d’examiner les journaux, car le chemin vulnérable relie du contenu contrôlé par l’utilisateur à une surface d’exécution de base de données.

Pour PostgreSQL, examinez les journaux de base de données et les enregistrements d’audit afin de repérer un usage inhabituel de fonctionnalités serveur liées aux fichiers ou aux programmes, des changements de rôle inattendus, la création de fonctions inconnues, des modifications de la configuration d’authentification et une activité du compte de service MCP hors de son profil de requêtes habituel. Examinez la télémétrie de l’hôte du serveur de base de données pour repérer des processus, fichiers, connexions réseau ou mécanismes de persistance qui ne s’expliquent pas par la charge de travail de la base. Gardez cette revue au niveau de la détection défensive ; un article ou un ticket d’incident ne doit pas devenir une recette pour reproduire l’exécution de commandes.

Pour MySQL, recherchez les instructions qui auraient dû être bloquées mais apparaissent dans les journaux d’audit, les changements inattendus sur des tables de production, l’usage de privilèges administratifs ou liés aux fichiers, et les connexions du compte MCP depuis des clients ou à des horaires inhabituels. Comparez, lorsque ces traces existent, les instructions observées avec les demandes en langage naturel qui les ont générées. Un décalage peut révéler une injection de prompt, un contrat d’outil trop large, un problème de parseur ou une erreur ordinaire du modèle.

CloudTrail peut aider sur le versant AWS de l’enquête, mais il ne remplace pas la télémétrie de la base de données et de l’hôte. Cherchez des lectures inattendues dans Secrets Manager, des découvertes RDS ou de clusters hors du flux normal, des modifications IAM ou de groupes de sécurité, et des accès provenant d’identités associées au processus MCP. Corrélez les horodatages entre le client MCP, la base de données, le système d’exploitation et les journaux cloud.

Si des éléments suggèrent un accès non autorisé, suivez le processus de réponse à incident de l’organisation : isolez le processus affecté, faites tourner ou révoquez les identifiants lorsque c’est approprié, préservez les preuves et évaluez l’intégrité de la base et de l’hôte. Une mise à niveau seule ne constitue pas une réponse à incident complète si un identifiant privilégié a pu être utilisé.

Ce que cela change pour la conception des déploiements MCP

Les correctifs immédiats sont des mises à jour de paquets, mais la leçon plus large concerne la place qu’une intégration d’IA est autorisée à occuper dans l’architecture. Un serveur MCP qui traduit le langage naturel en SQL n’est pas seulement un adaptateur pratique. C’est un interpréteur placé entre une personne, un modèle, un protocole d’outil et un système à état. Chaque couche peut transformer la demande ou lui ajouter du sens.

Il faut donc des contrôles qui restent compréhensibles lorsque le modèle se comporte de façon inattendue. Un déploiement utile sépare les analyses en lecture seule de l’accès opérationnel aux bases de données. Il utilise un rôle de base de données créé spécialement pour l’intégration, limite ce rôle aux objets approuvés et conserve les écritures de production dans un flux exigeant une identité distincte et un processus de changement explicite. Il garde le serveur MCP local ou autrement isolé lorsque le produit est conçu pour une opération STDIO mono-utilisateur. Il contraint l’hôte, les sorties réseau, les secrets et l’accès au système de fichiers autour du processus.

Il rend aussi les versions et la configuration observables. L’équipe doit pouvoir dire quel paquet MCP s’est exécuté, avec quels arguments, sous quelle identité, contre quelle base de données, et quel appel d’outil a produit chaque requête. Si ces réponses ne sont pas disponibles, une divulgation de vulnérabilité déclenchera un long débat sur ce qui pourrait être installé, au lieu d’une décision rapide de remédiation.

Les tests doivent couvrir le contrat de sécurité réel, pas seulement une requête nominale qui réussit. Vérifiez que les demandes ordinaires de lecture fonctionnent, que les écritures non autorisées échouent au niveau de la base, que le processus ne peut pas utiliser de fonctionnalités serveur privilégiées, que les erreurs se ferment dans un état sûr et qu’une entrée mal formée ou inattendue ne désactive pas silencieusement une politique. Testez ce comportement après les mises à niveau de dépendances et après les mises à niveau du moteur de base de données. Le but n’est pas de prouver qu’un filtre reconnaît toutes les orthographes SQL possibles ; le but est de prouver qu’une demande non fiable ne peut pas dépasser le résultat permis par l’identité.

La conclusion pratique

Les bulletins publiés par AWS le 9 septembre rappellent au bon moment que « lecture seule » est une affirmation de conception qui doit être appliquée à plusieurs endroits. Le problème PostgreSQL exige une attention particulière lorsqu’un ancien paquet est connecté par le protocole filaire à un serveur auto-géré avec un rôle superutilisateur ou pg_execute_server_program. Le problème MySQL affecte les anciennes versions du paquet et montre qu’une syntaxe SQL qui paraît inoffensive à un filtre textuel peut quand même compter.

Mettez à niveau les deux paquets là où ils sont présents. Inventoriez les versions réellement lancées et les méthodes de connexion. Remplacez les comptes de base de données puissants par des rôles étroitement bornés. Revoyez le profil IAM, l’accès aux secrets, les permissions de l’hôte et l’exposition réseau autour du processus MCP. Ensuite, utilisez les journaux de base de données, d’hôte et de cloud pour déterminer si les installations affectées étaient seulement vulnérables ou si elles ont aussi été détournées.

Le conseil qui tient dans le temps est simple, même si sa mise en œuvre demande du travail : laissez la base de données faire respecter la frontière de la base de données. Traitez les instructions du modèle et les filtres SQL comme des couches utiles autour de cette frontière, pas comme son substitut.

Sources

  • Amazon Web Services, « CVE-2026-87911 - Read-only enforcement bypass enabling operating system command execution in the SQL validation component of Amazon awslabs postgres-mcp-server », publié le 9 septembre 2026.
  • Amazon Web Services, « CVE-2026-85788 - Issue with awslabs mysql-mcp-server », publié le 10 septembre 2026.
  • AWS Labs, « AWS Labs postgres MCP Server README and security model », consulté comme contexte de sécurité du paquet.
  • AWS Labs, « AWS Labs mysql MCP Server README and security model », consulté comme contexte de sécurité du paquet.
  • PostgreSQL Global Development Group, « PostgreSQL COPY documentation », utilisé pour le comportement de COPY et de PROGRAM.
  • Amazon Web Services, « Security best practices in IAM », utilisé pour les recommandations de moindre privilège.
  • Amazon Web Services, « AWS Identity and Access Management User Guide », utilisé comme contexte IAM général.
  • AWS Labs, « aws-api-mcp-server: migration to AWS MCP Server », discussion publiée le 10 juillet 2026 et utilisée pour les avertissements d’architecture autour de STDIO, IAM et des classifications de lecture seule.