Copilot pour SQL Server : un mode lecture seule par regex, l'injection de prompt et la voie vers sysadmin

De quoi s’agit-il ?

Le 30 septembre 2026, le chercheur Johann Rehberger (Embrace The Red) a publié le compte rendu de son intervention à BlueHat Asia 2026 sur Copilot dans SQL Server Management Studio (SSMS). Microsoft suit le problème comme une vulnérabilité d’élévation de privilèges de SQL Server, publiée dans son Security Update Guide le 8 septembre 2026, avec un score CVSS 3.1 de 9,6 (critique). Les recherches initiales remontent à mai 2026.

Ce cas illustre une erreur récurrente en sécurité des agents : une propriété de sûreté (« lecture seule ») appliquée par analyse de texte côté application plutôt que par la base de données elle-même.

Comment cela fonctionne

Selon l’article, le mode lecture seule de Copilot reposait sur un classifieur à base d’expressions régulières chargé de juger si une instruction générée pouvait être exécutée. Un tel classifieur inspecte la chaîne, pas l’effet. Le chercheur a montré qu’une exécution dynamique via une variable pouvait échapper au contrôle, de sorte que des instructions modifiant ou supprimant des données s’exécutaient malgré le mode lecture seule. Un second outil, destiné à vérifier des fichiers de sauvegarde, transmettait lui aussi du T-SQL arbitraire.

Deux éléments aggravaient la situation. D’abord, des résultats de requêtes pouvaient être envoyés vers un partage de fichiers distant via une procédure stockée étendue, ce qui offrait un canal d’exfiltration. Ensuite, Copilot lit des fichiers d’instructions stockés dans la base (une « constitution » valable pour toute la base et des instructions par objet, conservées sous forme de propriétés étendues). Un utilisateur disposant de droits modestes sur un objet pouvait y attacher de telles instructions, et Copilot les suivait ensuite avec les privilèges de la personne qui l’utilisait.

En les enchaînant, un propriétaire de base pouvait déposer des instructions, attendre qu’un sysadmin ouvre Copilot sur cette base, et faire ajouter son compte au rôle sysadmin par l’agent. L’attaque exige une interaction de l’utilisateur, mais aucun code d’exploitation : la « charge utile » est un texte que l’agent traite comme une consigne. Aucune chaîne exploitable n’est reproduite ici.

Exemple de prompt

Illustratif et expurgé : il montre la forme de la faille, pas une charge utilisable.

# SQL Copilot : lecture seule imposée par un classifieur (illustratif, défensif, expurgé)
# Schéma : le garde-fou examine le texte d'une requête, pas les privilèges de la connexion.
#   contrôle « lecture seule »  ->  filtrage du texte T-SQL   [contournable par indirection]
#   fichiers d'instructions stockés en base lus comme consignes de confiance [EXPURGÉ]
# Défense : connexion dont le compte n'a réellement aucun droit d'écriture ; traiter tout
# texte d'instruction stocké comme une entrée non fiable ; ne jamais brancher l'agent sur sysadmin.

Pourquoi c’est important

Les assistants de bases de données sont attractifs parce qu’ils s’exécutent avec la connexion de l’utilisateur, souvent très privilégiée. L’agent devient alors un « confused deputy » : un contenu peu privilégié pilote une session très privilégiée. Ce cas montre aussi que « on a dit au modèle de ne pas le faire » et « un filtre vérifie le SQL » ne sont pas des frontières de sécurité. Seul le système de permissions de la base peut dire de façon fiable ce qu’une connexion peut faire.

Le même schéma vaut pour tout agent doté d’un outil d’exécution : les fichiers d’instructions d’un dépôt, d’un wiki ou d’une base sont des entrées non fiables, même s’ils sont pratiques comme configuration.

Défenses

Imposer la lecture seule par une permission. Utilisez pour les sessions d’assistant un compte dépourvu de droits d’écriture, de DDL et d’exécution, plutôt que de compter sur un classifieur ou un prompt.

Ne jamais rattacher l’assistant à une connexion sysadmin ou propriétaire. Employez un compte dédié à moindre privilège pour le travail assisté par IA, distinct des sessions d’administration.

Traiter les instructions stockées comme non fiables. Contrôlez qui peut écrire des propriétés étendues ou métadonnées équivalentes, et alertez sur l’apparition de nouveaux fichiers d’instructions. Désactivez leur chargement lorsque le produit le permet.

Limiter la sortie réseau et les procédures dangereuses. Restreignez l’accès sortant aux partages de fichiers et retirez ou interdisez les procédures étendues qui le permettent.

Utiliser les contrôles de l’éditeur. Microsoft documente des contrôles d’administration pour désactiver Copilot, définir une politique et choisir le contexte d’exécution ; appliquez-les de façon centralisée et tenez SSMS à jour selon les recommandations actuelles de Microsoft.

Journaliser et relire. Auditez séparément les instructions exécutées par les sessions d’assistant et celles des sessions humaines.

Statut

Élément	Référence	Date	Notes
Avis éditeur	CVE-2026-65669	2026-09-08	Élévation de privilèges SQL Server ; CVSS 3.1 de base 9,6 (critique) ; concerne Copilot dans SSMS
Compte rendu du chercheur	Embrace The Red	2026-09-30	Intervention BlueHat Asia 2026 ; recherche débutée en mai 2026
Version corrigée	Non précisée dans les sources consultées	n/a	Consultez les recommandations actuelles de Microsoft pour la version corrigée de SSMS