Semantic Kernel prompt injection flaws show agent tool calls can become host execution
Microsoft Defender Security Research disclosed two fixed Semantic Kernel flaws where prompt injection could influence trusted tool parameters, reaching Python command execution in one path and unintended host file writes in another.
Date
May 7, 2026
First Seen
May 7, 2026
Last Reviewed
May 18, 2026
Publisher
Microsoft Security Blog
Source Type
article
Related reading
OpenClaw Security GuideA practical baseline for local binding, scoped credentials, sandboxing, runtime checks, and Armorer Guard.
Securing OpenClaw with Armorer GuardHow Armorer wraps OpenClaw with managed setup, Docker hardening, health checks, approvals, and Guard-backed scanning.
Semantic Kernel Prompt Injection Flaws Show Agent Tool Calls Can Become Host Execution
Summary
Microsoft Defender Security Research disclosed two fixed Semantic Kernel flaws where prompt injection could influence trusted tool parameters, reaching Python command execution in one path and unintended host file writes in another.
Why It Matters
These vulnerabilities reinforce a durable agent-security lesson: once a model can select tools and provide tool parameters, prompt injection can become an execution-layer risk if the framework or tool implementation treats model output as trusted input.
For OpenClaw and Armorer-style local agent stacks, the affected product is not the direct dependency in every deployment. The transferable risk is the same pattern seen across local coding agents, MCP servers, browser agents, and workflow assistants: natural-language input can influence privileged tool calls, filesystem paths, query filters, child processes, and sandbox transfer helpers. A safe-looking tool description does not make the tool implementation a security boundary.
Attack Path
- An agent ingests attacker-controlled or lower-trust content through chat, retrieval, documents, browsing, tickets, or another prompt-injection vector.
- The model is allowed to call a framework tool or plugin with parameters derived from that content.
- The framework/tool implementation interpolates a model-controlled parameter into code, a query filter, filesystem path, or host-side helper without complete validation.
- Existing prompt guardrails or identifier blocklists fail to stop a crafted payload.
- The agent host executes a command, writes to a sensitive host path, reads a local file, or otherwise crosses the intended tool/sandbox boundary.
Affected Surface
- Python
semantic-kernelversions before 1.39.4 when using the In-Memory Vector Store filter functionality behind the Search Plugin with default configuration, according to Microsoft. - Semantic Kernel .NET SDK versions before 1.71.0 for the
SessionsPythonPluginarbitrary file-write issue, according to Microsoft. - Agent frameworks and local control planes that expose filesystem, code execution, search, retrieval, shell, browser, database, or sandbox-transfer tools to model-directed calling without strict server-side validation and containment.
Armorer Relevance
Armorer could help reduce this class of risk by giving operators a local control plane to inventory which tools are enabled, which processes and containers they run in, what filesystem and network access they receive, and which credentials are available to the agent runtime. Docker isolation and per-tool network/filesystem limits can reduce blast radius when a tool implementation is vulnerable. Runtime monitoring can flag suspicious child processes, unexpected file writes, outbound connections, or tool-call patterns that look unlike normal workflow behavior.
Credential handling and health checks are also relevant. If an agent host or tool server is exploitable, scoped credentials, rotation guidance, and checks for risky mounts, broad home-directory access, unauthenticated local services, or exposed tool endpoints can make compromise harder to turn into durable access. These controls would not prove Armorer would have prevented the Semantic Kernel bugs, but they provide places to enforce and check the containment assumptions that agent frameworks often depend on.
Evidence
- Microsoft says
CVE-2026-26030could be exploited when prompt injection influenced Search Plugin input backed by the In-Memory Vector Store filter functionality in vulnerable Python Semantic Kernel versions. - Microsoft says the vulnerable filter path used evaluated Python lambda expressions and that a crafted payload could bypass blocklist-based validation.
- Microsoft says
CVE-2026-25592exposed a host-side download helper to model-directed function calling in the .NET SDK, allowing arbitrary file writes before the fix. - Microsoft reports both issues were fixed by upgrading Python
semantic-kernelto 1.39.4 or later and Semantic Kernel .NET SDK to 1.71.0 or later.
Mitigations
- Upgrade Python
semantic-kernelto 1.39.4 or later and Semantic Kernel .NET SDK to 1.71.0 or later where applicable. - Treat model output and tool arguments as untrusted input; validate parameters inside the tool/server boundary, not only in prompts.
- Prefer allowlists for safe AST nodes, functions, paths, and operations over fragile blocklists of dangerous names.
- Do not expose administrative, host-transfer, upload/download, or filesystem helper functions to model-directed tool calling unless they are intentionally designed for that use.
- Restrict sandbox transfer helpers to canonicalized, explicitly allowed directories.
- Run agent frameworks and tool servers in containers or similarly constrained environments with minimal filesystem, network, and credential access.
- Monitor the agent host for suspicious child processes, persistence artifacts, unexpected file writes, and outbound connections during any vulnerable window.
Open Questions
- Which downstream agent products embedded vulnerable Semantic Kernel versions before the fixes.
- Whether similar model-exposed helper functions exist in other agent frameworks or tool plugins.
- Which Armorer health checks should become default for model-callable filesystem, sandbox-transfer, and code-execution tools.