CVE-2026-26030：提示注入在 Microsoft Semantic Kernel 中演变为 RCE

这是什么？

2026 年 5 月 7 日，微软 Defender 安全研究团队（Uri Oren、Amit Eliahu、Dor Edry）发布了 《When prompts become shells》，记录了 Microsoft Semantic Kernel 中的两个严重漏洞——这是微软的开源智能体框架，在 GitHub 上获得超过 27,000 颗星，与 Copilot Studio 同源。这两个漏洞 CVE-2026-26030（Python SDK）和 CVE-2026-25592（.NET SDK）可将普通的提示注入转化为在托管智能体的主机上远程执行代码。NVD 条目 将 CVE-2026-26030 评为 CVSS 9.8。两者均已通过负责任披露报告给 MSRC，并在发布当天修复。

其教训是结构性的，而非偶然：一旦模型连接到工具，「内容问题」与「执行原语」之间的边界就消失了。模型完全按其设计行事——把语言翻译成工具调用。漏洞在于框架如何信任被解析出的参数。

工作原理

CVE-2026-26030 —— eval() 接收点（Python）。 Semantic Kernel 默认的内存向量存储将其过滤器构造为 Python lambda，并通过 eval() 执行。对于酒店搜索智能体，像 「查找巴黎的酒店」 这样的查询会变成 lambda x: x.city == 'Paris'。city 的取值由模型控制且未经净化——这是一个经典的注入接收点。通过闭合引号并附加 Python 代码，攻击者可以跳出字符串。框架曾预见此风险，加入了基于 AST 的黑名单，拒绝 eval、exec、open、__import__ 等名称并清空 __builtins__。微软证明该黑名单可被绕过：包裹在合法 lambda 中的载荷可以通过结构检查，并且不使用被禁名称，而是遍历 Python 的类层次结构（经由 tuple、__class__、__subclasses__、BuiltinImporter）抵达 os.system——这些都不在名单上。此处不复现任何可用载荷；不复现也足以说明教训。

CVE-2026-25592 —— 被过度暴露的工具（.NET）。 SessionsPythonPlugin 在隔离的 Azure Container Apps 沙箱中运行模型生成的代码。但 DownloadFileAsync——一个主机侧函数——被错误地标注为 [KernelFunction]，从而作为可调用工具暴露给模型。其 localFilePath 参数决定 File.WriteAllBytes() 在主机上的写入位置，因此被模型控制，且没有路径校验。把「在沙箱中写入载荷」与「将其下载到主机的启动文件夹」串联起来，便可在下次登录时从沙箱逃逸为完整的 RCE。微软将该链条对应到 MITRE ATLAS AML.T0051（LLM 提示注入）级联到 AML.T0016（获取能力）。

为什么重要

两个漏洞都源于同一个架构错误：对由模型路由的输入信任得太深，以至于它能抵达代码求值或文件系统原语。当检索为工具参数提供输入、而工具参数又喂给解释器时，被检索内容与可执行代码之间的边界便消解了——而位于智能体运行时之外的传统输入净化，永远看不到该载荷。

影响面很广。Semantic Kernel 支撑着 Azure 上的生产级 RAG 应用、Microsoft 365 Copilot 场景，以及受监管行业中大量内部自动化的长尾。对于 CVE-2026-26030，唯一前提是攻击者可影响的字段能进入索引——共享语料库中的单个被投毒文档，就可能波及所有下游查询它的智能体。正如微软直言：你的 LLM 不是安全边界；你所暴露的工具定义了攻击者的作用范围。

防御

• 立即打补丁。 将 Python semantic-kernel 包升级到 1.39.4+，将 .NET SDK 升级到 1.71.0+。无需重写智能体——修复会移除模型自主触发这些函数的能力。
• 在代码求值接收点用白名单而非黑名单。 Semantic Kernel 的修复用一个 AST 节点类型白名单、调用白名单、层次遍历属性黑名单（__class__、__subclasses__）以及名称限制，取代了脆弱的黑名单。在动态语言中，禁止危险标记在结构上是必败的；只有显式允许安全构造才站得住。
• 将模型可影响的每个工具参数都视为不可信输入。 校验并规范化文件路径（Path.GetFullPath() 加上目录白名单），对查询使用参数化，绝不要把模型输出插入 eval/exec/模板化代码。
• 不要把危险的辅助函数暴露为工具。 审计哪些函数带有 [KernelFunction] / 工具模式注解。主机侧的文件、进程和网络辅助函数应当只能由你的代码调用，而绝不应由模型调用——参见工具描述投毒这一未被测试的攻击面。
• 也要在主机层防御。 由于模型护栏可能被绕过，应将模型层信号与端点遥测关联起来：一个智能体主机进程突然启动 cmd.exe/powershell.exe，或向启动文件夹投放文件，都是强烈的后渗透信号。微软为此专门发布了高级猎杀查询。
• 对智能体施加最小权限。 智能体的二选一规则与按工具的最小权限，可限制一次成功注入所能触及的范围。

状态

项目	详情
CVE	CVE-2026-26030（Python），CVE-2026-25592（.NET）
组件	Semantic Kernel —— 内存向量存储过滤器；SessionsPythonPlugin
类别	提示注入 → eval() 接收点 RCE；过度暴露的工具 → 主机文件写入 / 沙箱逃逸
CVSS	9.8（CVE-2026-26030，NVD）
受影响	Python semantic-kernel < 1.39.4；.NET SDK < 1.71.0
修复版本	Python 1.39.4；.NET 1.71.0
披露	经 MSRC 协调；在发布当天修复（2026 年 5 月 7 日）
在野利用	微软提供可复现 PoC；披露时未确认野外活动

这其实不算「Semantic Kernel 的一个漏洞」。它是智能体时代对一条古老 Web 安全教训的重述：不可信输入绝不能在无中介的情况下抵达高风险操作。在 2000 年代，这类输入进入 SQL 查询和 shell 调用；如今它以自然语言到来，被解析为工具参数，最终落入解释器。微软已表示这一研究系列的后续将覆盖其他被广泛使用的框架中结构相同的执行漏洞——因此应把它当作一类问题，而非孤例，并假定任何把模型输出映射到系统工具的框架都具有相同的形态。