一个 9.8 分的漏洞，描述却只有一句话
9 月 5 日，两份 CVSS 3.1 评分均为 9.8 的漏洞记录在同一天早晨出现，间隔仅两秒。它们来自两个开源智能体沙箱项目：一个是 Cua 的 computer-server，另一个是 AutoAgent 的沙箱 TCP 服务。两份记录可以浓缩成同一句工程上的大白话：沙箱在所有网络接口上监听，并接收任何连上来的连接发来的指令。
AutoAgent 是香港大学 HKUDS 团队开源的智能体框架。它的沙箱环境会起一个 Docker 容器来隔离智能体执行的代码，并通过一个轻量 TCP 命令服务与容器通信。问题出在这个 TCP 服务本身：它绑定 0.0.0.0，对连上来的连接不做任何鉴权，收到的 bash 命令直接以 root 身份在容器内执行。
漏洞到底长什么样
攻击路径并不依赖任何传统意义上的「破解」。攻击者只需要能扫到暴露的端口，打开一条原始 TCP 连接，发送一段 bash 命令，命令就会在沙箱容器里以 root 身份被执行。因为 AutoAgent 的沙箱通常会把宿主机工作目录挂载进容器供智能体读写，这个 root 权限还能触及容器之外的真实文件。
披露方 CosmicBytez Labs 将其标注为「正在被利用」，并建议立即处置。受影响的提交范围一直到 16c12b052；截至 9 月 5 日的记录，公告指向 issue 96，但未列出已确认修复的版本。也就是说，在补丁发布之前，缓解责任落在部署方自己身上。
同一类缺陷，四条独立记录
AutoAgent 不是孤例。NetFoundry 在 9 月 4 日至 10 日的「可达性观察」里统计了 906 个新发网络可达 CVE，其中 96 个达到其严重线（CVSS 8.6 以上），包括 5 个满分 10.0。其中 AI 智能体与自动化工具占了显眼位置，且呈现同一个模式：鉴权检查只在某个环境变量被设置时才运行，变量一旦没设，检查就不跑。
除 AutoAgent 的 CVE-2026-86124 外，同批还有：Cua 的 computer-server（CVE-2026-86121，9.8），当 CONTAINER_NAME 未设置时跳过鉴权，端口 8000 暴露 /cmd、/ws、/pty；excel-mcp-server（CVE-2026-85661，9.8），EXCEL_FILES_PATH 留空时可读写任意文件；TEN Framework 的 TMAN Designer API（CVE-2026-85688，9.8），无需任何环境变量即可未鉴权读写文件。
根因：鉴权检查「只在变量被设置时才跑」
这四处缺陷分属三个厂商、三种不同代码库，却共享同一段逻辑：auth check 写在代码里，但只有在某个环境变量被设好的前提下才会被调用；三者都没有「变量没设就失败关闭」的兜底。于是「我们写了检查」和「检查真的跑了」之间出现了一条缝——而这条缝正是这一整批漏洞的贯穿主题。
Cua 的反应更积极：版本 0.3.42 把默认改成了本地模式只绑 127.0.0.1，并把「显式选择不安全」做成 CUA_ALLOW_INSECURE=1 的开关，跨站来源检查也在评审中。AutoAgent 一侧的补丁状态当时仍是开放。这个差异本身说明：问题不在于能不能修，而在于默认值的取向。
为什么「root 容器加挂载宿主机」不是沙箱
这几份记录都把危险能力包进 Docker，并描述容器本应兜住损害。但 Docker 自己的文档比这份代码更谨慎：rootless 模式的存在，正是因为「容器内 root」并不是一道硬边界；而挂载（bind mount）正是打开一条回宿主机的路。一个以 root 运行、且把宿主机目录挂载为可写的容器，不是沙箱，它就是你的机器，只是多绕了几步。
披露方据此把这类部署称为「你拥有的、权限过度集中的账户」。这两份 9.8 记录都映射到 CWE-306（关键功能缺少鉴权），在 CISA 的 KEV 目录里当时未见收录——但「正在被利用」的标注意味着它已经不是纸面风险。
微软那一波，是同一主题的旁注
同一观察期内，微软在 9 月 9 日一次性修补了 15 个严重网络 CVE，其中 14 个评分 9.8，覆盖 Windows DNS、DHCP 服务、RPC 运行时、USB 大容量存储与 Telnet 客户端，外加 Exchange Server 的 CVE-2026-69356（9.3）。这些不是智能体专属缺陷，但它们和前面的模式是同一句话的注脚：一个本应不可达的服务，因为某个开关没设对，变成了可达且可被接管。
区别在于，微软这批有官方补丁节奏；而若干开源智能体工具的补丁状态参差，部署方需要自己先兜底。
给自用沙箱的五项检查
如果在本地跑任何智能体沙箱，建议至少做五件事。其一，不要在任何不可信网络上暴露沙箱端口，把命令端口绑到 127.0.0.1 或直接去掉发布参数。其二，在防火墙或安全组层面阻断该端口来自非回环接口的连接。其三，去掉 docker run 里的 --user root，改用最小权限的非特权 UID。其四，如果服务必须超越本地，前面加一层 mTLS 或令牌代理，不要只靠网络隔离。其五，审计现有部署是否已有该端口从外部可达，并监控异常的入站连接与容器内进程派生。
这次真正值得带走的判断
这两份 9.8 记录更像是一个论点的注脚：你的智能体，很可能就是你所拥有、权限最过度的那个账户。当一个能执行代码、能联网、能读写文件的系统被默认以 root 跑、且监听所有网卡时，严重程度评分只是把这件事标注了出来。对部署方来说，真正要改的不是某一行代码，而是「默认开放」这个取向——把「是否对外开放」做成显式开关，并让未设变量时失败关闭，而不是失败放行。
公开材料未提供受影响的在野利用规模与时间线细节，行业暂未披露更多，后续将持续跟进迭代动态。