Semantic Kernel : quand un prompt devient un shell (CVE-2026-25592, CVE-2026-26030)

De quoi parle-t-on ?

Le 7 mai 2026, le Microsoft Security Response Center a publié les advisories de deux vulnérabilités critiques dans Semantic Kernel, le framework d’agents phare de l’éditeur. CVE-2026-25592 (CVSS 10.0) affecte le SDK .NET avant la version 1.71.0 ; CVE-2026-26030 (CVSS 9.8) affecte le SDK Python avant la 1.39.4. Toutes deux transforment un unique prompt injecté en exécution de code au niveau de l’hôte.

L’article de recherche associé, “When prompts become shells”, montre comment lancer calc.exe sur la machine qui héberge l’agent — sans exploit navigateur, sans pièce jointe malveillante, sans bug de corruption mémoire. Une simple chaîne de caractères en langage naturel suffit.

Comment ça fonctionne

CVE-2026-26030 (Python, InMemoryVectorStore). Lorsqu’une application Semantic Kernel utilise le vector store en mémoire par défaut avec le Search Plugin, l’expression de filtre fournie par l’utilisateur est compilée en lambda Python puis passée à eval(). Toute chaîne que le modèle peut placer dans ce filtre — directement, ou via le contenu d’un document récupéré — devient donc du code Python exécuté sur l’hôte :

# Schéma vulnérable simplifié (NE PAS exécuter)
filter_expr = user_or_model_supplied_string
fn = eval(f"lambda item: {filter_expr}")  # [REDACTED-eval]
results = [it for it in store if fn(it)]

CVE-2026-25592 (.NET, SessionsPythonPlugin). Le plugin qui exécute le code généré par le modèle dans les sessions dynamiques Azure Container Apps exposait également une méthode interne, DownloadFileAsync, décorée avec [KernelFunction]. Cet attribut rend une méthode .NET visible au LLM comme un outil appelable. Sans validation de chemin, le modèle pouvait créer un payload à l’intérieur du sandbox, puis demander au framework lui-même d’écrire ce payload à un emplacement arbitraire de l’hôte qui exécute l’agent — contournant entièrement la frontière du sandbox.

Les deux bugs partagent une même erreur d’architecture : avoir traité le registre d’outils ([KernelFunction]) et le langage de filtres (eval) comme des commodités ergonomiques plutôt que comme des surfaces critiques pour la sécurité.

Pourquoi c’est important

La prompt injection a longtemps été décrite comme un problème de « sécurité de contenu ». Ces CVE renversent ce cadrage. Dès lors qu’un LLM est branché sur des outils et reçoit du texte non fiable — document récupéré, page web, message utilisateur — chaque fonction exposée devient une partie de la surface d’attaque, et chaque interpréteur de chaîne devient un chemin d’exécution.

Le motif n’est pas spécifique à Semantic Kernel. Les travaux de Microsoft et les advisories tierces concurrentes documentent en 2026 la même classe de bugs dans d’autres frameworks d’agents (CrewAI, LangFlow, LiteLLM, GPT Researcher), souvent via l’injection de commandes MCP STDIO ou des appels à eval/exec dans les systèmes de plugins. Toute équipe qui construit des agents avec outils, RAG ou exécution de code doit considérer cette classe comme la concernant tant que l’inverse n’est pas démontré.

Défenses

• Appliquer le correctif immédiatement. Mettez à niveau vers semantic-kernel >= 1.39.4 (Python) et >= 1.71.0 (.NET). Épinglez la version dans le lockfile et vérifiez en CI.
• Auditer le registre d’outils. Listez chaque méthode exposée au modèle ([KernelFunction], @kernel_function, décorateurs équivalents dans les autres frameworks). Retirez tout ce qui franchit une frontière de confiance — I/O fichier sur l’hôte, sortie réseau, accès aux secrets — sauf si cette exposition est délibérée et revue.
• Bannir eval/exec sur tout input influencé par le modèle. Remplacez les filtres à base de lambdas par une AST analysée ou par un langage de domaine avec une allowlist explicite d’opérateurs. Une expression de filtre est de l’entrée utilisateur, pas du code.
• Sandboxer l’hôte de l’outil, pas seulement l’interpréteur. Azure Container Apps sandboxait la session Python ; il ne sandboxait pas l’hôte .NET propriétaire du helper de fichier. La frontière de confiance doit englober l’appelant de l’outil, et pas seulement le payload.
• Appliquer la grille de la « lethal trifecta ». Comme le formule Simon Willison, un agent qui combine (1) un accès à des données privées, (2) une exposition à du contenu non fiable, et (3) la capacité d’agir vers l’extérieur est exploitable par défaut. Retirez au moins une de ces trois jambes par environnement quand c’est possible.
• Journaliser les appels d’outils avec leurs arguments. Détectez les paramètres anormaux (chemins hors des répertoires attendus, code suspect dans les filtres) avant exécution.

Statut

Composant	Versions vulnérables	Patché en	CVSS
semantic-kernel (Python, InMemoryVectorStore)	< 1.39.4	1.39.4	9.8
semantic-kernel (.NET, SessionsPythonPlugin)	< 1.71.0	1.71.0	10.0

Dates clés : divulgation et correctifs publiés par Microsoft le 7 mai 2026. Les entrées CVE ont été créées la même semaine ; l’advisory GitHub GHSA-xjw9-4gw8-4rqx et la fiche NVD de CVE-2026-26030 servent de références primaires.