DEV Community: Aditya Soni

A Prompt Injection Turned Into a Shell: Inside Semantic Kernel's Two RCE CVEs

Aditya Soni — Thu, 17 Sep 2026 14:36:35 +0000

Two ordinary agent-framework conveniences, a filterable vector search and a file-download tool, turned into remote code execution once an LLM's output was trusted a little too much. Here's what happened in Microsoft Semantic Kernel, and what to check in your own agent code today.

Prompt injection usually gets discussed as an output-quality problem: the model says something it shouldn't, or does something a user didn't ask for. CVE-2026-26030 and CVE-2026-25592, two vulnerabilities Microsoft disclosed in its Semantic Kernel framework, are a sharper reminder of what it can become: full remote code execution, demonstrated in Microsoft's own writeup by launching calc.exe on the machine running the agent.

Semantic Kernel is Microsoft's open-source framework for building agents and wiring LLMs into tool-calling applications, widely used both inside Microsoft's own ecosystem and in third-party projects. Both vulnerabilities follow the same underlying pattern in different SDKs, and that pattern is the actually useful thing to take away from this.

CVE-2026-26030: when a search filter is also a code path

This one lives in the Python SDK's InMemoryVectorStore. When an agent searches a vector store with a metadata filter, Semantic Kernel builds that filter as a Python lambda expression and evaluates it with eval() at query time. The filter parameters can include AI-model-controlled input, and according to Microsoft's account, that input was not sanitized before being interpolated into the expression.

The framework did have a blocklist meant to catch dangerous constructs. It was bypassed using Python's class hierarchy traversal, essentially reaching dangerous built-ins through an indirect attribute-access path the blocklist didn't anticipate rather than referencing them directly. Microsoft's proof of concept, built around a "hotel finder" agent scenario, used this path to launch calc.exe. The fix shipped in semantic-kernel 1.39.4 for Python.

CVE-2026-25592: a file-download tool with no path validation

The second vulnerability is in the .NET SDK's SessionsPythonPlugin. Its DownloadFileAsync function was exposed to the model through a [KernelFunction] attribute, the standard way Semantic Kernel marks a method as callable by the agent, without validating the destination path. That let a sufficiently crafted prompt cause the agent to write a file to an arbitrary location on the host, including the Windows Startup folder.

A file dropped in Startup runs automatically the next time the user logs in. That's the more consequential part of this one: it doesn't just execute code inside the agent's process, it persists past the session and past whatever sandbox the agent's normal execution was running in, because a container's sandbox isolation typically doesn't extend to filesystem locations mounted or shared with the host, and Startup-folder execution triggers outside the container entirely on the next host login. The fix shipped in the .NET SDK 1.71.0, the same day as the Python fix.

The pattern underneath both

Strip away the specifics and both vulnerabilities are the same mistake: a powerful, code-adjacent primitive, eval() in one case, unrestricted file I/O in the other, received a value that ultimately traced back to model output, and nobody treated that value as attacker-controlled. That's the actual lesson, and it generalizes far past these two specific CVEs.

An LLM's output is attacker-controlled the moment it has processed any untrusted content: a scraped webpage, a user-supplied document, retrieved search results, another agent's message. If that output can influence a filter string that gets evaluated as code, or a path that gets written to without validation, or really any string that reaches a powerful primitive without going through a narrow, explicit contract, you have the shape of this bug, regardless of which framework you're using.

What to actually check in your own code

