Semantic Kernel ran a model-controlled search filter through eval() at query time

Text interpolated into a Python lambda is code. According to Microsoft's account, relayed in a dev.to writeup of the disclosure, the filter parameters passed to an `InMemoryVectorStore` search can include model-controlled input. That input was not sanitized before it went into the expression that `eval()` then ran ^[4].

There was a blocklist, meant to catch dangerous constructs ^[5]. It was bypassed by walking Python's class hierarchy, reaching dangerous built-ins through an indirect attribute-access path instead of referencing them directly ^[6].

The .NET side took no interpreter trick, just one attribute making the whole exposure decision. `DownloadFileAsync` on `SessionsPythonPlugin` carried a `[KernelFunction]` attribute, the standard way Semantic Kernel marks a method callable by the agent, and it did not validate the destination path ^[9].

The Startup folder is what makes that write outlive the request. A file there runs automatically at the next user login ^[11]. The writeup argues that a container's sandbox isolation typically does not extend to filesystem locations mounted or shared with the host, so execution from Startup triggers outside the container at the next host login ^[12]. For that to transfer to your deployment, the agent's container needs a writable mount that reaches the host profile directory. Without one, the same write lands inside the sandbox and goes away with it.

Upgrading to `semantic-kernel` 1.39.4 for Python ^[8] and the .NET SDK 1.71.0 ^[13] fixes these two call sites. The methods you marked callable in your own plugin classes are still on you. The writeup's first recommendation is to take each one and ask what happens if the model calls it with the worst possible string ^[16].

Both bugs are described in the writeup as the same mistake. A code-adjacent primitive, `eval()` in one case and unrestricted file I/O in the other, received a value that traced back to model output, and nobody treated that value as attacker-controlled ^[14]. Model output is attacker-controlled the moment the model has processed untrusted content, including a scraped webpage, a user-supplied document, retrieved search results or another agent's message ^[15]. The writeup asks for two remedies. One is a small explicit filter grammar you parse and validate instead of `eval()` or `exec()` ^[17]. The other is file paths checked against a canonicalized allowlist of directories rather than a blocklist of bad patterns ^[18].