AI安全案例分析:Prompts Become Shells —— 从提示词注入到 Agent远程代码执行(RCE)(文末附邀请码)

随着AI Agent框架的快速发展（如微软的Semantic Kernel、ModelScope的MS-Agent等），以大模型为核心的AI系统正在从"对话系统"演进为具备工具调用与自主执行能力的Agent。在这个演进过程中，AI不再只是生成文本，而是具备了文件读取、代码执行、API调用乃至系统命令执行等能力——这使得一个原本属于"语言模型安全问题"的攻击面，升级为"具备执行权限的系统安全问题"。传统的输入过滤与输出审查机制，在这一新范式下几近失效。

2026年，安全研究人员在多个主流AI Agent框架中发现并披露了结构高度相似的执行漏洞：Microsoft Semantic Kernel的CVE-2026-26030与CVE-2026-25592，以及ModelScope MS-Agent的CVE-2026-2256。这些漏洞指向同一个根源：框架对模型输出的过度信任，以及工具执行层缺乏有效隔离。

使用本地模型利用CVE-2026-26030的示意图

在传统大模型应用中，Prompt Injection 的危害止步于内容层；但在 AI Agent 架构下，模型输出会直接驱动工具调用、文件操作乃至 Shell 执行等高权限行为，Prompt 从"输入文本"变成了"执行控制信号"。一旦注入成功影响模型推理，攻击者就能沿着注入 → 推理污染 → 工具调用偏移 → 系统执行的路径，将原本的内容安全问题升级为远程代码执行。

这一威胁真正危险的地方，是攻击者无需任何传统Exploit，并且不依赖内存漏洞、不需要恶意附件，仅凭一条精心构造的Prompt，就能在运行代理的主机上执行任意命令、写入关键目录，乃至获取完整控制权。问题的根源是框架默认将模型输出视为可信意图，直接接入工具调用与系统执行链路，却缺少任何运行时校验——本质上是把高权限执行能力交给了一个可被上下文操纵的概率模型。微软此次披露的两个CVE，正是这一威胁路径在真实框架中的具体体现。

该漏洞存在于 Semantic Kernel Python SDK 的内存向量存储搜索插件中。当用户输入"查找巴黎的酒店"时，AI 模型会调用 search_hotels(city="Paris")，框架将其构造为 lambda 过滤函数并通过 eval() 执行。问题是city 参数由模型控制且未经任何清理，攻击者只需闭合引号并附加恶意代码，即可将数据查询变为可执行载荷。

框架开发者预料到了这一风险，并实现了基于 AST 解析的黑名单验证，仅允许 lambda 表达式、过滤危险标识符（如 eval、exec、__import__）、并在受限 __builtins__ 环境下执行。

然而这套防御最终被绕过。攻击载荷从 tuple() 出发，遍历 Python 类层次结构找到 BuiltinImporter，再动态加载 os 模块调用 system() 执行任意命令。整条链路没有触碰任何被屏蔽的关键词，结构上也是合法的 lambda 表达式，三层防御全部失效。根本问题是黑名单在 Python 这类动态语言中本质上不可穷举，正确做法应是只允许已知安全的 AST 节点类型（白名单），而非试图屏蔽所有危险操作。

SessionsPythonPlugin 是 Semantic Kernel .NET SDK 中负责在 Azure Container Apps 隔离沙箱内执行 Python 代码的组件，沙箱与主机之间有明确的容器边界。为了在沙箱和主机之间传输文件，插件内置了 DownloadFileAsync 和 UploadFileAsync 两个辅助函数——这两个函数从未打算暴露给模型，但 DownloadFileAsync 被意外标注了 [KernelFunction] 属性，加之 localFilePath 参数缺乏路径校验，攻击者得以通过路径遍历将文件写入主机任意位置。