Audit every method your framework marks as callable by the model ([KernelFunction] in Semantic Kernel, the equivalent decorator or registration call in whatever you're using). For each one, ask: if the model called this with the worst possible string, what happens?
Never eval() or exec() a value built from model output, even for something that feels as harmless as a search filter. Build a real filter DSL, a small, explicit grammar you parse and validate, rather than reaching for a code-executing shortcut because it's faster to ship.
Validate file paths against a canonicalized allowlist of directories, not a blocklist of bad patterns. The vector-store bug's blocklist bypass is a reminder that blocklists lose to creative attackers almost by definition; allowlists at least bound the failure.
Don't treat container or sandbox isolation as your whole defense. CVE-2026-25592 shows a process that looks properly contained can still reach outside it through a filesystem write that was never meant to be a privilege boundary in the first place.
If you're on Semantic Kernel, upgrade now: Python to 1.39.4 or later, .NET to 1.71.0 or later, and grep your own codebase for any [KernelFunction]-tagged method that touches the filesystem, shells out, or evaluates a string as code.

Why this keeps happening

Agent frameworks compete partly on how much they let a model do without hand-written glue code, which means each new release tends to add more direct, convenient bridges between "thing the model said" and "thing that actually executes." Every one of those bridges is a candidate for this exact failure mode. Semantic Kernel isn't unusually careless here; it's unusually well-documented, because Microsoft wrote the postmortem itself. The realistic assumption for anyone building on any agent framework is that equivalent, undisclosed instances of this pattern exist elsewhere, and the fix is the same regardless of framework: treat model output as untrusted input everywhere it lands, not just at the final response to the user.

Sources

This story was written with the assistance of an AI writing program.

DeepSeek's New Model Isn't Interesting Because of Benchmarks. It's the Pricing.

Aditya Soni — Sat, 12 Sep 2026 19:16:22 +0000

Another open-weight model beating a frontier benchmark isn't news anymore. A pricing structure that makes long-context work ten times cheaper at certain hours might actually change how you architect a product.
What DeepSeek shipped
DeepSeek released V4.1 Flash on September 10, 2026, according to the company's own API changelog and coverage from VentureBeat, Dataconomy, and DataCamp. It's a mixture-of-experts model with a reported 552-billion-parameter backbone, native vision support, and a 1-million-token context window, released under an MIT license with weights available on Hugging Face for commercial use.

On published benchmarks, DeepSeek reports 90.6 on Terminal-Bench 2.1 (up from 82.7 on the prior V4 Flash release) and 74.2% on DeepSWE v1.1 (up from 54.4%), alongside a 3,471 Codeforces rating and 90.9 on GPQA Diamond. VentureBeat's coverage frames these as "eclipsing" GPT-5.6 Sol and Claude Opus 5 on select metrics, though it's worth being precise: beating a frontier closed model on a specific benchmark subset is not the same as being a better general-purpose model, and DeepSeek's own comparison points are self-selected.

The more unusual detail is the pricing. During off-peak hours, DeepSeek prices input tokens at $0.003 per million on a cache hit, versus $0.15 per million on a cache miss, with output at $0.60 per million. Peak-hour rates roughly double. DeepSeek has also said its existing V4 Pro tier will route to V4.1 Flash after September 14, 2026, effectively retiring the older tier in favor of this one.

Why the pricing structure is the actual engineering story
A 50x gap between cache-hit and cache-miss pricing is a strong, explicit signal about where DeepSeek's infrastructure cost actually lives: recomputing attention over long contexts, not generating tokens. That's not a new insight in principle — every major provider has some form of prompt caching — but pricing it this aggressively, and pairing it with a genuine 1M-token window, changes the calculus for a specific class of application: agents and tools that repeatedly re-read a large, mostly-static context (a codebase, a knowledge base, a long conversation history) and only append a small amount of new information per turn.

If your workload looks like "re-send a 200K-token codebase snapshot on every turn, with the same snapshot for the next hour," this pricing model rewards you specifically for keeping that context stable and hitting the cache, in a way that a flat per-token price doesn't. It's an argument for restructuring how you manage context in an agent loop: batch static context in a way that maximizes cache hits, and treat cache-miss traffic as the expensive path to minimize, not just an occasional cost.

The tradeoffs nobody puts in the launch post
Off-peak pricing implies a queuing/scheduling decision you now have to make. If a meaningful chunk of the cost advantage is time-of-day dependent, batch and non-interactive workloads (evals, bulk document processing, offline agent runs) can be scheduled to capture it; latency-sensitive user-facing traffic generally can't. That's a real architectural split, not just a footnote.

Benchmark gains on Terminal-Bench and DeepSWE are coding-agent-specific. These are useful signals if you're building a coding assistant, less so if your use case is retrieval-heavy Q&A or general reasoning, where the model's relative position may differ. Don't generalize a coding-benchmark win into "best model for our RAG pipeline" without testing on your own eval set.

Open weights change your deployment options, not your operational burden. MIT-licensed weights mean you can self-host V4.1 Flash instead of using DeepSeek's API, which matters for data residency or cost-at-scale reasons — but self-hosting a 552B-parameter MoE model competently is its own significant infrastructure project, not a free lunch.

Practical takeaway
Before switching a workload to chase this pricing, model your actual cache-hit rate under realistic usage patterns, not the best case. A cache-friendly workload (stable context, frequent short follow-ups) can see genuinely large savings; a cache-unfriendly one (constantly changing context) will mostly pay the cache-miss rate and see far less benefit than the headline number suggests. Run the numbers on your own traffic shape before committing.

Sources
https://venturebeat.com/technology/deepseek-v4-1-flash-debuts-with-0-003-1m-off-peak-cached-input-rate-and-benchmarks-eclipsing-gpt-5-6-sol-claude-opus-5
https://dataconomy.com/2026/09/11/deepseek-v4-1-flash-ultralow-token-pricing/
https://api-docs.deepseek.com/updates/
https://www.datacamp.com/blog/deepseek-v4-1-flash
This story was written with the assistance of an AI writing program.

An Attacker's Multi-Agent Framework Stole Thousands of Credentials in Under Six Hours

Aditya Soni — Sat, 12 Sep 2026 09:21:16 +0000

A financially motivated attacker ran reconnaissance, exploitation, and cleanup with almost no human in the loop — using the same design patterns you'd use to build a helpful agent. That symmetry is the actual story.

What Google's threat researchers found

Google's Threat Intelligence Group (GTIG) published its Q3 2026 AI Threat Tracker documenting a mass credential-harvesting campaign carried out largely by a multi-agent framework rather than a human operator. According to GTIG's report and coverage from The Hacker News, SiliconANGLE, and Help Net Security, a suspected financially motivated actor gained access to an organization's cloud infrastructure, then deployed an autonomous multi-agent system from inside that environment — which let requests originate from legitimate-looking IP addresses rather than obviously malicious infrastructure.

The attacker reportedly built the framework using an AI coding chatbot, a set of instructions, and preconfigured Markdown files functioning as operational playbooks — essentially the same "agent skills" pattern legitimate teams use to give an LLM reusable, structured procedures. Per Mandiant's incident-response analysis cited in GTIG's report, the resulting system managed the vulnerability-scanning pipeline, collected credentials, resolved technical problems as they came up, and rotated IP addresses — without a human approving each step. Google says the entire operation, from setup to compromising thousands of third-party credentials, took under six hours.

The part that should worry engineers, specifically

Most public discussion of "agentic security risk" focuses on prompt injection against your own agents, or an assistant being tricked into leaking your data. This is a different and arguably more mundane threat: the same reliability engineering that makes agents useful — self-correction, retries, graceful handling of transient failures — is exactly what makes an attack pipeline resilient enough to run unattended for hours.

A scanning script that dies on the first unexpected HTTP response needs a human to restart it. An agent that "resolves technical problems as they arise" doesn't. That's the entire value proposition of agentic tooling, and it's now showing up on the offensive side at effectively the same maturity level as it shows up in developer tools. There is no special dangerous capability here beyond what a decent coding agent already has — which is precisely the point: the barrier to running a multi-day human-operated campaign as a six-hour autonomous one has dropped to "know how to write agent instructions."

What this changes for teams running agents in cloud environments

If your organization runs agentic coding tools, CI-integrated assistants, or internal automation with cloud credentials in scope, this campaign is a preview of what compromise of that infrastructure looks like from the attacker's side, not just the defender's. A few concrete implications:

Treat agent-accessible credentials as high-value targets, explicitly. If an AI coding tool or CI agent has broad cloud IAM permissions "to be safe," that's now a more attractive target than it was a year ago, because compromising it hands an attacker a ready-made autonomous operator, not just a static credential.
IP-based anomaly detection is weaker than it used to be. Attacks launched from inside compromised legitimate infrastructure won't trip geographic or reputation-based alerts. Detection needs to shift more weight onto behavioral signals — unusual API call sequences, scanning patterns, credential-access velocity — that don't depend on the request's origin looking suspicious.
Markdown-based agent instructions are now a security-relevant artifact. If your org uses "skills" files, playbooks, or reusable prompt templates for internal agents, those same file types deserve the code-review scrutiny you'd give a shell script, because that's functionally what they are.

What we don't know yet

GTIG's report describes the campaign's structure and outcome but, per the available public reporting, doesn't name the specific AI coding chatbot the attacker used, nor does it publish the full Markdown playbooks (for obvious reasons). That means teams can't yet check their own environment against specific indicators of compromise beyond general behavioral patterns — this is a capability disclosure more than an incident-response playbook. Expect more operational detail to surface as other vendors and incident responders corroborate or extend the findings.

Sources

This story was written with the assistance of an AI writing program.