【AI安全】生成式 UI 沙箱的宿主权限越界分析

本文内容仅供技术学习与交流使用，严禁用于任何非法用途。请遵守《中华人民共和国网络安全法》等相关法律法规，因违规使用产生的一切后果，由使用者自行承担，与作者无关。 一、引言 随着 AI Agent 逐渐具备代码生成与工具执行能力，越来越多的应用开始采用生成式 UI（Generative UI）技术，由大模型动态生成 Python 代码，并通过沙箱执行后构建交互界面。这种方式提高了应用的灵活性，同时也对不可信代码的执行隔离提出了更高要求。 目前，WebAssembly（WASM）已被应用于部分 AI 代码执行场景，通过独立运行环境和虚拟文件系统限制代码对宿主资源的访问。但 当沙箱内部的代码能够通过跨语言接口调用宿主运行时 API 时，原有的权限隔离可能失效 ，本文以 Prefab UI 为研究对象，结合实际执行链、漏洞复现和源码分析， 还原从 Pyodide 沙箱到 Deno 宿主文件系统的权限越界过程 ，并分析漏洞成因、实际危害及修复机制，为同类 Agent 代码执行环境的安全评估提供参考。 二、Prefab UI 的代码执行机制 2.1 生成式 UI 的执行流程 Prefab UI 是一个基于 Python 的组件化 UI 框架，支持通过 Python 代码构造文本、图表、表格及交互组件。 在传统的开发模式下，界面代码由开发者编写，随后经过测试和部署。而在 Generative UI 场景中，代码由大模型根据用户需求实时生成。 例如，模型可以生成： from prefab_ui.components import Text view = Text("Hello, Generative UI") 这段代码在执行后会产生一个 Prefab 组件，服务端将组件信息转换为结构化数据，再由客户端完成渲染。 当 Prefab UI 与 FastMCP 结合时，可以通过 GenerativeUI Provider 注册生成式 UI 工具。 对应的执行流程为： 这里存在一个重要区别：FastMCP 的 generate_prefab_ui 工具接收的不是组件配置，而是可以被 Python 解释器执行的源代码。 因此，服务端需要允许代码执行，但又不能让这段代码直接获得服务器的文件系统和网络权限。 Prefab UI 选择使用 Pyodide 承载这部分执行任务。 2.2 Pyodide 与 Deno 的运行环境 Pyodide 是基于 WebAssembly 的 Python 运行环境，可在 JavaScript Runtime 中运行 CPython 及相关 Python 包。Prefab UI 的生成式执行器并非为每次请求创建独立容器或虚拟机，而是由 Python 服务进程启动 Deno 子进程，在 Deno 中运行 runner.js 并加载 Pyodide。 其运行结构如下： 宿主操作系统 │ ├── Python 服务进程 │ ├── FastMCP Server │ ├── GenerativeUI Provider │ └── PyodideSandbox │ └── Deno 子进程 └── runner.js └── Pyodide ├── Python Interpreter ├── Emscripten Virtual FS ├── Prefab Python Components └── 模型生成的 Python 代码 Pyodide 内部的常规 Python 文件操作默认作用于 Emscripten 虚拟文件系统；Deno 则作为真实的操作系统进程，提供受其自身权限机制及操作系统访问控制约束的文件、网络等原生 API。这两层运行环境并不天然共享同一套文件访问边界。 同时，Pyodide 支持 Python 与 JavaScript 的互操作。若不可信 Python 能访问 Deno 暴露的全局对象，执行器就需要确保这些对象不会向其传递超出预期的宿主权限。 2.3 漏洞影响范围 根据 JFrog 的公开公告，CVE-2026-120338 影响 Prefab UI 0.14.0 至 0.21.0 之前的版本。 项目 信息 漏洞编号 CVE-2026-120338 组件 prefab-ui 漏洞类型 宿主文件访问权限越界 受影响版本 >=0.14.0, <0.21.0 公开验证版本 0.20.2 修复版本 0.21.0 修复 PR PrefectHQ/prefab#538 漏洞披露时间 2026 年 11 月 1 日 漏洞发现者 JFrog Security Research / Yuval Moravchick 该漏洞并不是安装 Prefab UI 后就能够直接利用。 攻击需要服务端启用相关 Generative UI 功能，并且安装 Deno，使外部提交的 Python 代码能够进入受影响的 Pyodide 执行器。 如果服务端没有启用对应执行入口，则这条攻击路径并不存在。 对于已经启用该功能的服务，攻击者还需要能够调用相关 MCP 工具。在未配置认证的 FastMCP 服务中，可访问该服务的客户端可能直接调用工具；如果配置了认证和权限控制，则需要具备对应工具调用权限。 此外，Deno 对宿主文件的访问仍受到操作系统权限限制。 例如，Deno 进程以普通用户身份运行时，并不能仅凭 --allow-write 修改当前账户无权写入的 root 所有文件。 因此，不能把本漏洞直接等同于系统提权或容器逃逸。 三、Pyodide 与 Deno 的文件访问边界 3.1 Pyodide 虚拟文件系统 在 Prefab UI 的默认执行环境中，Pyodide 通过 Emscripten 虚拟文件系统承载 Python 的常规文件操作。代码使用 open() 或 pathlib 创建的文件，默认保存在 Pyodide 内部的文件空间中，并不会自动映射为宿主操作系统的同名文件。 例如，在 Pyodide 中写入 /tmp/demo.txt ，并不意味着 Deno 所在操作系统的 /tmp/demo.txt 也被创建。两者虽然可能具有相同的路径字符串，但对应的文件系统不同。 Pyodide 也支持额外的文件系统挂载和桥接机制，因此上述结论以执行器未将目标路径显式映射到宿主文件系统为前提。第四章将通过实际文件检查验证这一默认行为。 3.2 JavaScript 桥接 Pyodide 提供 js 模块，使 Python 能够访问承载它的 JavaScript 运行时中的全局对象。运行于 Deno 内部时，Python 可以通过该桥接接口获取 Deno 全局对象，例如： import js js.Deno 与 pathlib 等 Python 文件 API 不同， js.Deno.readTextFileSync() 和 js.Deno.writeTextFileSync() 调用的是 Deno 的原生文件接口。其最终文件操作对象是 Deno 进程可见的文件系统，而非 Pyodide 默认的虚拟文件系统。 两条访问路径的差异如下图所示： 因此， import js 本身不等于越权；能否真正读写宿主文件，还