{“lastseen”:”2026-05-07T21:28:40″,”description”:”In this article\\n\\n 1. A representative case study: Semantic Kernel\\n 2. CVE-2026-26030: In-Memory Vector Store\\n 3. CVE-2026-25592: Arbitrary file write through SessionsPythonPlugin\\n 4. The vulnerability\\n 5. Attack chain overview\\n 6. Defending the agentic edge\\n 7. Not bugs, but developed by design\\n 8. CTF challenge: Attack your own agent\\n 9. Learn more\\n\\n\\n\\nAI agents have fundamentally changed the threat model of AI model-based applications. By equipping these models with plugins (also called tools), your agents no longer just generate text; they now read files, search connected databases, run scripts, and perform other tasks to actively operate on your network.\\n\\nBecause of this, vulnerabilities in the AI layer are no longer just a content issue and are an execution risk. If an attacker can control the parameters passed into these plugins via prompt injection, the agent may be driven to perform actions beyond its intended use.\\n\\nThe AI model itself isn\u2019t the issue as it\u2019s behaving exactly as designed by parsing language into tool schemas. The vulnerability lies in how the framework and tools trust the parsed data.\\n\\nTo build powerful applications, developers rely heavily on frameworks like Semantic Kernel, LangChain, and CrewAI. These frameworks act as the operating system for AI agents, abstracting away complex model orchestration. But this convenience comes with a hidden cost: because these frameworks act as a ubiquitous foundational layer, a single vulnerability in how they map AI model outputs to system tools carries systemic risk.\\n\\nAs part of our mission to make AI systems more secure and eliminate new class of vulnerabilities, we\u2019re launching a research series focused on identifying vulnerabilities in popular AI agent frameworks. Through responsible disclosure, we work with maintainers to ensure issues are addressed before sharing our findings with the community.\\n\\nIn this post, we share details on the vulnerabilities we discovered in Microsoft\u2019s Semantic Kernel, along with the steps we took to address them and interactive way to try it yourself. Stay tuned for upcoming blogs where we\u2019ll dive into similar vulnerabilities found in frameworks beyond the Microsoft ecosystem.\\n\\n### Background\\n\\nWe discovered a vulnerable path in Microsoft Semantic Kernel that could turn prompt injection into host-level remote code execution (RCE).\\n\\nA single prompt was enough to launch _calc.exe_ on the device running our AI agent, with no browser exploit, malicious attachment, or memory corruption bug needed. The agent simply did what it was designed to do: interpret natural language, choose a tool, and pass parameters into code.\\n\\nFigure 1. Illustration of CVE-2026-26030 exploitation using a local model.\\n\\nThis scenario is the real security story behind modern AI agents. Once an AI model is wired to tools, prompt injection draws a thin line between being just a content security problem and becoming a code execution primitive. In this post in our research series on AI agent framework security, we show how two vulnerabilities in Semantic Kernel could allow attackers to cross that line, and what customers should do to assess exposure, patch affected agents, and investigate whether exploitation may already have occurred.\\n\\n## A representative case study: Semantic Kernel\\n\\nSemantic Kernel is Microsoft\u2019s open-source framework for building AI agents and integrating AI models into applications. With over 27,000 stars on GitHub, it provides essential abstractions for orchestrating AI models, managing plugins, and chaining workflows.\\n\\nDuring our security research into the Semantic Kernel framework, we identified and disclosed two critical vulnerabilities: CVE-2026-25592 and CVE-2026-26030. These flaws, which have since been fixed, could allow an attacker to achieve unauthorized code execution by leveraging injection attacks specifically targeted at agents built within the framework.\\n\\nIn the following sections, we break down the mechanics of these vulnerabilities in detail and provide actionable guidance on how to harden your agents against similar exploitation.\\n\\n## CVE-2026-26030: In-Memory Vector Store\\n\\nExploitation of this vulnerability requires two conditions:\\n\\n 1. The attacker must have a prompt injection vector, allowing influence over the agent\u2019s inputs\\n 2. The targeted agent must have the Search Plugin backed by In-Memory Vector Store functionality using the default configuration\\n\\n\\n\\nWhen both these two conditions are met, the vulnerability enables an attacker to achieve RCE from a prompt.\\n\\nTo demonstrate how this vulnerability could be exploited, we built a \u201chotel finder\u201d agent using Semantic Kernel. First, we created an In Memory Vector collection to store the hotels\u2019 data, then exposed a _search_hotels(city=\u2026)_ function to the kernel (agent) so that the AI model could invoke it through tool calling.\\n\\nFigure 2. Semantic Kernel agent configured with In-Memory Vector collection.\\n\\nWhen a user inputs, for example, _\u201cFind hotels in Paris,\u201d_ the AI model calls the search plugin with _city= \\”Paris\\”._ The plugin then first runs a deterministic filter function to narrow down the dataset and computes vector similarity (embeddings).\\n\\nWith this understanding of how a Semantic Kernel agent performs the search, let\u2019s dive deep into the vulnerability.\\n\\n#### Issue 1: Unsafe string interpolation\\n\\nThe default filter function that we mentioned previously is implemented as a Python lambda expression executed using _eval()_. In our example, The default filter will result to _new_filter = \\”lambda x: x.city == ‘Paris’\\”_.\\n\\nFigure 3. Default filtering function definition.\\n\\nThe vulnerability is that _kwargs[param.name]_ is AI model-controlled and not sanitized. This acts as a classic injection sink. By closing the quote (_’_) and appending Python logic, an attacker could turn a simple data lookup into an executable payload:\\n\\n * **Input:** _’ or MALICIOUS_CODE or ‘_\\n * **Result:** _lambda x: x.city == \\” or MALICIOUS_CODE or \\”_\\n\\n\\n\\n#### Issue 2: Avoidable blocklist\\n\\nThe framework developers anticipated this RCE risk and implemented a validator that parses the filter string into an Abstract Syntax Tree (AST) before execution.\\n\\nFigure 4. Blocklist implementation.\\n\\nBefore running a user-provided filter code, the application runs a validation function designed to block unsafe operations. At a high level, the validation does the following:\\n\\n 1. It only allows lambda expressions. It rejects outright any attempt to pass full code blocks (such as import statements or class definitions).\\n 2. It scans every element in the code for dangerous identifiers and attributes that could enable arbitrary code execution (for example, strings like _eval, exec, open, __import__,_ and similar ones). If any of these identifiers appear, the code is rejected.\\n 3. If the code passes both checks, it is executed in a restricted environment where Python’s built-in functions (like _open_ and _print_) are deliberately removed. So even if something slips through, it shouldn’t have access to dangerous capabilities.\\n\\n\\n\\nThe resulting lambda is then used to filter records in the Vector Store.\\n\\nWhile this approach is solid in theory, blocklists in dynamic languages like Python are inherently fragile because the language\u2019s flexibility allows restricted operations to be reintroduced through alternate syntax, libraries, or runtime evaluation.\\n\\nWe found a way to bypass this blocklist implementation through a specially crafted exploit prompt.\\n\\n#### Exploit\\n\\nOur exploit prompt was designed to manipulate the agent into triggering a Search Plugin invocation with an input that ultimately leads to malicious code execution:\\n\\nA Malicious prompt demanding execution of the search_hotels function with the malicious argument.\\n\\nThis prompt circumvented the agent to trigger the following function calling:\\n\\nInvocation of the \\”search hotels\\” function with the malicious argument.\\n\\n_As result, the lambda function_ was _formatted as_ the following a _nd executed inside eval()._ This payload escaped the template string, traversed Python\u2019s class hierarchy to locate _BuiltinImporter_ , and used it to dynamically load _os_ and _call system()_. These steps bypassed the import blocklists to launch an arbitrary shell command (for example, _calc.exe_) while keeping the template syntax valid with a clean closing expression.\\n\\nThe filter function didn\u2019t block the payload because of the following reasons:\\n\\n**1\\\\. Missing dangerous names**\\n\\nThe payload used several attributes that weren\u2019t in the blocklist:\\n\\n * **___name___** \u2013 Used to find _BuiltinImporter_ by name\\n * **_load_module_** \u2013 The method that imports modules\\n * **_system_** \u2013 The method that executes shell commands\\n * **_BuiltinImporter_** \u2013 The class itself\\n\\n\\n\\n**2\\\\. Structural check passes**\\n\\nThe payload was wrapped inside a valid lambda expression. The check _isinstance(tree.body, ast.Lambda) _passed because the entire thing is in itself a lambda that just happens to contain malicious code in its body.\\n\\n**3\\\\. Empty ___builtins___ is irrelevant** \\nThe _eval()_ call used _{ \\”__builtins__\\”: {}}_ to remove access to built-in functions. However, this protection was meaningless because the payload never used built-ins directly. Instead, it started with _tuple()_ , which exists regardless of the _builtins_ environment, and crawled through Python’s type system to reach dangerous functionality.\\n\\n**4\\\\. No _ast.Subscript_ checking** \\nWhile not used in this payload, it’s worth noting that the filter only checked _ast.Name_ and _ast.Attribute_ nodes. If the payload needed to use a blocked name, it could\u2019ve accessed it using bracket notation (for example, _obj[ ‘__class__’] _instead _of obj.__class___), which creates an _ast.Subscript_ node that the validation completely ignored.\\n\\n### Mitigation\\n\\nAfter responsibly disclosing the vulnerability to MSRC, the Microsoft Semantic Kernel team implemented a comprehensive fix using four layers of protection to eliminate every escape primitive needed to turn a lambda filter into executable code:\\n\\n * **AST node-type allowlist** \u2013 Permits only safe constructs like comparisons, boolean logic, arithmetic, and literals.\\n * **Function call allowlist** \u2013 Checks even allowed AST call nodes to ensure only safe functions can be invoked.\\n * **Dangerous attributes blocklist** \u2013 Blocks class hierarchy traversal (for examples, ___class__, __subclasses___).\\n * **Name node restriction** \u2013 Allows only the lambda parameter (for example, _x_) as a bare identifier and rejects references to _os_ , _eval_ , _type_ , and others.\\n\\n\\n\\n##### **How do I know if I am affected?**\\n\\nYour agent is vulnerable to CVE-2026-26030 if it meets all of the following conditions:\\n\\n * It uses the Python package semantic-kernel.\\n * It\u2019s running a framework version prior to 1.39.4.\\n * It uses the _In-Memory Vector Store_ and relies on its filter functionality (when acting as the backend for the Search Plugin using default configurations).\\n\\n\\n\\n##### **What to do if I am affected?******\\n\\nYou don\u2019t need to rewrite your agent. Upgrading the Python semantic-kernel dependency to version 1.39.4 or higher mitigates the risk.\\n\\n##### **What about the time that my agent was vulnerable?**\\n\\nWhile patching closes the bug, but it doesn\u2019t answer the retrospective question defenders care about: whether their agent was exploited before they upgraded.\\n\\nFirst, define the vulnerable window for each affected deployment: from the moment a vulnerable Semantic Kernel Python version was deployed until the moment version 1.39.4 or later was installed. Any investigation should focus on that time range.\\n\\nSecond, hunt for host-level post-exploitation signals during that vulnerable window. Because successful exploitation results in code execution on the host, the most useful evidence is in endpoint telemetry: suspicious child processes, outbound connections, or persistence artifacts created by the agent host process. We provide a set of practical advanced hunting queries for further investigation in a separate section of this blog.\\n\\nIf you find suspicious activity during that window, treat it as a potential host compromise. Review the affected host, rotate credentials and tokens accessible to the agent, and investigate what data or systems that host could reach.\\n\\n## CVE-2026-25592: Arbitrary file write through _SessionsPythonPlugin_\\n\\nBefore diving into the mechanics of this second vulnerability, here is what an agent sandbox escape looks like in practice: with a single prompt, an attacker could bypass a cloud-hosted sandbox, write a malicious payload directly to the host device\u2019s Windows Startup folder, and achieve full RCE.\\n\\nThe container boundary\\n\\nSemantic Kernel includes a built-in plugin called _SessionsPythonPlugin_ that allows agents to safely execute Python code inside Azure Container Apps dynamic sessions, which are isolated cloud hosted sandboxes with their own filesystem.\\n\\nThe security model relies entirely on this boundary. Code runs in the isolated sandbox and cannot touch the host device where the agent process runs. To help move data in and out of the sandbox, the plugin uses helper functions like _UploadFile_ and _DownloadFile_ , which run on the host side to transfer files across this boundary.\\n\\n## The vulnerability\\n\\nIn the .NET software development kit (SDK), _DownloadFileAsync_ was accidentally marked with a _[KernelFunction]_ attribute, which officially advertised it to the AI model as a callable tool, complete with its parameter schema:\\n\\n\\n\\nBecause of this attribute, the _localFilePath_ parameter, which dictates exactly where _File.WriteAllBytes()_ saves data on the host device, was now entirely AI controlled. With no path validation, directory restriction, or sanitization in place, an attacker wouldn\u2019t need a complex hypervisor exploit; they just needed to prompt the model to do it for them.\\n\\n_(Note: Arbitrary File Read. A similar vulnerability existed in reverse for the upload_file() function across both the Python and .NET SDKs. It accepted any local file path without validation, allowing prompt injections to exfiltrate sensitive host files, like SSH keys or credentials, directly into the sandbox)._\\n\\n## Attack chain overview\\n\\nBy chaining two exposed tools, an attacker could turn standard function calling into a sandbox escape:\\n\\n\\n\\n**Step 1: Create the payload**\\n\\nAn injected prompt instructs the agent to use the _ExecuteCode_ tool to generate a malicious script inside the isolated container:****\\n\\nAt this point, the payload is contained. It exists only in the sandbox and cannot execute on the host.\\n\\n**Step 2: Escape the sandbox******\\n\\nA second injected instruction tells the AI model to use the _DownloadFileAsync_ tool to download the file to a dangerous location on the host:\\n\\n\\n\\nThe agent calls:\\n\\n\\n\\nThe agent fetches the script from the sandbox’s API and writes it directly to the host’s _Windows\\\\Start Menu\\\\Programs\\\\Startup_ folder.\\n\\n**Step 3: Execute the code******\\n\\nOn the next user sign-in, the script runs, granting full host compromise.\\n\\nThis exploit illustrates the MITRE ATLAS technique AML.T0051 (LLM Prompt Injection) cascading into AML.T0016 (Obtain Capabilities).\\n\\nExposing _DownloadFileAsync_ provided a direct file write primitive on the host filesystem, effectively negating the container isolation.\\n\\n#### The fix and how to defend\\n\\nSemantic Kernel patched this vulnerability by removing the root cause of tool exposure and adding defense in depth:\\n\\n**Removed AI access** \u2013 The _[KernelFunction]_ attribute was removed, making the function invisible to the AI model. The AI agent can no longer invoke it, and prompt injection can no longer reach it:\\n\\n\\n\\nThis single change breaks the entire attack chain. The AI can now only be called directly by the developer’s intentional code.\\n\\n * **Path validation** \u2013 For developers calling the function programmatically, a _ValidateLocalPathForDownload()_ method was added using path canonicalization _(Path.GetFullPath())_ and directory allowlist matching to ensure the target path falls within permitted directories:\\n\\nSimilar opt-in protections were applied to uploads.\\n\\n##### How do I know if I am affected?\\n\\nYour agent is vulnerable to CVE-2026-25592 if it uses a Semantic Kernel .NET SDK version older than 1.71.0.\\n\\n## Defending the agentic edge\\n\\nIf you use Semantic Kernel, our primary recommendation is to upgrade immediately. You don\u2019t need to rewrite your agent’s architecture; the security updates simply remove the AI model\u2019s ability to trigger these functions autonomously.\\n\\nMore broadly, defending AI agents requires acknowledging that AI models aren\u2019t security boundaries. Security teams must correlate signals across two layers: the AI model level (intent detection through meta prompts and content safety filters) and the host level (execution detection). If an attacker bypasses the AI model guardrails, traditional endpoint defense must be in place to detect anomalous behavior, such as an AI agent process suddenly spawning command lines or dropping scripts into Startup folders.\\n\\n## Not bugs, but developed by design\\n\\nUntrusted data being used as input for high-risk operations isn\u2019t entirely new. In the early days of web application security, such input was passed directly into SQL queries or filesystem APIs. Today, agents are doing something similar, in that they could map untrusted natural-language input to system tools.\\n\\nThe overarching lesson from both vulnerabilities is that both aren\u2019t bugs in the AI model itself, but rather issues in agent architecture and tool design. We must make a clear distinction between model behavior and agent architecture. The AI model functions exactly as it was designed to: translate intent into structured tool calls.\\n\\nWhen models are connected to system tools, prompt injection risks may extend beyond typical chatbot misuse and require additional safeguards. Instead, it becomes a direct path to concrete execution primitives like data exfiltration, arbitrary file writes, and RCE. For a deeper look at the runtime risks of tool-connected AI models, see Running OpenClaw safely: identity, isolation, and runtime risk.\\n\\nAs mentioned previously, your LLM is not a security boundary. The tools you expose define your attacker\u2019s affected scope. Any tool parameter the model can influence must be treated as attacker-controlled input.\\n\\nIn the next blog in this series, we\u2019ll expand beyond Semantic Kernel to explore structurally similar execution vulnerabilities that we found in other widely used third-party agent frameworks.\\n\\n* * *\\n\\n## CTF challenge: Attack your own agent\\n\\nIf you want to see how prompt injections escalate into execution and to put your skills to the test, we’ve packaged the vulnerable hotel-finder agent that we described in this blog into an interactive, hands-on capture-the-flag (CTF) challenge.\\n\\nThis CTF challenge lets you step into the shoes of an attacker and try to exploit the CVE-2026-26030 vulnerability in a controlled environment. You need to craft a prompt injection that not only bypasses the agent\u2019s natural language defenses but also smuggle a Python AST-traversal payload through the vulnerable _eval()_ sink.\\n\\nTo see if you can manipulate the AI model into launching arbitrary code and popping _calc.exe_ on the server, download the challenge, spin it up in a sandbox, and see if you can achieve RCE. **_Keep in mind that this challenge is for educational purposes only, and shouldn\u2019t be run in production environments._**\\n\\n\\n\\nReconnaissance:\\n\\n\\n\\nExploit (jailbreak and payload):\\n\\n\\n\\nNote: Because the agent will running locally on your device, _calc.exe_ will open on your desktop. In a real-world scenario, such an executable file will launch remotely on the server hosting the agent.\\n\\nDownload the CTF challenge: https:\/\/github.com\/amiteliahu\/AIAgentCTF\/tree\/main\/CVE-2026-26030\\n\\n### Advanced hunting\\n\\nThe following advanced hunting queries lets you surface suspicious activities from Semantic Kernel agents.\\n\\n#### Detect common RCE post-exploitation child processes from Semantic Kernel agent hosts\\n \\n \\n DeviceProcessEvents\\n | where Timestamp \\u003e ago(30d)\\n | where InitiatingProcessCommandLine matches regex @\\”(?i)semantic[\\\\s_\\\\-]?kernel\\”\\n or InitiatingProcessFolderPath matches regex @\\”(?i)semantic[\\\\s_\\\\-]?kernel\\”\\n | where FileName in~ (\\n \\”cmd.exe\\”, \\”powershell.exe\\”, \\”pwsh.exe\\”, \\”bash.exe\\”, \\”wsl.exe\\”,\\n \\”certutil.exe\\”, \\”mshta.exe\\”, \\”rundll32.exe\\”, \\”regsvr32.exe\\”,\\n \\”wscript.exe\\”, \\”cscript.exe\\”, \\”bitsadmin.exe\\”, \\”curl.exe\\”,\\n \\”wget.exe\\”, \\”whoami.exe\\”, \\”net.exe\\”, \\”net1.exe\\”, \\”nltest.exe\\”,\\n \\”klist.exe\\”, \\”dsquery.exe\\”, \\”nslookup.exe\\”\\n )\\n | project \\n Timestamp,\\n DeviceName,\\n AccountName,\\n FileName,\\n ProcessCommandLine,\\n InitiatingProcessFileName,\\n InitiatingProcessCommandLine,\\n InitiatingProcessFolderPath\\n | sort by Timestamp desc\\n \\n\\n#### Detect .NET hosting Semantic Kernel that spawns suspicious children\\n \\n \\n DeviceProcessEvents\\n | where Timestamp \\u003e ago(30d)\\n | where InitiatingProcessFileName in~ (\\”dotnet.exe\\”)\\n | where InitiatingProcessCommandLine matches regex @\\”(?i)(semantic[\\\\s_\\\\-]?kernel|SKAgent|kernel\\\\.run)\\”\\n | where FileName in~ (\\n \\”cmd.exe\\”, \\”powershell.exe\\”, \\”pwsh.exe\\”, \\”bash.exe\\”,\\n \\”certutil.exe\\”, \\”curl.exe\\”, \\”whoami.exe\\”, \\”net.exe\\”\\n )\\n | project \\n Timestamp,\\n DeviceName,\\n AccountName,\\n FileName,\\n ProcessCommandLine,\\n InitiatingProcessFileName,\\n InitiatingProcessCommandLine\\n | sort by Timestamp desc\\n \\n\\n## Learn more\\n\\nFor the latest security research from the Microsoft Threat Intelligence community, check out the Microsoft Threat Intelligence Blog.\\n\\nTo get notified about new publications and to join discussions on social media, follow us on LinkedIn, X (formerly Twitter), and Bluesky.\\n\\nTo hear stories and insights from the Microsoft Threat Intelligence community about the ever-evolving threat landscape, listen to the Microsoft Threat Intelligence podcast.\\n\\nReview our documentation to learn more about our real-time protection capabilities and see how to enable them within your organization. \\n\\n * Learn more about securing Copilot Studio agents with Microsoft Defender \\n * Evaluate your AI readiness with our latest Zero Trust for AI workshop.\\n * Learn more about Protect your agents in real-time during runtime (Preview)\\n * Explore how to build and customize agents with Copilot Studio Agent Builder \\n * Microsoft 365 Copilot AI security documentation \\n * How Microsoft discovers and mitigates evolving attacks against AI guardrails \\n\\n\\n\\nThe post When prompts become shells: RCE vulnerabilities in AI agent frameworks appeared first on Microsoft Security Blog.”,”published”:”2026-05-07T20:22:39″,”modified”:”2026-05-07T20:22:39″,”type”:”mssecure”,”title”:”When prompts become shells: RCE vulnerabilities in AI agent frameworks”,”source”:””,”references”:””,”id”:”MSSECURE:4E20DBAC465767E4D354336F2963D674″,”bulletinFamily”:”blog”,”cwe”:null,”cvelist”:[“CVE-2026-25592″,”CVE-2026-26030″],”sourceData”:””,”sourceHref”:””,”cvss”:{“score”:9.9,”severity”:”CRITICAL”,”vector”:”CVSS:3.1\/AV:N\/AC:L\/PR:L\/UI:N\/S:C\/C:H\/I:H\/A:H”,”version”:”3.1″},”cvss2″:{},”cvss3″:{“version”:””,”vectorString”:””,”baseScore”:0,”baseSeverity”:””,”attackVector”:””,”attackComplexity”:””,”privilegesRequired”:””,”userInteraction”:””,”scope”:””,”confidentialityImpact”:””,”integrityImpact”:””,”availabilityImpact”:””,”cvssV3″:{“version”:””,”vectorString”:””,”baseScore”:0,”baseSeverity”:””,”attackVector”:””,”attackComplexity”:””,”privilegesRequired”:””,”userInteraction”:””,”scope”:””,”confidentialityImpact”:””,”integrityImpact”:””,”availabilityImpact”:””}},”href”:”https:\/\/www.microsoft.com\/en-us\/security\/blog\/2026\/05\/07\/prompts-become-shells-rce-vulnerabilities-ai-agent-frameworks\/”,”category_name”:”News”,”post_link”:””,”product”:””,”version”:””,”vendor”:””,”ai_description”:””,”ai_severity”:””,”ai_vendor”:””,”ai_product”:””,”ai_version”:””,”ai_score”:0}<\/p>\n","protected":false},"excerpt":{"rendered":"
{“lastseen”:”2026-05-07T21:28:40″,”description”:”In this article\\n\\n 1. A representative case study: Semantic Kernel\\n 2. CVE-2026-26030: In-Memory Vector Store\\n 3. CVE-2026-25592: Arbitrary file write through SessionsPythonPlugin\\n 4. The vulnerability\\n…<\/p>\n","protected":false},"author":1,"featured_media":0,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[4],"tags":[9,6,8,45,12,110,13,7,11,5],"class_list":["post-52183","post","type-post","status-publish","format-standard","hentry","category-category_news","tag-critical","tag-cve","tag-cvss","tag-cvss-99","tag-exploit","tag-mssecure","tag-news","tag-security","tag-tapic","tag-vulnerability"],"yoast_head":"\n