The Microsoft Defender Security Research Team published a research post on May 7, 2026 documenting two vulnerabilities they found in Microsoft's own Semantic Kernel framework. Both have since been patched. The post deserves careful reading because neither vulnerability is a bug in an AI model. Both are bugs in how the framework trusted AI-generated output as safe input to system tools. That distinction matters enormously for anyone building or deploying AI agents right now.
The core lesson: your LLM is not a security boundary
Semantic Kernel, LangChain, CrewAI, and similar agent orchestration frameworks wire AI models to plugins. Those plugins read files, run code, query databases, and talk to APIs. When the AI model decides what parameters to pass to those plugins, and when those parameters come from attacker-influenced content, you have an injection vulnerability. The model is not the attacker's target. The tools are.
This is structurally identical to how SQL injection works. The database layer trusts the application layer to sanitize inputs before interpolating them into queries. The AI framework layer trusts the model's outputs to be safe inputs to system calls. In both cases, that trust is exploitable.
CVE-2026-26030: one bad eval, one blocklist bypass, one shell
The first vulnerability requires two conditions: a prompt injection vector that lets an attacker influence the agent's inputs, and an agent using the Search Plugin backed by the In-Memory Vector Store with default configuration.
The Search Plugin uses a default filter function implemented as a Python lambda expression passed to eval(). The kwargs passed to the lambda are AI model-controlled and unsanitized. The framework developers anticipated this risk and built a validator that parses the filter string into an Abstract Syntax Tree before execution, blocking dangerous identifiers like eval, exec, open, and __import__.
The bypass works because Python's type system provides access to dangerous capabilities through paths the blocklist did not enumerate. The research team's exploit prompt caused the agent to invoke the search function with an argument that, after lambda string interpolation, traversed Python's class hierarchy via tuple().__class__.__mro__[1].__subclasses__() to locate BuiltinImporter, then called load_module to import os and call system(). The exploit opened calc.exe as the proof of concept. In production it would be anything the agent process can execute.
The blocklist missed __name__, load_module, system, and BuiltinImporter. The structural check passed because the entire payload was wrapped in a valid lambda. The __builtins__: {} sandbox was irrelevant because the payload never used built-in functions directly.
The fix, shipped in semantic-kernel Python 1.39.4, switches from a blocklist to an allowlist on the AST. Only safe constructs are permitted: comparisons, boolean logic, arithmetic, and literals. Function calls and name references are each independently validated against explicit allowlists rather than blocked by pattern matching.
CVE-2026-25592: sandbox escape via a misconfigured plugin attribute
The second vulnerability is simpler and arguably worse. The SessionsPythonPlugin lets agents execute Python code inside Azure Container Apps dynamic sessions, isolated cloud sandboxes. The security model relies entirely on this boundary: code runs in the container and cannot touch the host.
The plugin includes UploadFile and DownloadFile helper functions to move data between the sandbox and the host. DownloadFileAsync in the .NET SDK was accidentally marked with a [KernelFunction] attribute, which advertised it to the AI model as a callable tool. The localFilePath parameter, which determines where File.WriteAllBytes() saves data on the host, was therefore entirely AI-controlled, with no path validation.
The attack chain: a prompt injection in the first step causes the agent to use ExecuteCode to generate a malicious script inside the sandbox. A second injected instruction causes the agent to call DownloadFileAsync with localFilePath set to the Windows Startup folder on the host. On the next user sign-in, the script runs.
No hypervisor exploit. No memory corruption. Just prompt injection and a misplaced attribute.
The fix, in Semantic Kernel .NET 1.71.0, removes the [KernelFunction] attribute from DownloadFileAsync so the model can never invoke it, and adds path canonicalization and directory allowlist matching for any programmatic callers.
Are you affected
For CVE-2026-26030: your agent is vulnerable if it uses the semantic-kernel Python package below version 1.39.4, uses the In-Memory Vector Store, and exposes the Search Plugin with default configuration.
For CVE-2026-25592: your agent is vulnerable if it uses the Semantic Kernel .NET SDK below version 1.71.0 and uses the SessionsPythonPlugin.
If you deployed either during their vulnerable window, investigate. Define the vulnerable window, then hunt for host-level signals: suspicious child processes spawned by the agent host, outbound connections from the agent process, unexpected files in Startup folders or other persistence paths. Rotate any credentials or tokens the agent host could access.
What to do
Upgrade semantic-kernel Python to 1.39.4 or higher. Upgrade the Semantic Kernel .NET SDK to 1.71.0 or higher. These are the only remediation steps. There is no architectural change required for either fix.
More broadly: treat every parameter an AI model can influence as attacker-controlled input. Allowlists on AST node types, function calls, and file paths are the correct pattern for sandboxing model outputs. Blocklists in dynamic languages will be bypassed.
Microsoft published advanced hunting queries in the research post for detecting common RCE post-exploitation child processes from Semantic Kernel agent hosts, using DeviceProcessEvents. Run them against the vulnerable window for any affected deployments.
Gigia Tsiklauri is a Security Architect and founder of Infosec.ge. Get in touch if you want help reviewing your AI agent architecture for injection risks before your next deployment.