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.
