Semantic Kernel CVSS 10.0 Vulnerability: What You Need to Know

NAS Digital — Tue, 09 Jun 2026 17:52:56 +0000

On 7 May 2026, Microsoft disclosed critical vulnerabilities in Semantic Kernel, the official .NET framework used to build AI agents and LLM-powered applications. Among them was CVE-2026-25592, a vulnerability that received a CVSS 10.0 rating.

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.

From a CVE perspective, they're correct.

However, the vulnerability highlights a broader security problem that can still exist in many Semantic Kernel deployments: allowing AI-controlled values to flow into privileged operations without strict validation.

This post explains what CVE-2026-25592 was, how it worked in a real .NET application, why the underlying pattern remains relevant, and what developers should be doing to secure their Semantic Kernel implementations.

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 centered 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 — could 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 may result in code execution.

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

The Broader Lesson

Microsoft's fix in Semantic Kernel 1.71.0 addresses the specific vulnerability that was reported.

However, the broader lesson extends beyond a single method.

The root problem was allowing AI-generated values to reach privileged operations without appropriate validation.

Although the reported vulnerability has been remediated, developers can unintentionally recreate the same class of issue in custom implementations.

Examples include:

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 a custom [KernelFunction] accepts AI-controlled input and passes it directly into operating system, database, filesystem, or network operations, the same trust-boundary problem can reappear regardless of Semantic Kernel version.

The important question is not:

"Am I running 1.71.0?"

The important 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 whenever possible.

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

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")
        .TrimEnd(Path.DirectorySeparatorChar)
        + Path.DirectorySeparatorChar;

    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 relevant 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.

Human Approval Controls

Many enterprise teams rely on human-in-the-loop controls before allowing agents to perform sensitive actions.

Semantic Kernel includes mechanisms intended to support these workflows. However, developers have reported scenarios where confirmation behaviour did not align with their expectations.

For that reason, organizations with strict approval requirements should consider implementing confirmation logic explicitly at the application layer rather than relying solely on framework-level controls.

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 or Later

Apply Microsoft's security fixes without delay.

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 exclusively 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 isolation where practical

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 where appropriate
Conduct a security assessment

The Bigger Picture

CVE-2026-25592 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 tension.

Semantic Kernel is not unique in this regard. Similar patterns can emerge in any framework where an LLM is allowed to invoke application functionality. Whenever model-generated output crosses into privileged operations, the trust boundary 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.

This version is something I'd be comfortable putting my name on from a technical accuracy standpoint. It still has a strong thesis, but it no longer makes any claim that requires proving Microsoft's patch is bypassable. Instead, it uses the CVE as a concrete example of a broader security pattern, which is both accurate and more valuable to readers.

DEV Community: NAS Digital