--- schema: 1 kind: vulnerability title: "Microsoft Semantic Kernel CVE-2026-26030 / CVE-2026-25592: Prompt-Injection-to-RCE in an AI Agent Orchestration Framework" headline: "Microsoft Semantic Kernel CVE-2026-26030 / CVE-2026-25592: Prompt-Injection-to-RCE in an AI Agent Orchestration Framework" summary: "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 …" discovered_at: "2026-05-10T05:00:12Z" event_date: 2026-05-07 run_id: 2026-05-10-001 priority: notable immediate_action: null tags: - vulnerabilities - rce - poc-public - patch-available - ai-abuse - cloud regions: - global sectors: [] entities: [] cves: - id: CVE-2026-26030 cvss: "9.9" epss: null type: rce vector: user-interaction auth: pre-auth status: - poc-public - patch-available - id: CVE-2026-25592 cvss: "9.9" epss: null type: rce vector: user-interaction auth: pre-auth status: - poc-public - patch-available sources: - url: "https://www.microsoft.com/en-us/security/blog/2026/05/07/prompts-become-shells-rce-vulnerabilities-ai-agent-frameworks/" publisher: "Microsoft Security Blog, 2026-05-07" role: primary - url: "https://github.com/microsoft/semantic-kernel/security/advisories/GHSA-xjw9-4gw8-4rqx" publisher: "GitHub Security Advisory GHSA-xjw9-4gw8-4rqx, 2026-05-07" role: corroborating - url: "https://github.com/microsoft/semantic-kernel/security/advisories/GHSA-2ww3-72rp-wpp4" publisher: "GitHub Security Advisory GHSA-2ww3-72rp-wpp4, 2026-05-07" role: corroborating closed_sources: [] evidence: [] verification: multi-source sourcing_note: null confidence: high update_of: null references: [] deep_dive: true deep_dive_category: other org_triage: null watchlist_hit: false actions: [] migrated_from: briefs/2026-05-10.md --- **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](https://www.microsoft.com/en-us/security/blog/2026/05/07/prompts-become-shells-rce-vulnerabilities-ai-agent-frameworks/) · [GitHub GHSA-xjw9-4gw8-4rqx](https://github.com/microsoft/semantic-kernel/security/advisories/GHSA-xjw9-4gw8-4rqx) · [GitHub GHSA-2ww3-72rp-wpp4](https://github.com/microsoft/semantic-kernel/security/advisories/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: ```python "".__class__.__bases__[0].__subclasses__()[]("...") ``` — 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](https://attack.mitre.org/techniques/T1059/006/) (the resulting RCE primitive); [T1190 Exploit Public-Facing Application](https://attack.mitre.org/techniques/T1190/) 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](https://attack.mitre.org/techniques/T1611/) (sandbox escape from Container Apps Python session into the host); [T1565.001 Stored Data Manipulation](https://attack.mitre.org/techniques/T1565/001/) (write primitive); [T1005 Data from Local System](https://attack.mitre.org/techniques/T1005/) (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.exe` invocations from `python` virtualenv 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` / `dotnet` agent 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.