Sandbox Escape（沙箱逃逸）

编码智能体属于高价值目标，原因与它有用的原因相同：它握着一个 shell。它读写源码树、运行构建与测试命令，并以启动它的开发者的环境权限运行——这个权限范围内通常包括 SSH 密钥、云凭据、包仓库令牌与内网可达系统。正因如此，主流编码智能体普遍引入操作系统级隔离：Linux 上的 bubblewrap 与 Landlock、macOS 上的 Seatbelt，或为每个智能体单独分配一台轻量虚拟机。

需要先明确这层隔离的定位。据 Docker 在其安全公告中的表述，虚拟机边界是隔离控制项本身，而不是虚拟机内部的权限隔离——也就是说，虚拟机里的智能体、它安装的包、它以 sudo 运行的命令，都被假定为敌意。这一定位决定了评估方式：沙箱的质量不由「配置得多严」来衡量，而由「隔离实现本身是否可信」来衡量。

当隔离层自己写错时，一次调用就足以越界。DeepSeek Harness 的 CVE-2026-82533 是其中叙事较完整的案例。据 OX Security 的披露与复现记录，该工具把智能体控制 API 暴露在本机 HTTP 端口（127.0.0.1:3080）上且不做认证，仅凭客户端提供的 Host 请求头判断请求是否可信，而从未校验连接的实际对端地址；其代码注释显示这一检查原本用于防御 DNS 重绑定类攻击。同时，产品默认的沙箱限制文件写入，却让回环网络保持开放，普通 shell 调用也不需要审批。两个条件叠加后，沙箱内的智能体只需执行一条 curl 命令调用自家未认证 API，即可把会话提升为 danger-full-access 且审批设为 never，此后每条命令都在无隔离、无提示的状态下运行。

该漏洞被归为 CWE-807（在安全决策中依赖不可信输入），CVSS 评分 9.4。时间线为：2026 年 8 月 24 日确认并提交 VulnCheck，8 月 27 日在 0.1.2-alpha.1 修复，8 月 30 日复测确认，9 月 8 日 CVE 公开发布。研究人员同时验证了第二条路径：一旦该端口通过隧道、反向代理、SSH 转发或编辑器端口转发可达，未认证的远程攻击者无需 API key 或模型调用即可接管智能体，并导出全部已存会话。

Docker Sandboxes 的两个漏洞说明的是另一类实现失误。据 Docker 2026 年 9 月的安全公告，CVE-2026-77179（CVSS 9.4）位于 virtio-fs 主机侧服务：在重新打开已删除文件时按存储路径跟随符号链接，guest 内代码可以替换父目录为符号链接从而跳出共享工作区，以虚拟机监视器所在的宿主账号权限读写任意文件，Docker 描述其可能进一步导致宿主代码执行。CVE-2026-79994（CVSS 8.7）位于 Unix domain socket 转发：转发通道先校验 socket 路径在工作区内、随后按名称重连，检查与连接之间被替换为符号链接即可触及工作区外的 socket。两者影响 0.28.0 至 0.41.9（macOS），已在 2026 年 9 月 7 日发布的 0.42.0 修复；截至 9 月中旬的公开记录，尚无在野利用证据，也未进入已知被利用漏洞目录。

更值得警惕的是不需要任何实现缺陷的那条路径。据 CybeDefend 汇总的 Pillar Security 研究成果，研究团队在数月内于 Cursor、OpenAI Codex CLI、Google Gemini CLI 与 Antigravity 四款主流编码智能体上复现了 7 处沙箱逃逸。其中多数案例里，智能体没有离开边界，也没有违反任何一条规则：它只是写了一个文件——一个 hook 配置、一个虚拟环境解释器、一条 Git 配置、一个任务定义——而边界之外的某个受信任进程在其回合结束后读取并执行了这个文件。

Cloud Security Alliance 在 2026 年 7 月 22 日的研究简报中为这一模式命名：Trust Handoff Flaw（信任交接缺陷）——智能体待在盒子里、遵守全部规则，却写入了会被盒外未隔离工具在事后消费的文件。它的定义把安全边界从「一处可配置的位置」移到了「一组未必被盘点过的关系」：开发者机器上那些会读取项目内文件并据此行动、且不会就此征询的程序集合。

该简报同时归纳了沙箱设计中被反复验证失效的四类假设，其本质是设计错误而非偶发 bug：拒绝清单的缝隙（用列举禁止项的方式写策略，要求作者完整枚举操作系统能力，而没有人做到过）、对路径规则的信任（非标准 Git 目录即可绕过路径限制）、按名称而非按参数判定（命令允许清单信任命令名，忽略参数）、把写入权等同于安全（默认智能体可以写自己工作区的全部内容）。逐条看下来，7 处逃逸中有 4 处的成因是一段写入，而不是一次突破。

沙箱逃逸的严重性来自权限继承：逃逸后的进程通常以启动虚拟机的宿主账号权限运行。如果开发者用日常登录账号启动沙箱，那么 SSH 密钥、云平台凭据、密码库都在射程内。研究者给出的对策方向也由此展开——为虚拟机监视器分配最小权限的专用账号，并让长期有效的密钥远离共享工作区。

第二个容易被低估的点是逃逸不需要远程暴露。CVE-2026-82533 的复现是在默认配置、无网络暴露、无凭据的条件下完成的，前提只是智能体执行了一段由攻击者文本诱导的命令——而这恰恰是沙箱存在的理由：处理不可信内容。反过来，如果本地端口因任何原因对外可达，风险会从「智能体自己越界」升级为「外部攻击者直接接管」。

第三个判断维度是已被利用与否。截至 2026 年 9 月中旬的公开记录，上述漏洞均未出现真实在野利用证据。这不意味着风险可以下调：编码智能体天然处理不可信输入、安装第三方包、运行生成的代码，正好构成这些漏洞所假设的敌意 guest；从漏洞公开到被自动化利用的窗口，在传统企业软件上已压缩到很短，而智能体运行时可被诱导执行命令，等于缩短了利用链的一环。

把上述案例转成可执行动作，可归纳为几条：

补齐网络命名空间隔离。文件写入受限不等于隔离成立，沙箱应默认不共享宿主网络命名空间，并禁止访问本机管理端口。

对本地控制接口做真实认证。以对端地址、令牌或进程凭证判定可信，而不是依赖请求头；本地端口不应被视为可信边界。

把「智能体能写什么」当作首要问题。在给定隔离强度之前，先界定写入范围，并盘点哪些未隔离进程会读取项目内文件并据此执行——hook、任务定义、解释器路径、Git 配置都在此列。用允许清单替代拒绝清单。

让审批与策略不可被智能体自身改写。工具权限变更必须来自人类可控的通道，并在日志中区分来源是人还是智能体。CVE-2026-82533 中策略变更被记录为 source: user，正是这一区分缺失的后果。

以最小权限账号运行沙箱宿主，并保持宿主密钥与工作区分离；同时把版本跟进纳入例行流程，因为这类修复通常以小版本形式发布。

沙箱逃逸的攻防重心正在从「突破隔离」转向「滥用信任关系」。这意味着两个方向的投入会同步上升：一是运行时的边界定义，从文件系统隔离扩展到写入物审计与盒外消费链的可见性；二是权限语义的显式化，宿主账号、可写范围与外部可达性有望进入统一的声明式描述。目前官方及行业暂未披露更多细节，后续将持续跟进迭代动态。