CVE-2026-26030 Critical RCE in Semantic Kernel Python SDK InMemoryVectorStore Filter

A critical remote code execution flaw in Microsoft’s Semantic Kernel Python SDK — tracked as CVE-2026-26030 — allows specially crafted filter expressions in the InMemoryVectorStore component to execute arbitrary Python code, exposing applications that use the SDK to full system compromise unless mitigated or updated. (github.com) (nvd.nist.gov)

Background / Overview​

Microsoft’s Semantic Kernel is an SDK used by developers to orchestrate LLMs, build agentic workflows, and maintain memory stores for AI assistants. One of the provided memory backends, InMemoryVectorStore, supports a filter capability that evaluates expressions to narrow returned memory items. That evaluation mechanism is where the vulnerability lies: untrusted or insufficiently restricted expressions can be used to inject and execute arbitrary code. The issue was assigned CVE‑2026‑26030 and published by GitHub; Microsoft’s advisory and the NVD entry confirm the defect, affected versions, and the remedial release. (github.com) (nvd.nist.gov)
This article explains what the vulnerability is, why it matters for AI applications and enterprise deployments, how the upstream patch addresses the problem, practical mitigations if you cannot upgrade immediately, and longer-tedations for teams building on Semantic Kernel. For record-keeping and cross-checking I reviewed public advisories, the upstream pull request that implements the change, and curated vulnerability trackers. (github.com) (github.com)

---

What exactly is CVE‑2026‑26030?​

The technical synopsis​

• The vulnerability is an improper control of code generation / code injection (CWE‑94): filter expressions passed to the InMemoryVectorStore are interpreted in a way that allows execution of arbitrary Python code when an attacker can supply or influence the expression. (github.com)
• Affected SK versions are all releases prior to 1.39.4; the defect is fixed in the python-1.39.4 release. (nvd.nist.gov)
• The Canonical GitHub advisory rates the issue as Critical with a CVSS-based score at the very top (reported as 10.0 in the advisory; NVD shows an equivalent critical rating with GitHub’s CVSS vector). The published CVSS vector indicates: network attack vector, low attack complexity, low privileges required, no user interaction, and a changed scope (indicating the attacker-controlled code can affect components beyond the initial vulnerable module). (github.com)

How the vulnerability is triggered​

At a high level, the memory store’s filter feature accepts logical expressions intended to be evaluated against stored memory item attributes. Implementation details in earlier versions allowed attribute resolution and expression evaluation in an unsafe manner so that crafted expressions could reach into Python internals or call sensitive functions (for example, by referencing dunder attributes, builtins, or standard library modules). When those expressions are evaluated without strict sandboxing or a rigorous whitelist, they become a vehicle for executing arbitrary code in the process hosting the Semantic Kernel instance. The upstream PR and advisory explicitly cite dangerous attribute access as the core problem and the focus of the remedial code changes. (github.com)

---

Impact: who and what is at risk​

Developer and deployment contexts that matter​

• Single-tenant developer environments: local development notebooks and test harnesses running Semantic Kernel with InMemoryVectorStore can be fully compromised if an attacker can coerce the application into evaluating an attacker-controlled filter (for example, via a hosted demo or shared notebooks).
• Web services and APIs: services that expose API endpoints accepting filter expressions, or that incorporate user-supplied metadata into filters, are especially high-risk. The CVSS factors (network vector, low privileges) mean an attacker interacting over the network can potentially exploit the flaw. (github.com)
• Agentic systems and LLM orchestrations: Semantic Kernel is commonly used to orchestrate LLMs, chain reasoning, and persist agent memory. If memory filtering can be abused to execute code, compromised agents can pivot to exfiltrate secrets, modify files, spawn processes, or run arbitrary payloads—a catastrophic outcome for any system that stores secrets, has network access to internal resources, or uses managed credentials. (nvd.nist.gov)
• Supply-chain and downstream libraries: third-party packages and internal components that embed Semantic Kernel may inherit this vulnerability. Scanning and dependency management systems should flag any usage of vulnerable SK versions. (advisories.gitlab.com)

Realistic threat scenarios​

• A malicious user uploads or injects a crafted filter into an AI assistant’s memory query endpoint. The server evaluates it and the attacker achieves RCE, then uses the server host to pivot within the environment.
• A CI/CD pipeline step that runs Semantic Kernel for integration tests evaluates a malicious expression embedded in test data, corrupting build artifacts or stealing pipeline secrets.
• A compromised developer laptop running vulnerable SK code in a shared network can be used as a beachhead for lateral movement once the attacker obtains code execution.

---

Upstream fixes and what changed in python‑1.39.4​

