Microsoft Semantic Kernel Flaws Turn AI Prompt Injection Into Full Remote Code Execution Threat

CyberDefender 15 mins0

Artificial intelligence agents are rapidly becoming operational components inside enterprise environments. Unlike traditional AI chatbots that only generate responses, modern AI agents interact directly with infrastructure through plugins, APIs, databases, shell execution environments, vector stores, and cloud services. This shift fundamentally changes the security landscape. A compromised AI prompt is no longer just a content moderation issue; it can become an execution pathway into production systems. This technical analysis explores two major vulnerabilities discovered in Microsoft Semantic Kernel: CVE-2026-26030 and CVE-2026-25592. These flaws demonstrate how AI agent frameworks can unintentionally expose remote code execution primitives through unsafe plugin design, insecure parameter handling, and excessive trust in model-generated instructions.

Understanding the Security Shift in AI Agent Architectures

Traditional application security models were built around explicit user input validation and predefined execution paths. AI agents disrupt this model because natural language itself becomes a dynamic execution interface. Instead of users directly invoking functions, AI models translate language into structured tool calls, often with little developer visibility into the resulting execution flow.

This creates a dangerous architectural pattern where untrusted language is transformed into executable operations. The AI model is not malfunctioning when this occurs; it is performing exactly as designed. The problem emerges when frameworks blindly trust the structured outputs generated by the model. Once an agent has access to filesystem APIs, vector databases, cloud sandboxes, or operating system commands, prompt injection evolves into a practical exploitation technique capable of host compromise.

The vulnerabilities discovered in Semantic Kernel reveal a broader industry problem: many AI frameworks still lack mature security boundaries between model intent and system execution. As AI adoption accelerates, these weaknesses may become increasingly attractive attack vectors for adversaries targeting enterprise AI infrastructure.

Semantic Kernel: The Foundation of Many Enterprise AI Agents

Microsoft Semantic Kernel is one of the most widely adopted open-source frameworks for building AI agents and integrating large language models into enterprise applications. The framework provides abstractions for plugins, memory systems, vector stores, workflow orchestration, and autonomous function calling. Its popularity makes any security flaw particularly significant. Vulnerabilities inside the framework do not affect a single application; they can potentially impact thousands of downstream deployments relying on default configurations and plugin behaviors. During security research into the framework, researchers identified two critical flaws capable of transforming prompt injection into full remote code execution.

The first vulnerability targeted the In-Memory Vector Store functionality. The second abused unsafe file handling inside the SessionsPythonPlugin. Together, they illustrate how modern AI agents can inadvertently expose host-level execution primitives through poorly constrained tooling.

CVE-2026-26030: Remote Code Execution Through In-Memory Vector Store Filters

The first vulnerability affected Semantic Kernel’s Python implementation and specifically targeted applications using the In-Memory Vector Store backend alongside the Search Plugin functionality. Under vulnerable configurations, attackers could inject malicious payloads into vector search filters and achieve arbitrary code execution on the host system.

Illustration of CVE-2026-26030 exploitation using a local model.

The exploitation conditions were relatively straightforward:

  • The attacker needed a prompt injection vector capable of influencing agent input.
  • The target application needed to use Semantic Kernel versions earlier than 1.39.4.
  • The application needed to rely on the default In-Memory Vector Store filter implementation.

Researchers demonstrated the issue using a hotel-finder AI agent. The agent exposed a search_hotels(city=...) plugin that allowed users to query hotel data by city. Under normal operation, a prompt such as “Find hotels in Paris” triggered the AI model to call the plugin with the argument city="Paris".

Internally, Semantic Kernel dynamically generated a Python lambda expression to filter records:

lambda x: x.city == 'Paris'
Default filtering function definition

The vulnerability emerged because the city parameter was directly controlled by the AI model and inserted into the lambda string without sanitization. Since the filter logic was ultimately executed using Python’s eval() function, attackers could inject arbitrary Python expressions into the generated lambda.

Unsafe String Interpolation and the Eval() Execution Sink

The core issue was classic code injection disguised as AI functionality. By closing the original string and appending malicious Python logic, attackers could reshape the generated lambda expression into executable payloads.

For example:

Input: ' or MALICIOUS_CODE or '

Resulted in:

lambda x: x.city == '' or MALICIOUS_CODE or ''

Because the payload remained syntactically valid Python, the eval() call executed attacker-controlled logic directly on the host machine.

This demonstrates a critical lesson in AI security engineering: language model outputs must always be treated as untrusted input, even when converted into structured data. The model may produce syntactically correct outputs that still contain malicious intent.

Why the AST-Based Security Validation Failed

