2026-05-10 · view entry permalink →
Microsoft Semantic Kernel CVE-2026-26030 / CVE-2026-25592: Prompt-Injection-to-RCE in an AI Agent Orchestration Framework
Primary CVEs: CVE-2026-26030 (Python SDK, CVSS 9.9; patched in 1.39.4) and CVE-2026-25592 (.NET SDK, CVSS 9.9; patched in 1.71.0; also assigned a Python patch in 1.39.3 per the GitHub advisory, superseded by 1.39.4) | Status: Patch available; public PoC for CVE-2026-26030; no in-the-wild exploitation reported | Primary advisory: Microsoft Security Blog, 2026-05-07 · GitHub GHSA-xjw9-4gw8-4rqx · GitHub GHSA-2ww3-72rp-wpp4
Why this matters for a Swiss/EU public-sector SOC
Semantic Kernel is the open-source orchestration SDK behind Azure AI Foundry, Copilot Studio, and a growing fraction of self-hosted enterprise AI agents in EU government modernisation pilots. Where prompt injection has previously been treated as a content problem (LLM produces wrong text), CVE-2026-26030 and CVE-2026-25592 promote it to a host problem: an attacker who can inject text the agent reads — via user input, RAG-retrieved documents, tool outputs, or email indexed by an automation — escapes the agent's logical boundary and runs code on the agent process's host. The deployment surface inside an EU public-sector tenant is exactly the place where an LLM-driven workflow has access to sensitive data sources (case-management systems, HR repositories, classified-by-policy documents). The two CVEs together demonstrate that agentic-AI tool authorisation is a security boundary, not a convenience abstraction.
CVE-2026-26030 — Python SDK: code injection via InMemoryVectorStore filter
Affected: Microsoft Semantic Kernel Python SDK < 1.39.4. Class: CWE-94 Improper Control of Generation of Code ('Code Injection'). CVSS: 9.9.
The Python SDK's InMemoryVectorStore filter function composes its LINQ-like filter expression by f-string interpolation of an LLM-controlled parameter rather than parameterising the value into the filter AST. The SDK applies a string-blocklist validator to reject obvious dangerous tokens (e.g. eval, exec, os.system), but the validator is a denylist on the literal text, not a sandboxed evaluation. The attacker bypasses it via the standard Python class-hierarchy traversal pattern:
"".__class__.__bases__[0].__subclasses__()[<index>]("...")— walking object's subclass list to reach an arbitrary class that exposes a method capable of running shell commands (typically subprocess.Popen or a os reference reached via reflection). Once the validator is fooled, the f-string interpolation completes and Python evaluates the resulting expression in the agent process's context.
Exploitation prerequisites. The agent must (a) use the in-memory vector store backing for a Search Plugin or analogous component (default for self-hosted Semantic Kernel agents until a customer wires in a different vector backend), and (b) the attacker must have an injection vector into the prompt context. In practice, indirect prompt injection via retrieved documents or tool output is sufficient; a direct user-input vector is not required.
MITRE ATT&CK mapping: T1059.006 Command and Scripting Interpreter: Python (the resulting RCE primitive); T1190 Exploit Public-Facing Application where the agent ingests externally-sourced content.
Public PoC. Microsoft's research post references the public proof-of-concept in the amiteliahu/AIAgentCTF GitHub repository.
CVE-2026-25592 — .NET SDK: arbitrary file write via misapplied [KernelFunction] attribute on Sessions Python plugin
Affected: Microsoft Semantic Kernel .NET SDK < 1.71.0. Class: CWE-22 Path Traversal (effectively, an unintended sandbox-escape path). CVSS: 9.9.
The SessionsPythonPlugin integrates Azure Container Apps Python sessions as an agent-callable code-execution sandbox. Two of its methods — DownloadFileAsync and UploadFileAsync — were mistakenly annotated with [KernelFunction]. The decoration tells the kernel that the method is callable by the LLM as a tool. Combined, the LLM can therefore (a) call UploadFileAsync to write attacker-chosen bytes to an attacker-chosen path on the host running the agent process, escaping the Container Apps Python session entirely; and (b) call DownloadFileAsync symmetrically to read host-side files back into the agent context. The intended design exposed only sandboxed file operations against the Container Apps session filesystem; the attribute application broke containment.
The attack surface is any Semantic Kernel .NET agent that loads SessionsPythonPlugin. As with the Python flaw, the LLM can be steered into invoking these methods through indirect prompt injection — no explicit tool-call permission grant from the user is required at runtime if the agent has been configured to allow plugin invocation autonomously.
MITRE ATT&CK mapping: T1611 Escape to Host (sandbox escape from Container Apps Python session into the host); T1565.001 Stored Data Manipulation (write primitive); T1005 Data from Local System (read primitive).
Why this is a class, not just two CVEs
Both flaws stem from a shared design weakness: an agent framework that treats LLM-controlled values as input to executable abstractions without explicit validation at the boundary. The Python flaw uses string interpolation (the LLM's value is interpolated into code); the .NET flaw uses attribute application (LLM-callable surface is over-broad because of mis-tagged methods). Both bypass any of the existing prompt-side mitigations (output filtering, response classifiers, "let the LLM judge" patterns) because the dangerous operation occurs inside the SDK, not in the model's text.
Microsoft's research framing — "prompts become shells" — is the correct mental model for defenders: any place an agent framework converts an LLM-supplied value into a code-execution-adjacent operation (filter expression, tool dispatch, plugin parameter, file path, SQL, shell command) requires the same defensive treatment as a user-supplied parameter on a public-facing web endpoint. The same class of bug is highly likely to exist in LangChain, CrewAI, AutoGen, Haystack, LlamaIndex, and other agent frameworks; defenders should not assume Microsoft Semantic Kernel is uniquely affected.
Detection concepts
- Process ancestry anomalies for AI agent frameworks. Sysmon EID 1 with parent-image filters covering
python.exe/dotnet.exeinvocations frompythonvirtualenv paths or .NET app-host paths under typical Semantic Kernel deployment directories — alert when those processes spawn shells (bash,cmd.exe,powershell.exe), file utilities (mv,cp,tar), or network tools (curl,wget,ssh,nc). - EDR detections for unexpected shell-spawning by
python/dotnetagent processes. EDR vendors classify this under hunt-pack categories such as "interpreter spawning shell" and "agent framework lateral move". - File-creation events outside the expected sandbox path. For .NET agents using
SessionsPythonPlugin, alert on file creation by the agent process anywhere outside the Container Apps Python sessions mount; for Python agents, alert on file creation outside the configured agent working directory. - Agent-side telemetry: log and audit every tool / plugin invocation with parameters. Many self-hosted agent deployments do not log plugin-method calls because the LLM provider's API logs the prompt and response but not the agent-side dispatcher's tool-call traffic. Add structured logging at the dispatcher layer.
Hardening / mitigation
- Patch first. Upgrade Python SDK to ≥ 1.39.4 and .NET SDK to ≥ 1.71.0. The patched releases also include the upstream test additions covering the bypass patterns.
- If immediate upgrade is blocked, implement a Function Invocation Filter (the SDK-supported hook documented in the Microsoft research post) to allowlist the methods and parameters that may be called. This neutralises the unintended-
[KernelFunction]exposure on the .NET side and reduces the Python-side blast radius even if the validator is bypassed. - Audit every
[KernelFunction]-decorated method in your codebase for parameter types that are paths, file handles, raw strings later interpolated into code, SQL fragments, or URLs; remove the decorator from anything that does not need to be LLM-callable. - Treat LLM-supplied inputs to filter / templating / dispatch as untrusted at the SDK boundary — the same bar as request-body validation on a REST endpoint. Allowlist parameter types, validate paths against canonicalised roots, parameterise filter expressions instead of interpolating them.
- Network segmentation around agent hosts. A Semantic Kernel agent host with read access to internal systems and outbound internet access is an obvious post-RCE pivot point; the agent process should run with the same network and credential constraints as any internet-exposed application server.