Skyvern 是一款通过 LLM 生成步骤来驱动网页浏览器的自托管 agent，其沙盒逃逸漏洞被分配为 CVE-2026-82447，并于 2026 年 8 月 29 日 15:30:19 UTC 发布到 GitHub Advisory Database。该漏洞所描述的代码修复于 7 月 6 日 21:44:03 UTC 合入仓库，早了 53 天。

漏洞究竟是什么

Skyvern 的 TextPromptBlock 会将每个提示词 渲染两次。第一次按设计通过 Jinja 的 SandboxedEnvironment 进行。第二次则把同一个受攻击者影响的字符串送入一个 未加沙盒 的渲染器，这足以让代码以服务器进程身份执行。修复提交 d723de6 本质上就是一次删除：在 block.py 中 新增三行、删除十一行，去掉了第二次渲染以及向其传递的 parameter_values 参数。其余部分都是测试。

问题出在何种表述上

关于这类通告，常会有两种说法，但在这里都不成立。第一种说法是这是一次 静默 修补。并非如此：7 月 7 日 22:19:18 UTC 发布的 v1.0.45 版本说明里确实包含了 "SSTI" 一词。但这只是约 190 行发布内容中的一条项目，既没有厂商安全通告，当时也没有 CVE，更无法与例行变更日志区分开来。第二种说法暗示，CVE 的年份就能告诉你何时已暴露。事实并非如此——这个 CVE 是由 VulnCheck 作为第三方编号机构提出的，并非由该项目自己提出。

会让工具失灵的部分

该通告记录给出的 CVSS 3.1 评分为 8.8，CVSS 4.0 评分为 8.7，并被归类为 CWE-1336。但其结构化的 vulnerabilities 数组是 空的。受影响范围——0.2.1 至 1.0.45 之前——只存在于 VulnCheck 页面上的文字说明里。任何读取 GitHub 结构化通告数据并据此检查固定版本 skyvern 依赖项的扫描器，都会完全报不出结果。

这种形态为何反复出现

其利用路径并不罕见。工作流参数，或上游区块的输出，都是 agent 自己生成或摄取的文本；它们进入模板渲染器；随后便在 agent 的主机上变成了代码。这就是最直白的提示注入到执行的桥梁，而对于允许模型输出去驱动模板层的工具而言，这种结构性风险始终存在。