Semantic Kernel attempted to mitigate code execution risks through Abstract Syntax Tree (AST) validation before evaluating the lambda expressions. The framework enforced several restrictions:

  • Only lambda expressions were allowed.
  • Dangerous identifiers such as eval, exec, and open were blocked.
  • Built-in Python functions were removed during execution.
  • Unsafe code blocks were rejected.

Although these protections appeared robust on paper, Python’s dynamic object model enabled researchers to bypass them entirely. Attackers exploited Python’s internal class hierarchy traversal capabilities to locate dangerous functionality indirectly. Instead of directly importing modules, the payload navigated through existing runtime objects to locate BuiltinImporter, dynamically load the os module, and invoke system() calls.

The exploit succeeded because several dangerous attributes were missing from the framework’s blocklist, including:

  • __name__
  • load_module
  • system
  • BuiltinImporter

Additionally, the validator failed to inspect ast.Subscript nodes, allowing blocked attributes to be accessed indirectly through bracket notation. The AST validation therefore became an incomplete blacklist approach rather than a true security boundary.

Microsoft’s Multi-Layered Security Fix

Following responsible disclosure, Microsoft implemented a significantly stronger mitigation strategy. The patch introduced multiple layers of validation designed to eliminate every known escape primitive involved in the attack chain.

The security improvements included:

  • An AST node allowlist permitting only safe expression types.
  • Strict validation of callable functions.
  • Explicit blocking of dangerous attributes like __class__ and __subclasses__.
  • Restrictions allowing only approved lambda parameters as bare identifiers.

Applications running Semantic Kernel Python versions earlier than 1.39.4 remained vulnerable and required immediate upgrading.

CVE-2026-25592: Arbitrary File Write Through SessionsPythonPlugin

The second vulnerability targeted Semantic Kernel’s .NET SDK and exposed a different but equally severe attack path. Researchers discovered that the DownloadFileAsync method inside SessionsPythonPlugin had accidentally been exposed to the AI model as a callable tool through the [KernelFunction] attribute.

This plugin was originally intended to help transfer files between Azure Container Apps dynamic sessions and the host environment. The security assumption was that sandbox isolation would prevent malicious code from escaping the container. However, exposing DownloadFileAsync to the AI model unintentionally handed attackers direct influence over host filesystem writes.

The dangerous parameter was localFilePath, which controlled exactly where files would be written on the host machine using File.WriteAllBytes(). Because no validation or directory restrictions existed, attackers could instruct the AI model to write arbitrary files anywhere on the filesystem.

Chaining Prompt Injection Into Sandbox Escape

Researchers demonstrated a practical sandbox escape attack chain involving two plugin operations. First, the attacker instructed the AI agent to generate a malicious payload inside the isolated Python execution container using the ExecuteCode tool. At this stage, the payload remained confined inside the sandbox environment.

Next, the attacker used prompt injection to convince the AI model to invoke DownloadFileAsync, downloading the malicious payload from the sandbox directly into the host machine’s Windows Startup folder. Once written into the Startup directory, the malicious script executed automatically during the next user login, resulting in complete host compromise. This attack bypassed container isolation entirely without requiring kernel exploits, memory corruption, or privilege escalation vulnerabilities. The AI agent itself became the escape mechanism.

Defensive Recommendations for AI Agent Security

  1. Applications using Semantic Kernel Python versions earlier than 1.39.4 or .NET SDK versions earlier than 1.71.0 should be upgraded immediately.
  2. Only expose plugins and functions that are absolutely necessary for business operations. Every callable tool expands the potential attack surface available through prompt injection.
  3. AI-generated parameters should undergo the same validation standards applied to traditional user input. Dynamic evaluation functions such as eval() should never process model-controlled content.
  4. Security teams should monitor AI agent hosts for suspicious process creation, unexpected outbound network connections, filesystem modifications, and persistence mechanisms. Prompt injection attacks frequently manifest as endpoint anomalies rather than traditional web attacks.
  5. Treat AI agents as semi-trusted automation components rather than inherently safe orchestration systems. Runtime isolation, least privilege, filesystem restrictions, and network segmentation remain essential defenses.

Final Thoughts

The vulnerabilities discovered in Microsoft Semantic Kernel are not isolated implementation mistakes. They expose a broader architectural challenge facing the AI industry: natural language is becoming an execution interface. As AI agents gain the ability to interact with filesystems, cloud platforms, APIs, and operating systems, prompt injection attacks can rapidly evolve into real-world compromise scenarios.

Modern AI systems must therefore be designed with the assumption that every model-generated action could be influenced by adversarial input. Security can no longer rely solely on model alignment or content filtering. Instead, robust architectural controls, strict tool governance, runtime monitoring, and secure-by-default framework design must become standard practice across the AI ecosystem.

CyberDefender