Monitor vulnerabilities like this one.
Sign up free to get alerted when software you use is affected.
6.9
OpenClaw Sandbox Network Isolation Bypass via Docker Container Join
GHSA-ww6v-v748-x7g9
Summary
A security issue in OpenClaw allows a sandbox to access services in another container's network. This can happen if an attacker has control over the sandbox configuration. To fix this, update the OpenClaw settings to block container join-style network modes and only allow safe network configurations. If you use OpenClaw, check for updates and follow the recommended configuration changes to prevent this issue.
What to do
- Update openclaw to version 2026.2.24.
Affected software
| Vendor | Product | Affected versions | Fix available |
|---|---|---|---|
| – | openclaw | <= 2026.2.23 | 2026.2.24 |
Original title
OpenClaw has a sandbox network isolation bypass via docker.network=container:<id>
Original description
### Summary
In `[email protected]`, 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 refactor/cleanup (no policy rollback):
https://github.com/openclaw/openclaw/commit/5552f9073
### Publication Update (2026-02-25)
`[email protected]` is published on npm and contains the fix commit(s) listed above. This advisory now marks `>= 2026.2.24` as patched.
In `[email protected]`, 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 refactor/cleanup (no policy rollback):
https://github.com/openclaw/openclaw/commit/5552f9073
### Publication Update (2026-02-25)
`[email protected]` is published on npm and contains the fix commit(s) listed above. This advisory now marks `>= 2026.2.24` as patched.
ghsa CVSS4.0
6.9
Vulnerability type
CWE-284
Improper Access Control
CWE-693
Protection Mechanism Failure
Published: 2 Mar 2026 · Updated: 7 Mar 2026 · First seen: 6 Mar 2026