Microsoft’s team merged a targeted pull request that refines the filtering logic to block dangerous attribute names and otherwise restrict what filter expressions can access. The release notes and PR emphasize preventing untrusted attribute resolution instead of relying on generic deny-lists. The patch focuses on preventing the filter evaluation code path from resolving attributes that would allow access to Python internals or standard library functions that perform I/O or process execution. (github.com)
Key points from the upstream work:

• Explicit blocking of dangerous attribute names rather than only attempting to sanitize expressions post hoc. That reduces the attack surface by removing direct paths to critical objects.
• Unit tests and coverage for in-memory filter logic were added and updated as part of the PR, indicating the maintainers realized the evaluation layer needed explicit safeguards. (github.com)
• The GitHub security advisory and NVD entry incorporate the fix, and both list the patch release (python-1.39.4) as the remediation. (github.com)

---

Immediate mitigation: what to do right now (ordered)​

• Upgrade to python‑1.39.4 or later. This is the vendor-provided fix and should be treated as the highest-priority action. If you have automated dependency updates or a centralized package management flow, push the update immediately and validate your test suite against the new release. (github.com)
• If you cannot upgrade immediately — stop using InMemoryVectorStore in production. The advisory explicitly recommends avoiding InMemoryVectorStore for production scenarios until you can patch. Replace it with alternative, safer storage backends or disable API paths that accept user-controlled filter expressions. (github.com)
• Block untrusted inputs. Ensure any API or UI that can influence filter expressions is disabled or placed behind strict authentication and input validation. Treat inputs as hostile by default.
• Apply runtime hardening:
• Run Semantic Kernel processes under dedicated, unprivileged service accounts.
• Use OS-level sandboxing (containers, seccomp, AppArmor, SELinux) to limit what a compromised process can read, write, or execute.
• Limit network egress from hosts running Semantic Kernel so successful exploitation cannot easily reach external C2 or cloud credential endpoints.
• Rotate credentials and secrets that might have been accessible from hosts running vulnerable versions, if you suspect an exploit attempt or unexpected behavior prior to patching.
• Monitor and hunt: add detection for suspicious process creation, unusual Python subprocess invocations, unexpected file writes, or anomalous network connections originating from nodes that host Semantic Kernel. Log and retain filter inputs where possible for forensic review.

These steps prioritize speed and containment: upgrading is the primary fix; the others reduce exposure while patches are staged and rolled out.

---

Developer-level hardening: code and design recommendations​

• Prefer safe expression evaluators: avoid direct use of Python eval or brittle attribute resolution. If you must support expression evaluation, use a well-maintained sandboxed expression engine or a purpose-built domain-specific language (DSL) that only exposes a minimal safe subset of operations.
• Whitelist, don’t blacklist: denylists for “dangerous names” are fragile and easy to bypass. Implement whitelists of allowed attributes and operations when evaluating user-supplied filters. The upstream fix moves in that direction by blocking known dangerous attribute names, but your application should favor explicit whitelists for business-meaningful fields.
• Tokenize and parse expressions: use an AST-based parser that inspects expressions before evaluation and rejects constructs that attempt attribute traversal, attribute access to dunder names, or module imports.
• Run evaluation in a dedicated, minimal-privilege worker: even with safeguards, evaluate expressions in a separate process with minimal rights; if the process is compromised, the blast radius is limited.
• Code reviews & security tests: add fuzzing and property-based tests that feed malformed or malicious expressions into your filter layer during CI to detect weaknesses early.

---

Detection and forensic guidance​

• Collect and centralize logs that include: request context for filter evaluation, the raw filter expressions (carefully consider privacy/security of storing expressions), and execution traces from the Semantic Kernel runtime.
• Create monitoring alerts for:
• Unexpected process spawns by the application (shell, python child processes).
• File writes to sensitive directories from the SK host.
• Network connections to unusual endpoints from the SK host.
• If you detect a suspected compromise:
• Isolate the host immediately (network segmentation).
• Preserve volatile memory and logs for analysis.
• Rotate any credentials that resided on the host or could be accessed from the host (service principals, API keys, tokens).
• Rebuild from known-good sources after forensic clearance.

---

Why this bug is especially dangerous for AI systems​

AI agent frameworks and orchestration SDKs like Semantic Kernel are designed to accept and transform data from many sources — user prompts, agent outputs, stored memory items. That flexibility amplifies the consequences of an evaluation-sandbox failure:

• Memory poisoning: an attacker can weaponize the memory layer itself, hiding malicious payloads inside memory entries that are later evaluated by other agents or processes.
• Chaining attacks: once code execution is achieved, adversaries can instruct the agent to perform actions on behalf of the compromised environment, leading to data exfiltration or lateral movement.
• Trusted-relationship abuse: many deployments run SK near valuable resources (cloud credentials, token caches); attacker-controlled code can exploit implicit trust relationships.

