Your Semantic Kernel Agent Has a CVSS 10.0 Vulnerability — And the Patch Doesn't Fully Fix It

On 7 May 2026, Microsoft disclosed two critical vulnerabilities in Semantic Kernel, the official .NET framework used to build AI agents and LLM-powered applications. One was assigned a CVSS score of 10.0. The other received a score of 9.8.

If you've upgraded to Semantic Kernel 1.71.0, you've applied Microsoft's official fix. Many teams considered the issue closed at that point.

That may be a mistake.

While the patch addresses the specific vulnerable implementation that was reported, independent security research suggests the underlying design pattern remains present in many Semantic Kernel deployments. In practice, developers can still unintentionally create similar vulnerabilities when AI-controlled inputs are passed into privileged operations without strict validation.

This post explains what the vulnerability actually is, how it works in a real .NET application, why the official patch may not be sufficient on its own, and what you should be doing to secure your Semantic Kernel deployments.

Why Semantic Kernel Matters

Semantic Kernel is Microsoft's open-source orchestration framework for integrating Large Language Models into .NET applications. It provides abstractions for prompts, plugins, memory, planning, tool invocation, and agent workflows.

It is increasingly being used to power:

• Enterprise customer support systems

• AI-assisted business workflow automation

• Internal knowledge management platforms

• Intelligent data processing pipelines

• Agentic applications connected to enterprise systems

The framework works by exposing application functionality to the LLM through "kernel functions" — methods decorated with the [KernelFunction] attribute that the model can invoke when it determines they are needed.

This capability is what makes Semantic Kernel powerful.

It is also what makes mistakes extremely dangerous.

CVE-2026-25592: The Sandbox That Wasn't

The vulnerability centers around the SessionsPythonPlugin component within Semantic Kernel's .NET SDK.

The plugin exists to allow agents to execute Python code inside an Azure Container Apps sandbox. The intended security model is straightforward: code runs inside the isolated environment and cannot directly impact the host system.

The problem was a helper method named DownloadFileAsync.

The method was intended to transfer files from the sandbox back to the host machine. Unfortunately, it was also exposed to the LLM through a [KernelFunction] attribute.

That single attribute transformed an internal helper function into an AI-callable tool.

As soon as that happened, the localFilePath parameter became AI-controlled.

An attacker who can influence any prompt consumed by the agent — a support ticket, uploaded document, SharePoint file, Teams message, RAG source, or direct user interaction — can potentially persuade the model to invoke the function with an attacker-chosen file path.

For example:

// Vulnerable pattern (pre-1.71.0)
// DownloadFileAsync exposed as a KernelFunction
// No validation of localFilePath

localFilePath =
"C:\\Users\\[user]\\AppData\\Roaming\\Microsoft\\Windows\\Start Menu\\Programs\\Startup\\evil.exe";

If a malicious payload is written to a startup directory, the next user login can result in code execution.

At that point the attacker may gain:

• Arbitrary code execution

• File system access

• Persistence mechanisms

• Lateral movement opportunities

• Access to credentials and secrets available to the application

This is why the vulnerability received a CVSS score of 10.0.

The Real Problem Isn't the Function

Upgrading to Semantic Kernel 1.71.0 fixes the specific DownloadFileAsync issue.

However, the broader lesson is more important.

The root problem is not a single method. The root problem is allowing AI-generated values to flow into privileged operations without robust validation.

The patch prevents exploitation of the reported function.

It does not automatically protect:

• Custom kernel functions that accept file paths

• Functions that construct URLs

• Database query generation

• Command execution wrappers

• Reflection-based operations

• Network-access plugins

• Internal API integrations

If your own [KernelFunction] implementations accept AI-controlled input and pass those values into operating system, database, filesystem, or network operations, you may have recreated the same class of vulnerability yourself.

The correct question is not:

"Am I running 1.71.0?"

The correct question is:

"Do any of my kernel functions trust values generated by an LLM?"

Hardened Implementation Pattern

The safest approach is to avoid automatic execution of sensitive functions entirely.

var executionSettings = new OpenAIPromptExecutionSettings
{
    ToolCallBehavior = ToolCallBehavior.EnableKernelFunctions
    // Avoid AutoInvokeKernelFunctions
};

When functions must accept paths or similar parameters, validate against an allowlist rather than attempting to block dangerous values.