其中ExecuteCode 本身按设计正常运行，沙箱隔离并未失效。攻击链分两步：先通过提示注入让 Agent 在沙箱内用 ExecuteCode 生成恶意脚本，再调用 DownloadFileAsync 将脚本写进主机 Windows 启动目录。下次用户登录时脚本自动执行，主机就此失陷。沙箱逃逸的根源只是一个函数注册到了不该注册的地方，在这整个过程不涉及任何虚拟机层面的漏洞利用。

该漏洞存在于 ModelScope 的 MS-Agent 框架（v1.6.0rc1 及以下版本），CVSS 评分 9.8，由 CERT/CC 于 2026 年 3 月正式披露。MS-Agent 内置 Shell 工具允许代理直接在宿主操作系统上执行命令，漏洞的触发场景极为普遍：当代理被指示处理任何外部内容时——分析文档、总结代码、读取威胁情报——攻击者只需在这些内容中嵌入恶意命令序列，代理就会将其转发给 Shell 工具执行，在主机上运行任意操作系统命令。

框架同样实现了基于正则表达式的黑名单 check_safe() 来过滤危险命令，但被 shell 元字符（;、|、&&、$() 等）重新组织的命令结构直接绕过了所有正则匹配。与 CVE-2026-26030 相比，两个漏洞的防御失效逻辑高度相似：一个用 Python 类型系统绕过 AST 黑名单，一个用 shell 元字符绕过正则黑名单——形式不同，本质相同。不同之处在于 MS-Agent 的攻击入口更隐蔽，攻击者不需要直接与代理对话，只需污染代理会处理的任何外部内容即可。

AI Agent 中 Prompt Injection 导致 RCE 的攻击流程

针对这类风险，单一防护手段已经很难解决问题，需要从架构设计到运行时构建多层安全边界。

架构层：收窄攻击面

Agent 的工具权限应遵循最小权限原则，Shell 执行、文件写入、代码运行等高风险能力不应默认开放。每一个注册给模型的函数都构成潜在攻击面，工具暴露范围直接决定了攻击者的操作空间。CVE-2026-25592 的问题根源不在于沙箱设计本身，而在于一个误标注的 [KernelFunction] 将文件写入能力意外暴露给了模型，沙箱隔离就此失效。

验证层：不信任模型输出

Tool Calling、参数生成与任务编排环节须引入策略校验与运行时验证，打破"LLM Output = Trusted Intent"的默认假设。对于涉及代码执行的输入验证，应采用白名单而非黑名单——CVE-2026-26030 已经证明，在 Python 这类动态语言中试图枚举所有危险操作是徒劳的。

运行层：隔离与兜底

对用户输入、RAG 内容、网页数据、OCR/ASR 结果等外部来源建立上下文隔离与注入检测，防止污染数据进入 Agent 规划逻辑。对 Shell 执行、文件写入、凭据访问等高风险操作引入 Human-in-the-Loop 审批机制，确保模型无法自主完成危险行为。

[1] https://www.microsoft.com/en-us/security/blog/2026/05/07/prompts-become-shells-rce-vulnerabilities-ai-agent-frameworks/

[2] https://medium.com/@itamar.yochpaz/cve-2026-2256-from-ai-prompt-to-full-system-compromise-a4114c718326

本期附赠 10 个社区邀请码（先到先得）：

4YE5BGLHKRE4TVZ37UETNFBKFY30NWQA

P0FO3W9L6YJE2XB69QTHE401MZ9IE55I

G0JFKLE9K8XWZMLVT960657Q1JM3US07

FLEQCMJWVB287KG8SQPGDV5EVNGQSGEP

YQP5SO0MYSALXB04CX3EWV10JEFD186N

EJ4T2JJFOI4JHRH3AB5U30NOJ7GOM7NB

ED2LUNRIWN6PA1TP2DXS1QFGSKSHEQVI

SAXFUHED6OQ17QGTIA53FD4P4FZ5HZ17

QE3CFR973K7D7VXFMMFHV7CHAJCM3VP1

RTAAGTJD4AQCNMJKDSBR6VC8O6IJACFO