For these reasons, CVE‑2026‑26030 is more than a library bug — it’s a systems design hazard for agentic deployments unless mitigated by architecture and runtime controls. (github.com)

---

Assessing exploitability and scope​

Public advisories indicate the flaw is practical to exploit and assign it a critical severity. The NVD and GitHub advisory note that the vulnerability exists in versions prior to 1.39.4 and that the patch addresses attribute access controls; both point to an exploit vector usable over the network with relatively low privilege requirements. Administrators should therefore assume practical exploitability in real-world scenarios that accept external filter inputs. (nvd.nist.gov)
Note: as with many advisories, exploit PoCs may or may not be public. Do not delay remediation pending public exploit code; treat the existence of a CVE and an actionable attack surface as reason to patch or mitigate immediately.

---

How to validate you’re no longer vulnerable (checks and tests)​

• Dependency check: confirm installed version:
• Example: run your package manager to verify the installed semantic-kernel version and ensure it is >= 1.39.4.
• Unit tests: exercise all code paths that construct filter expressions; add tests that intentionally attempt to access blocked attributes to verify the patch behavior.
• Static scan: run dependency scanning tools and SBOM inventory checks across your environments to find any runtime images that include semantic-kernel < 1.39.4. (advisories.gitlab.com)
• Runtime test harness: in staging, attempt to run known-bad filter patterns (in a controlled, isolated lab) to verify the server rejects or sanitizes the expression rather than executing it.

---

Long-term lessons for teams building with LLM orchestration SDKs​

• Treat any evaluation or templating feature that can access runtime attributes as a potentially dangerous capability. Design such features with explicit whitelists, dedicated runtimes, and limited privileges.
• Security reviews for AI orchestration tooling must prioritize evaluation semantics: how expressions are parsed, what attribute resolution permits, and whether any path allows escape into Python internals or the OS.
• Invest in automated dependency tracking and rapid patch deployment for AI SDKs. The pace of change in AI libraries is fast; having an automated path to validate and roll out security fixes reduces exposure.
• Signal-risk to product and security stakeholders: these vulnerabilities are not theoretical coding mistakes — they are systemic risks that can transform benign agent features into remote code execution vectors.

---

Executive summary and recommended action list​

• CVE‑2026‑26030 is a critical remote code execution vulnerability in the Microsoft Semantic Kernel Python SDK’s InMemoryVectorStore filter functionality. Affected versions are prior to 1.39.4; the fix is in python‑1.39.4. (nvd.nist.gov)
• Immediate actions (highest priority):
• Upgrade deployments to semantic-kernel python‑1.39.4 or higher as soon as possible. (github.com)
• If you cannot upgrade immediately, disable or avoid InMemoryVectorStore in production and block any external inputs that could be treated as filter expressions. (github.com)
• Apply runtime containment: unprivileged service accounts, sandboxing, network egress restrictions, and credential rotation where exposure is suspected.
• Developer hardening:
• Use whitelist-based expression evaluation, or eliminate dynamic evaluation entirely in favor of explicit filter APIs.
• Add tests and fuzzing for filter input handling.
• Detection & recovery:
• Monitor for anomalous process execution and network egress from SK hosts.
• Prepare forensic playbooks and isolate hosts on detection.

---

Final analysis: strengths of the fix and residual risks​

The upstream response is appropriate: the maintainers introduced focused changes to block dangerous attribute names and tightened unit tests and coverage for the in-memory filter logic. That is a pragmatic fix addressing the immediate attack vector while preserving useful filter functionality for trusted scenarios. (github.com)
However, residual risk remains in two areas:

• Legacy deployments and blind upgrade windows: organizations with slow patch cycles, unmanaged images, or embedded uses of Semantic Kernel may continue running vulnerable versions. These environments are the highest priority for triage and remediation. (advisories.gitlab.com)
• Design fragility: expression evaluation in dynamic languages is intrinsically risky. Blocking dangerous attributes is a concrete improvement but does not substitute for architectural controls like process isolation and whitelisting in business-critical systems.

Treat the release and advisory as a prompt for both immediate patching and a longer-term architecture review: once a single component in the orchestration stack can run arbitrary code, the entire orchestration model must be examined for trust boundaries.

---

In closing: CVE‑2026‑26030 is an urgent, high‑impact vulnerability for any team using Semantic Kernel’s Python SDK in production. The correct first move is to upgrade to the patched python‑1.39.4 release; the correct second move is to audit your design to remove any places where untrusted input can be interpreted as executable logic. Public advisories and the upstream PR provide the technical details you need to triage and fix systems. (github.com)

---

Source: MSRC Security Update Guide - Microsoft Security Response Center