GHSA-WW6V-V748-X7G9: Sandbox Network Isolation Bypass in OpenClaw via Docker Container Mode

The core of OpenClaw's security model relies on strictly isolating agents within sandboxed Docker containers. To maintain this boundary, the validateNetworkMode function is responsible for vetting container configurations before execution. Its primary goal is to ensure that a sandboxed process cannot escape its virtualized network environment or access the host's network stack directly.

The vulnerability exists because the validation logic employed a strict allowlist/blocklist approach that was insufficiently comprehensive. While it explicitly prohibited the host network driver—a known dangerous configuration—it did not account for Docker's capability to share network namespaces between containers using the --network=container:<target> syntax. This omission created a logic gap where a technically valid but insecure configuration could pass validation checks.

By exploiting this flaw, an attacker can effectively merge the network stack of the sandboxed agent with that of any other container on the same Docker host, provided they know the target's ID or name. This breaks the fundamental assumption of the sandbox: that the agent operates in a private, isolated network environment.

The root cause is an Incomplete Blocklist implementation in the validateNetworkMode function. The security logic relied on checking the provided network mode string against a specific set of banned values, specifically checking only for the exact string "host".

Docker's network configuration is flexible and accepts the format container:<name|id> to instruct the Docker daemon to place the new container in the same network namespace as an existing one. When this mode is used:

1. The new container shares the IP address and MAC address of the target container.
2. The new container shares the loopback (localhost) interface of the target.
3. Port conflicts can occur, and services bound to 127.0.0.1 in the target become accessible to the new container.

Because the validator in src/agents/sandbox/validate-sandbox-security.ts only performed an exact match check (BLOCKED_NETWORK_MODES.has(network)), strings starting with container: were treated as valid custom network names rather than dangerous namespace directives.

The vulnerability resided in src/agents/sandbox/validate-sandbox-security.ts. The original code failed to inspect the structure of the network string, looking only for exact matches against a Set.

Vulnerable Code (Pre-Patch)

const BLOCKED_NETWORK_MODES = new Set(["host"]);
 
export function validateNetworkMode(network: string | undefined): void {
  // VULNERABILITY: Only checks for exact match of "host"
  // Fails to catch "container:target-id"
  if (network && BLOCKED_NETWORK_MODES.has(network.trim().toLowerCase())) {
    throw new Error(`Sandbox security: network mode "${network}" is blocked.`);
  }
}

Patched Code (Version 2026.2.24)

The fix introduces a prefix check to catch the container: syntax and adds a "break-glass" option for intentional overrides. This ensures that namespace sharing is blocked by default unless explicitly allowed by the administrator.

export function validateNetworkMode(network: string | undefined, options?: SandboxOptions): void {
  const normalized = network?.trim().toLowerCase();
  
  // FIX: Check for "host" AND "container:" prefix
  if (normalized === "host" || (normalized && normalized.startsWith("container:"))) {
    // Check for explicit override flag
    if (options?.allowContainerNamespaceJoin !== true) {
      throw new Error(
        `Sandbox security: network mode "${network}" is blocked by default. ` +
        'Network "container:*" joins another container namespace and bypasses sandbox network isolation. ' +
        "Use a custom bridge network, or set dangerouslyAllowContainerNamespaceJoin=true only when you fully trust this runtime."
      );
    }
  }
}

To exploit this vulnerability, an attacker requires the ability to configure the docker.network setting for the OpenClaw agent. This is typically done via the openclaw.yml configuration file or dynamic agent provisioning scripts.

Attack Scenario:

1. Identify Target: The attacker identifies a target container running on the same host, such as a database (postgres-internal) or a sensitive application service.
2. Configure Agent: The attacker configures the OpenClaw sandbox settings:

   agents:
     defaults:
       sandbox:
         docker:
           network: "container:postgres-internal"

3. Execution: When OpenClaw starts the agent, it passes --network=container:postgres-internal to the Docker daemon.
4. Access: The agent starts sharing the network stack of the database container. The agent can now connect to the database simply by dialing localhost:5432, bypassing any firewall rules that normally restrict external access to the database container.

The impact of this vulnerability is critical for multi-tenant or compartmentalized environments relying on Docker sandboxes.

• Isolation Bypass: The primary security control of the sandbox—network isolation—is completely negated. The boundary between the untrusted agent and trusted infrastructure is removed.
• Internal Service Exposure: Many microservices bind administrative interfaces or unauthenticated APIs to localhost, assuming they are unreachable from outside the container. This vulnerability exposes those interfaces directly to the attacker.
• Identity Theft: By inheriting the IP address of a privileged container, the malicious agent can bypass IP-based allowlists used by other network appliances or cloud IAM roles assigned to the target container's IP.

This flaw allows lateral movement from a low-privilege sandbox into critical infrastructure components without requiring a container escape exploit against the Linux kernel.