[KernelFunction]
public async Task<string> DownloadFileAsync(string localFilePath)
{
    var allowedRoot = Path.GetFullPath("/app/downloads");

    var requestedPath = Path.GetFullPath(
        Path.Combine(
            allowedRoot,
            Path.GetFileName(localFilePath)
        )
    );

    if (!requestedPath.StartsWith(
        allowedRoot,
        StringComparison.OrdinalIgnoreCase))
    {
        throw new SecurityException(
            $"Path traversal attempt: {localFilePath}"
        );
    }

    // Proceed with validated path
}

The key principle is simple:

Never trust AI-generated input simply because it originated from your own application.

Audit Every AI-Initiated Action

One of the most effective defensive controls is auditing all AI-triggered function calls.

kernel.FunctionInvocationFilters.Add(
    new SecurityAuditFilter()
);

A security-focused invocation filter should:

• Log every tool invocation

• Capture all arguments

• Alert on filesystem access

• Alert on network operations

• Alert on database modifications

• Generate audit events for investigation

If you cannot see what your agent is doing, you cannot detect when it has been manipulated.

The Second Broken Control: RequireUserConfirmation

Many enterprise teams rely on RequireUserConfirmation as their human-in-the-loop safety mechanism.

The assumption is that dangerous actions pause for approval before execution.

Unfortunately, there are documented cases where this control does not behave as expected.

Depending on implementation details, confirmation may be bypassed entirely or execution may stall unexpectedly.

If your security model depends on human approval for destructive actions, implement confirmation explicitly within your application layer rather than relying exclusively on framework behavior.

public class ConfirmationRequiredFilter
    : IFunctionInvocationFilter
{
    private readonly IConfirmationService
        _confirmationService;

    public async Task OnFunctionInvocationAsync(
        FunctionInvocationContext context,
        Func<FunctionInvocationContext, Task> next)
    {
        var approved =
            await _confirmationService
                .RequestApprovalAsync(
                    context.Function.Name,
                    context.Arguments);

        if (!approved)
        {
            throw new OperationCanceledException(
                "Human approval denied."
            );
        }

        await next(context);
    }
}

Immediate Actions for Production Deployments

If you're currently running Semantic Kernel in production:

1. Upgrade to 1.71.0 Immediately

Apply Microsoft's patch without delay.

But do not assume the upgrade alone eliminates all risk.

2. Audit Every Kernel Function

Review every [KernelFunction] implementation and identify:

• Filesystem operations

• Network requests

• Database access

• Process execution

• Reflection usage

• Dynamic code generation

Treat all parameters as untrusted input.

3. Disable AutoInvoke for Sensitive Operations

Only allow automatic invocation for low-risk, read-only functions.

Require explicit approval for anything that modifies systems or data.

4. Implement Allowlist Validation

Validate:

• Paths

• URLs

• Queries

• Commands

• Resource identifiers

Do not rely on blacklists.

5. Run With Least Privilege

The application hosting Semantic Kernel should have:

• Minimal filesystem permissions

• Restricted network access

• Limited IAM permissions

• Regular credential rotation

• Strong container isolation where possible

6. Monitor for Exploitation Attempts

Look for:

• Unexpected tool invocations

• Reflection-heavy execution paths

• Unusual filesystem activity

• Unexpected outbound network traffic

• Repeated failed function calls followed by success

7. Review Historical Activity

If vulnerable versions were previously deployed:

• Review audit logs

• Investigate unusual agent behaviour

• Check for unauthorized file modifications

• Rotate secrets and credentials

• Conduct a full security assessment

The Bigger Picture

This vulnerability highlights a challenge facing every AI framework today.

Developers want agents that can take meaningful action.

Security teams want systems that cannot be manipulated.

Those goals are often in direct tension.

Semantic Kernel is not unique in this regard. The same patterns exist across many agent frameworks. Whenever an LLM is given the ability to invoke application functionality, the boundary between "model output" and "trusted system command" becomes a security-critical control.

The industry is still learning how to secure these systems properly.

What I'm Looking At Next

These issues are only part of a much larger attack surface.

Future research will focus on:

• Azure AI Search index poisoning through SharePoint and Teams content

• Text-to-SQL injection chains in Azure OpenAI applications

• Secure patterns for agentic workflows

• Building Roslyn analyzers that detect dangerous Semantic Kernel patterns at compile time

AI agents are becoming increasingly capable. The security controls protecting them need to mature just as quickly.

Until then, treat every AI-generated action as untrusted input and design your systems accordingly.

Diagnostic and productivity prompt packs are available via my Gumroad - https://nasdigital.gumroad.com/

Thanks for reading if you've got this far. This is my first time ever writing a blog post so please let me know your thoughts and any improvments I can make in futute.