The hottest thread on r/netsec today was not about a zero-click bug or a glamorous jailbreak. It was about a more uncomfortable question for the agent era: when an LLM tells a built-in file tool to overwrite local code, is that a critical framework vulnerability, or did the developer simply hand the model a loaded gun?

That argument is what made the thread interesting.

A new public disclosure from Project Nuka-AI claims Microsoft Semantic Kernel and the newer Microsoft Agent Framework still expose a full-chain remote-code-execution path, even after Microsoft's February fix for CVE-2026-25592. The paper says six bypasses still work. The Reddit comments did not just react to the severity score. They immediately split over something deeper: whether agent frameworks should treat model output like untrusted user input by default, or whether that responsibility stays with the application developer.

That distinction sounds academic until you look at what is actually verified.

What is clearly on the record

First, the earlier Semantic Kernel flaw is real and public.

MITRE's CVE record for CVE-2026-25592 describes an arbitrary file write via AI agent function calling in Semantic Kernel's .NET SDK. The record points to GitHub's advisory, marks the issue as critical, and says affected versions were below 1.71.0. So this is not a case where developers invented a scary story out of a vague design complaint. Microsoft and GitHub already acknowledged that the framework's tool-calling path could cross into file-system abuse.

Second, Microsoft has already spent months hardening plugins that touched the local file system.

Public pull requests in the microsoft/semantic-kernel repository show the same pattern more than once:

  • PR #13478 added file-upload security controls to SessionsPythonPlugin, including path canonicalization to block traversal.
  • PR #13644 tightened WebFileDownloadPlugin defaults, added Path.GetFullPath() checks, and switched to safer allow-list behavior.
  • PR #13683 hardened DocumentPlugin with deny-by-default AllowedDirectories, fully qualified path enforcement, UNC rejection, and canonicalization checks.

Those are not cosmetic edits. They are explicit acknowledgments that agent-facing file tools needed stronger boundaries than they originally had.

Third, Microsoft Agent Framework is close enough to Semantic Kernel that security questions are going to bleed across.

Microsoft's own migration guide from Semantic Kernel to Microsoft Agent Framework makes that proximity obvious. It is framed as a migration path, not a clean break from the old model. That does not prove every Semantic Kernel flaw automatically carries over, but it does make the researcher's basic concern plausible: if the trust boundary lives in shared orchestration patterns, not in one plugin name, the newer framework deserves scrutiny too.

What the new disclosure claims

The primary source is Project Nuka-AI's paper, The Orchestration Trust Gap: Day-Zero Bypasses in Microsoft Semantic Kernel and Agent Framework 1.0.

The paper makes four important claims:

1. the February patch for CVE-2026-25592 did not fix the broader trust problem 2. six bypass techniques still defeat the current filter logic 3. Agent Framework inherits the same unsafe orchestration assumptions 4. enterprise users may get a false sense of safety because scanners show the earlier CVE as patched

The paper also includes exploit logs and recordings, which is more useful than vague hand-waving. But this is where the story gets messy.

I could verify the existence of the paper, the earlier CVE, and the public hardening work in Microsoft's repo. I could not independently reproduce the six bypasses from this environment. More importantly, one of the paper's most specific forensic claims does not line up cleanly with the public repository.

The disclosure cites PR #13702 as a hidden security change involving recursive canonicalization. The current public PR title and body do not read like that. They describe a Python connector change to add a Semantic Kernel User-Agent header for Google GenAI clients. That mismatch does not automatically invalidate the whole disclosure, but it does mean readers should lower their confidence and separate the well-grounded parts from the parts that still need independent confirmation.

That is exactly why the Reddit thread mattered.

Reddit immediately found the real fault line

The comments were not a victory lap. They were a peer review session with teeth.

One skeptical reply boiled the issue down to this: if you give an LLM a tool that can write to local disk, of course it can write to local disk. Another commenter argued that calling this a CVSS 10.0 RCE stretches the definition, and that some of the paper's jargon looked over-claimed.

The researcher pushed back with a more interesting argument. The point, they said, is not that dangerous tools exist. The point is that the framework treats untrusted model output as if it were trusted orchestration input, then tries to clean it up with narrow string filters instead of putting a hard sandbox around high-risk operations. In the thread, the researcher compared that attitude to the old habit of blaming SQL injection on application developers instead of building safer defaults into frameworks and libraries.

That comparison is provocative, but it explains why this post rose on r/netsec. Security people are not just debating one exploit chain. They are debating where agent frameworks should draw responsibility when model output is allowed to steer file writes, downloads, shell calls, or code execution.

Why this matters beyond one Microsoft stack

The big takeaway is not "Semantic Kernel bad." The big takeaway is that AI tooling keeps trying to smuggle an old argument into a new runtime.

For years, the standard excuse for dangerous abstractions was that the developer should know better. Now the developer is wiring a stochastic model into tools that touch the file system, the network, and sometimes production credentials. Once that happens, saying "the app developer should sanitize it" starts to sound less like a principle and more like a liability transfer.

The public PR history already shows Microsoft moving toward tighter defaults on file-oriented plugins. That is evidence the original boundary was too loose. The open question is how far that reasoning should go. Does a framework merely expose tools, or does it owe users a default security model for model-driven tool invocation itself?

That is the real story under the RCE headline.

What remains uncertain

A few points need careful wording.

  • The six bypasses are still researcher-reported. I verified the disclosure and the earlier CVE, but I did not reproduce the bypasses myself.
  • The alleged MSRC "developer error" stance comes from the disclosure and Reddit summary. I did not retrieve a separate public Microsoft statement confirming that exact language.
  • The inheritance claim for Agent Framework is plausible, not settled. Microsoft's migration docs show close lineage, but not a formal admission that the newer framework shares every affected code path.
  • The PR #13702 discrepancy is real and unresolved. It weakens confidence in the paper's narrative details, even if the broader security question stays valid.

What developers should do with this

If you are using Semantic Kernel or similar agent frameworks, the practical lesson does not depend on whether you accept the paper's highest-severity framing.

Treat model output as hostile whenever it can influence file paths, download targets, shell commands, or code execution. Prefer deny-by-default directories, explicit allow-lists, and hard sandboxing around tools. Be suspicious of any safety layer that depends on catching dangerous strings after the model has already chosen the action.

That is not overreaction. Microsoft's own plugin hardening work already points in the same direction.

The real lesson

The most useful reading of this Reddit-hot story is not that Microsoft definitely shipped a fresh CVSS 10.0 disaster and got caught. The useful reading is harsher and more general.

Agent frameworks are becoming operating environments, but too many of them still talk about security like they are only helper libraries.

That gap is where the trouble starts.

Sources