Most of us now know, at least vaguely, that you can trick a chatbot into saying things it should not. The more uncomfortable question is what happens when the chatbot can do things. In May, Microsoft’s own security researchers gave a precise answer for one popular toolkit. Using an AI agent built on Microsoft’s Semantic Kernel, they wrote: “A single prompt was enough to launch calc.exe on the device running our AI agent” (Microsoft Defender Security Research Team, 2026).
Calculator is the security world’s harmless calling card. If an attacker can make a computer open it, they could usually have made it run something far worse. The researchers did not need a malicious attachment, a browser exploit or a memory bug. The agent simply did what it was built to do: read language, pick a tool and pass along the details.
This post is about a specific, documented case: two vulnerabilities, now fixed, recorded as CVE-2026-26030 and CVE-2026-25592. If you want the general idea of prompt injection first, our plain-language explainer covers it. Here we look at what it took for injected words to become running code, and what that teaches anyone who builds or buys AI agents.
What Semantic Kernel is, and why it matters
Semantic Kernel is Microsoft’s open-source framework for building AI agents: software that connects a language model to “plugins” or tools so it can search data, read files or run code. It is widely used, with over 27,000 stars on GitHub according to Microsoft (Microsoft Defender Security Research Team, 2026). Frameworks like this sit underneath many products, which is why the researchers warn that a single flaw in how a framework connects model output to system tools “carries systemic risk.”
Both flaws were rated critical, 9.9 out of 10, in the advisories Microsoft published on GitHub in February 2026, and fixed versions were released that month (Microsoft, 2026a, 2026b; National Institute of Standards and Technology [NIST], 2026a, 2026b). Microsoft’s Security Response Center added the first flaw to its security update guide in March (Microsoft Security Response Center, 2026). Microsoft’s researchers published the full technical story on 7 May 2026.
The first flaw: a search box that ran code
To demonstrate CVE-2026-26030, the researchers built a simple “hotel finder” agent. Ask it to find hotels in Paris and the model calls a search tool with city="Paris". Behind the scenes, the Python version of Semantic Kernel turned that value into a small piece of code, a filter, and ran it with Python’s eval() function. The value came from the model, and it was not cleaned before being slotted into the code (Microsoft Defender Security Research Team, 2026).
The framework’s authors had seen the risk and added a blocklist that rejected dangerous words like eval and exec. The researchers showed that a carefully crafted prompt could get the model to pass a “city” that slipped past the blocklist by walking through Python’s internal class structure to reach the operating system. Their verdict on the approach is worth remembering: blocklists in flexible languages like Python are “inherently fragile.”
Two conditions had to be true. The attacker needed some way to get text in front of the agent, and the agent had to use the search plugin backed by Semantic Kernel’s In-Memory Vector Store with its default settings. The fix, in Python package version 1.39.4, replaced the blocklist with allowlists that permit only safe constructions such as comparisons and simple logic (Microsoft Defender Security Research Team, 2026; Microsoft, 2026a).
The second flaw: out of the sandbox
CVE-2026-25592 is, to me, the more instructive of the two, because the safety design looked right. Semantic Kernel’s .NET version includes a plugin that lets agents run Python code inside an isolated cloud sandbox, so that whatever the code does, it cannot touch the computer running the agent. Helper functions move files in and out of the sandbox.
One of those helpers, which downloads a file from the sandbox to the host, had been “accidentally marked” as a tool the AI model could call, complete with a parameter for where to save the file (Microsoft Defender Security Research Team, 2026). Nothing checked that location. So an injected prompt could tell the agent to write a script inside the sandbox, then tell it to download that script into the host’s Windows Startup folder. At the next sign-in, the script would run. The sandbox was intact, and it did not matter. A reverse problem existed for uploads, which could have let an injected prompt copy sensitive host files, such as SSH keys or credentials, into the sandbox.
The fix was simple: the download function was hidden from the model entirely, and path checks were added for developers who call it deliberately. It shipped in version 1.71.0 of the .NET package (Microsoft, 2026b).
Key idea: The trust boundary between untrusted text and tools
A trust boundary is the line where information you do not control meets something powerful you do. In an AI agent, everything the model reads, including emails, web pages and documents, sits on the untrusted side, and so does anything the model writes, because that text can be steered. Tools that touch files, money or systems sit on the other side. The boundary has to be enforced in ordinary code that checks every value the model passes across it, because, as Microsoft’s researchers put it, “your LLM is not a security boundary.”
Not a bug in the AI
The most useful part of Microsoft’s write-up is its framing. The model, they stress, behaved exactly as designed: it turned a request into a structured tool call. The weakness was in how the framework trusted that tool call. They compare it to the early web, when developers passed whatever users typed straight into database queries, and conclude: “Any tool parameter the model can influence must be treated as attacker-controlled input” (Microsoft Defender Security Research Team, 2026).
For non-engineers, that has a plain meaning. When an organization tells you its AI assistant is safe because the model has been trained to refuse bad instructions, ask what happens when the training fails. The protection that held in this case, once fixed, was not a smarter model. It was ordinary code that limited what the model was allowed to ask for.
For teams running AI agents: a practical check
- Patch. Python
semantic-kernelto 1.39.4 or later; .NETMicrosoft.SemanticKernel.Plugins.Coreto 1.71.0 or later, per Microsoft’s advisories. - Look back, not just forward. Microsoft advises defining the window when a vulnerable version was running, hunting for unusual child processes, outbound connections or new startup items from the agent host, and treating anything suspicious as a host compromise, including rotating credentials the agent could reach.
- List every tool the model can call. For each parameter, ask: what is the worst value an attacker could put here? Anything that becomes code, a file path or a command needs an allowlist, not a blocklist.
- Keep helper functions out of the model’s reach unless it truly needs them. The second flaw was a function that should never have been offered.
- Test it. Add a hostile-input test to your release checks: feed the agent a document containing instructions and confirm nothing crosses the boundary.
What the record does not show
Neither Microsoft nor the public vulnerability records report that these flaws were exploited by real attackers. The coordination assessment attached to both records by the US cybersecurity agency CISA, in February 2026, recorded no known exploitation at that time (NIST, 2026a, 2026b). The researchers’ demonstrations used test agents they built themselves. We also do not know how many deployed products used the vulnerable configurations, and the first flaw required a specific, non-universal setup. Microsoft says it has found structurally similar problems in other agent frameworks and will publish them later; we have not seen those findings and make no claim about them.
Questions you can ask
- If you use an AI assistant that can act for you: ask what it is allowed to do on its own, such as sending, deleting, buying or running things, and whether you can limit that.
- If you buy AI agents from a vendor: ask which agent framework they use, how quickly they apply its security fixes, and whether they checked for compromise during the vulnerable window.
- If you build agents: ask where your trust boundary is enforced in code, and who reviews it when a new tool is added.
- If you oversee security or risk: ask whether AI agent hosts are monitored like any other server, so that an agent suddenly launching a command line would be noticed.
Go further. Operational AI Readiness is FairByDesign’s field manual for AI that is already live, and the complete Standard edition is free to read and download. Chapter 7, Security Controls for LLM Apps and Agent Workflows, covers how to keep model output from reaching further than it should, and Appendix E, the minimal readiness test suite, gives you tests to run before every release, including hostile-input checks like the one above. Read it free, or test one workflow against domain 7 (LLM and agent security boundaries) in the free readiness assessment.
Your next step: read Operational AI Readiness free, starting with Chapter 7 and Appendix E.
FairByDesign is reader-funded. If this helped, get the free Mercury Brief or see ways to support. Support never buys editorial control.
References
Bakos, V. (2026). Operational AI readiness: A practitioner guide to governing AI that is already live. FairByDesign. https://fairbydesign.org/operational-ai-readiness/
Microsoft. (2026a, February 19). InMemoryVectorStore filter functionality vulnerable to remote code execution (GHSA-xjw9-4gw8-4rqx; CVE-2026-26030) [Security advisory]. GitHub. https://github.com/microsoft/semantic-kernel/security/advisories/GHSA-xjw9-4gw8-4rqx
Microsoft. (2026b, February 6). Arbitrary file write via AI agent function calling in .NET SDK (GHSA-2ww3-72rp-wpp4; CVE-2026-25592) [Security advisory]. GitHub. https://github.com/microsoft/semantic-kernel/security/advisories/GHSA-2ww3-72rp-wpp4
Microsoft Defender Security Research Team, Oren, U., Eliahu, A., & Edry, D. (2026, May 7). When prompts become shells: RCE vulnerabilities in AI agent frameworks. Microsoft Security Blog. https://www.microsoft.com/en-us/security/blog/2026/05/07/prompts-become-shells-rce-vulnerabilities-ai-agent-frameworks/
Microsoft Security Response Center. (2026). CVE-2026-26030: Microsoft Semantic Kernel InMemoryVectorStore filter functionality vulnerable [Security update guide]. https://msrc.microsoft.com/update-guide/vulnerability/CVE-2026-26030
National Institute of Standards and Technology. (2026a). CVE-2026-26030 detail. National Vulnerability Database. https://nvd.nist.gov/vuln/detail/CVE-2026-26030
National Institute of Standards and Technology. (2026b). CVE-2026-25592 detail. National Vulnerability Database. https://nvd.nist.gov/vuln/detail/CVE-2026-25592
Leave a Reply
You must be logged in to post a comment.