Semantic Kernel bugs turned prompt injection into remote code execution
Microsoft disclosed two Semantic Kernel vulnerabilities showing how prompt injection can stop being a content problem and become host compromise. In one case, an AI-controlled search parameter flowed into Python eval logic. In the other, an agent-exposed file-transfer helper could be driven to write outside its intended sandbox. The fixes were available, but the research is the useful part: once an AI agent can call tools, every model-controlled parameter is attacker-controlled input wearing a nicer jacket.
Incident Details
Tech Stack
References
The Prompt Became a Shell
Prompt injection is often described as a chatbot problem: the model reveals a secret, ignores instructions, or says something embarrassing. Microsoft's Semantic Kernel research shows the more dangerous version. When an AI agent is wired to tools, prompt injection can become a path to code execution on the machine running the agent.
Microsoft's May 7, 2026 security writeup focused on two Semantic Kernel vulnerabilities, CVE-2026-26030 and CVE-2026-25592. Both had fixes available by the time the public research was published. The interesting part is not that software had bugs. Software always has bugs; it is practically a subscription service. The interesting part is that the vulnerable data path ran through AI tool calling, where natural-language input could be transformed into parameters for code that touched files, filters, sandboxes, and the host environment.
That is squarely an AI-agent failure mode. The model did not need to "want" anything. It only needed to parse an attacker-controlled instruction, choose a tool, and pass along parameters the surrounding framework trusted too much.
CVE-2026-26030: Search Parameter to Python Eval
The first vulnerability involved Semantic Kernel's Python package, an In-Memory Vector Store, and default search-filter functionality. Microsoft demonstrated a hotel-search style agent where the AI model could call a search tool with a city parameter. Under the hood, that parameter was interpolated into a Python lambda expression used to filter records.
The bad sentence in that architecture is "interpolated into a Python lambda expression." If model-controlled text can land in code-shaped text that later gets evaluated, you have created a machine for turning prompts into syntax problems. Microsoft showed that a crafted prompt could manipulate the tool invocation so the resulting filter escaped the intended comparison and executed arbitrary code.
The original design included validation, but it relied on checks that could be bypassed through Python's flexible object model and alternate access paths. The fix moved toward allowlists and tighter restrictions on what code shapes could run. That is the correct direction because denylisting dangerous names in dynamic code is a game where the language has more imagination than you do.
GitHub's advisory scored CVE-2026-26030 as critical. Affected agents were those using vulnerable versions of the Python package with the In-Memory Vector Store and default filter functionality exposed through the search plugin. Microsoft advised upgrading to semantic-kernel 1.39.4 or later.
CVE-2026-25592: The Sandbox Door Was a Tool
The second vulnerability was in the .NET SDK's SessionsPythonPlugin. That plugin exists to let agents execute Python code in Azure Container Apps dynamic sessions, which are supposed to isolate code inside a hosted sandbox. The escape came from a file-transfer helper. A method for downloading files from the sandbox to the host was exposed as a kernel function, which meant the AI model could invoke it as a tool.
Once that happened, the local file path became AI-controlled. Microsoft described an attack chain where an injected prompt first created a payload inside the sandbox, then caused the agent to call the download helper and write that file to a dangerous host location, such as the Windows Startup folder. The container boundary still existed. The problem was that a trusted bridge across the boundary had been handed to the model.
This is the agentic version of leaving the loading dock open because the front door has a badge reader. The sandbox may be solid, but if the agent has a tool that copies files to arbitrary host paths, the attacker does not need to break the sandbox. They just ask the model to use the courier.
Microsoft said the fix removed AI access to that function and added path validation for programmatic use. That is the right lesson: not every helper method belongs in the model's tool menu. A function that is safe when called by trusted developer code can be unsafe when callable through natural-language instructions.
Why This Fits Here
The content scope for this site excludes ordinary human-written bugs that merely live in AI-adjacent software. A plain SQL injection in an AI framework's admin panel is still a plain SQL injection. This Semantic Kernel case is different because the exploit path depends on AI-specific behavior: prompt injection, model-mediated tool invocation, and framework trust in parameters selected by the agent.
The vulnerability is not "Microsoft has an AI library and some code was buggy." The vulnerability is "an attacker can manipulate the language model into driving framework tools in ways the system treats as trusted." That is exactly the new attack surface agent frameworks create. The model becomes a parser, router, and parameter generator for code with real privileges.
The Graveyard Lesson
AI agents collapse two worlds that security teams used to keep separate. On one side is language, which is messy, adversarial, and full of user input. On the other side are tools that read files, run code, query databases, move data, and write to disk. Tool calling is the bridge. Every bridge needs load limits.
The practical rule is simple: any value the model can influence is untrusted input. It does not matter if the model appears to choose a structured function call. It does not matter if the prompt looks benign. It does not matter if the tool was only intended for helpful workflows. If an attacker can steer the model, the attacker can steer the parameters.
Framework authors need defensive defaults: strict schema validation, allowlisted operations, path canonicalization, constrained sandboxes, minimal tool exposure, and no dynamic code execution fed by model-controlled strings. Application developers need to inventory which tools their agents can call, what those tools can reach, and whether a prompt injection could turn a cute demo into an endpoint incident.
The uncomfortable part is that this is not a weird edge case. It is the natural consequence of giving text generators operational hands. Once the assistant can touch the system, a bad prompt is no longer just bad content. It can be the first line of an exploit chain.
Discussion