Affected: OpenClaw

OpenClaw before 2026.2.24 contains a sandbox network isolation bypass vulnerability that allows trusted operators to join another container's network namespace. Attackers can configure the docker.network parameter with container:<id> values to reach services in target container namespaces and bypass network hardening controls.

Affected: npm: openclaw

### Summary In `openclaw@2026.2.23`, sandbox network hardening blocks `network=host` but still allows `network=container:<id>`.

This can let a sandbox join another container's network namespace and reach services available in that namespace.

### Preconditions and Trust Model Context This issue requires a trusted-operator configuration path (for example setting `agents.defaults.sandbox.docker.network` in gateway config). It is not an unauthenticated remote exploit by itself.

### Details Current validation blocks only `host`, while forwarding other values to Docker create args:

- `validateNetworkMode(network)` only rejects values in `BLOCKED_NETWORK_MODES = {"host"}`. - `buildSandboxCreateArgs(...)` validates then forwards `cfg.network` into `--network`. - Browser sandbox helper also treats `container:` as an accepted mode in network preparation.

Effective behavior:

- `host` -> blocked - `container:<id>` -> accepted and forwarded

### Impact Type: sandbox network isolation hardening bypass.

Practical impact depends on deployment:

- Requires ability to influence trusted sandbox network config. - Higher impact when a target container exposes privileged/internal network reachability.

### Remediation Block namespace-join style network modes (including `container:<id>`) for sandbox containers, and keep strict allowlisting for safe network modes.

### Patch Status Fixed on `main` in commit `14b6eea6e`: https://github.com/openclaw/openclaw/commit/14b6eea6e

Follow-up refact…