Prompts as RCE: why agent frameworks raise the blast radius

AI agents changed the security boundary.

A model that only generates text can still be abused, but the failure mode usually stays in the content layer. Once the same model is wired to tools (plugins/functions) that can read files, search data stores, or execute code, prompt injection stops being “just” a prompt problem. It becomes a pathway into whatever the tool layer can touch.

Microsoft’s security team published a case study on this shift using its open-source agent framework Semantic Kernel. The post describes two vulnerabilities (now fixed) where an attacker who can influence an agent’s input could potentially steer tool invocation in a way that crosses into host-level code execution.

What Microsoft says is vulnerable (and what’s fixed)#

Microsoft reports two critical issues found during internal research into Semantic Kernel:

• CVE-2026-25592: described as an arbitrary file write issue via SessionsPythonPlugin.
• CVE-2026-26030: an RCE path involving the Search Plugin when backed by an In-Memory Vector Store using default configuration.

The post frames these as framework/tooling trust failures, not “the model going rogue.” The model is doing what it is designed to do: parse language, choose a tool, and supply parameters. The vulnerability is in how the framework and plugins accept those parameters and translate them into executable behavior.

Microsoft states the flaws have been fixed, and the blog’s purpose is partly to show how to think about agentic risk: a ubiquitous orchestration layer (Semantic Kernel, LangChain, CrewAI, etc.) can become a systemic dependency. If the “model output → tool schema → code execution” mapping is unsafe in one common place, many downstream apps inherit the problem.

CVE-2026-26030: how a search feature becomes a code path#

The most instructive portion of the writeup is the “representative” exploit chain for CVE-2026-26030.

Microsoft says exploitation requires two conditions:

1. The attacker has a prompt injection vector (some way to influence the agent’s inputs).
2. The targeted agent uses the Search Plugin backed by In-Memory Vector Store functionality in its default configuration.

When those conditions hold, Microsoft demonstrates that a single prompt can be enough to reach code execution on the host running the agent. No browser exploit. No malicious attachment. No memory corruption. Just an agent doing tool calling.

The core bug: unsafe string interpolation into executable code#

In Microsoft’s example, the Search Plugin uses a default filter implemented as a Python lambda expression that is executed via eval.

The filter string is derived from model-controlled input and is not sanitized. That makes it an injection sink.

Conceptually, the flow looks like this:

• User (or attacker) supplies input.
• The model decides it should call a search tool and emits parameters.
• The plugin constructs a Python expression (a filter lambda) by interpolating those parameters into a string.
• That string is executed.

The blog’s example shows a benign filter like:

• lambda x: x.city == 'Paris'

But if an attacker can close the quote and append additional code (classic injection mechanics), the “filter” stops being just a filter. It becomes an execution primitive.

This is the security point that generalizes beyond Semantic Kernel: if model-controlled strings are ever treated as code (directly or indirectly), you have an RCE-shaped problem, even if the original feature was “just search.”

Why this matters beyond Semantic Kernel#

Even if you do not use Semantic Kernel, the post is a clean reminder of what changes when you build agents instead of chatbots:

• Tool invocation is an execution interface. Your “prompt surface” now reaches file systems, databases, internal APIs, and sometimes shells.
• Agent frameworks are a shared substrate. A bug in a popular tool adapter, memory component, or plugin can replicate across many products.
• Prompt injection becomes input validation plus authorization. The key question is not “can the model be tricked,” but “what happens when the model emits untrusted parameters into privileged code paths.”

The most dangerous pattern is also one of the most common in early agent stacks: treating model output as structured-but-trusted data.

Practical takeaways: what to check in your own agents#

Microsoft’s post includes remediation guidance at a high level (patch, assess exposure, and investigate for possible past exploitation). If you operate agentic systems, the fastest way to turn this into action is to inventory where model output crosses into execution.

🧭 Checklist (start here):

• Patch Semantic Kernel and plugins to versions that include the fixes for CVE-2026-25592 and CVE-2026-26030 (per Microsoft’s advisory and upstream release notes).
• Search your codebase for dynamic evaluation in tool layers: eval, exec, template-based code generation, expression languages, and “filters” built from strings.
• Identify tools that accept model-provided parameters that later become:
  • file paths
  • shell commands
  • SQL queries
  • code expressions (Python/JS)
  • deserialization inputs
• Review “memory” or “retrieval” plugins that take model-specified filters or queries. Retrieval systems often look read-only, but filtering and query composition can cross into execution depending on implementation.

What not to overclaim#

The Microsoft post is a vendor-authored research disclosure. It demonstrates a plausible exploitation path under specific conditions and reports the issues are fixed. It does not, in the provided material, claim widespread real-world exploitation, and it does not imply that “all prompt injection equals RCE.”

The conditions matter:

• You need an injection vector into the agent’s input.
• You need a vulnerable tool/plugin configuration.
• You need a bridge from untrusted strings to something executable.

Many deployments will not satisfy all of these at once. But the broader point still holds: in agent systems, it is increasingly easy for “just text” to end up in places that should never accept untrusted input.

How to harden the agent-tool boundary#

If you build or integrate agent frameworks, the defensive theme is simple: treat model output as hostile input.

Concrete controls that map to the failure mode described:

• Remove or strictly constrain dynamic evaluation (eval-style) in plugins. If you need filtering, implement it as data-driven logic, not code-as-strings.
• Add allowlists and type validation at the tool boundary. Validate tool parameters before execution, not after.
• Reduce tool privileges by default. If a tool only needs read access, don’t give it write access. If it only needs one directory, sandbox it there.
• Add auditing for tool calls. Log tool name, parameters (with sensitive redaction), and outcomes so you can investigate suspicious sequences.

The uncomfortable but useful conclusion is that “agent security” is mostly classic application security. The novelty is where the untrusted input comes from: a model that speaks in tool schemas.