CVE-2026-62201 OpenClaw: Sandbox Exec-Server SSRF and Network Policy Bypass

1. Introduction

This article examines a Server-Side Request Forgery (SSRF) and network policy bypass in OpenClaw, a local-first AI assistant platform that supports execution through sandboxed backends.

Tracked as CVE-2026-62201, the flaw has an advisory-published CVSS 3.1 score of 7.7 (High). A caller with access to the experimental sandbox exec-server can retrieve HTTP or HTTPS responses from destinations reachable by the active sandbox, including private, loopback, link-local and metadata addresses. Before 2026.6.6, the http/request method did not enforce destination policy.

GitHub Security Advisory GHSA-mgvr-6gvw-3rgr credits GitHub user diedromeo as the reporter. OpenClaw 2026.6.6 shipped the fix on June 12, 2026, followed by the advisory on June 30, 2026. Public reproduction material is available.

Safe Security independently reproduced the vulnerable behavior on OpenClaw 2026.6.5 and the patched behavior on 2026.6.6 through the exec-server and SSH sandbox path.

2. OpenClaw Description

OpenClaw is a local-first AI assistant platform built around a Gateway process that coordinates conversations, model routing, channels, tool policy, approvals, and execution configuration. A sandbox backend can run supported agent actions outside the Gateway host. OpenClaw’s Codex integration combines two execution contexts: the Codex app-server, which manages the Codex runtime and native execution semantics, and the OpenClaw sandbox, which defines where supported execution is allowed.

When a Codex-backed session is sandboxed, OpenClaw connects these contexts through an experimental sandbox exec-server, a WebSocket server bound to loopback at ws://127.0.0.1:<ephemeral-port>/openclaw-<random-uuid> that the OpenClaw runtime registers with the Codex app-server via the environment/add JSON-RPC method. The capability is configured through plugins.entries.codex.config.appServer.experimental.sandboxExecServer, defaulted to false in OpenClaw 2026.6.5 as a preview opt-in requiring Codex app-server 0.132.0 or newer, and is intended as a local capability for the paired Codex runtime. It is not a public HTTP proxy.

3. Vulnerability Severity

The GitHub advisory assigns CVSS v3.1 7.7 (High), with Scope Changed and High confidentiality impact. The published AV:N/PR:L vector should be read alongside the advisory’s scope: exploitation assumes a lower-trust caller or configured input path can reach the affected capability; it does not imply direct network exposure of the loopback exec-server.

4. Scope of Impact

• Affected: OpenClaw releases before 2026.6.6 (per GHSA-mgvr-6gvw-3rgr)
• Tested vulnerable version: OpenClaw 2026.6.5
• Condition: the experimental sandboxExecServer capability must be explicitly enabled; it defaults to false in the tested 2026.6.5 release. A Codex harness plugin, Codex app-server 0.132.0 or newer, and an active sandbox backend are all required, and practical impact further requires a caller or configured runtime path able to invoke the capability and sandbox network access to a destination that could expose data or functionality
• Fixed: OpenClaw 2026.6.6 and later (released June 12, 2026)

A version match identifies a potentially affected installation; exposure also depends on feature configuration, caller access and sandbox network reach.

5. Where is the vulnerability present?

The vulnerability resides in OpenClaw’s sandbox exec-server HTTP implementation in extensions/codex/src/app-server/sandbox-exec-server/http.ts at tag v2026.6.5. The exec-server is a broker across a trust boundary: it receives JSON-RPC http/request calls carrying a caller-controlled URL, serializes them, and hands them to the active sandbox backend, which runs an embedded Python HTTP helper whose eventual TCP connection originates from the sandbox’s network context. In 2026.6.5, httpRequest() validates the request structure and field types but performs no destination policy check on the supplied URL before dispatching to the backend.

The embedded Python helper checks only the URL scheme (HTTP and HTTPS are accepted; other schemes are rejected) before constructing a normal urllib.request.Request and performing urllib.request.urlopen(). The scheme check limits requests to HTTP and HTTPS but does not determine whether the caller is allowed to contact the resolved destination. A syntactically valid HTTP URL can still point to loopback, private, link-local, metadata, or other special-use space, and an apparently ordinary hostname can resolve to one of those addresses.

The caller can read the response status, headers, and the Base64-encoded body returned in bodyBase64.

The root cause is missing destination validation. OpenClaw moved the request into the sandbox without restricting its network destination. The fix adds two layers of validation. A TypeScript pre-flight guard validates the URL before the sandbox backend is invoked, rejecting malformed, known-blocked, or literal private/internal targets without touching the sandbox.

A Python execution-side guard inside the helper resolves hostnames in the environment that will actually make the request, classifies the resolved addresses against private, loopback, link-local, reserved, multicast, and special-use ranges (including IPv4 values embedded in IPv6 forms such as mapped IPv4, NAT64, 6to4, Teredo, and ISATAP), pins the validated DNS resolution for the connection, revalidates redirect destinations, and disables inherited proxy handling.

The analysis and component-level reproduction below are Safe Security’s independent validation of the product behavior.

6. Risk

A caller with access to the exec-server capability can make HTTP requests from the active sandbox and read the responses through JSON-RPC. Sandbox reachability determines which destinations can be contacted, while each destination’s authentication and application behavior determine what data is exposed. A broadly connected sandbox may therefore reveal internal applications, management interfaces, development services, and APIs that are unreachable to the original caller. Even when those services require authentication, returned status codes, headers, server banners, error bodies, and other responses can reveal service inventory and topology.

The risk is greatest when internal services trust requests based on their network origin, including local-only administration pages, development interfaces, or internal APIs that are deliberately inaccessible from untrusted networks but reachable from a workload or execution segment. Cloud metadata services are also relevant because they are intentionally exposed to workloads rather than arbitrary remote clients; the patched implementation specifically protects metadata hostnames and special metadata ranges.

The lab demonstrated a confidentiality impact: response data from HTTP services reachable from the sandbox can be returned to the caller. This does not establish arbitrary read access to every reachable service. Potential integrity and availability effects depend on the behavior and permissions of reachable services; they were not validated in this lab.

7. Mitigation

• Upgrade OpenClaw to 2026.6.6 or later. The release enforces destination policy at two layers: TypeScript pre-flight validation before the sandbox backend is invoked, and execution-side DNS resolution, address classification, pinning, and redirect revalidation inside the helper.
• Verify destination-policy enforcement for the sandbox backend deployed in your environment.
• Disable the sandboxExecServer capability wherever it is not required.
• Restrict capability distribution. Keep the exec-server available only to the intended local runtime path; the server binds loopback with a random /openclaw-<uuid> authorization path, and connections with any other path are refused with WebSocket close code 1008. Do not bridge or forward the capability to less-trusted callers.
• Constrain sandbox egress. Permit only workload-required destinations and block unnecessary access to management networks, internal API ranges, and link-local addresses, to limit the impact of future SSRF vulnerabilities in the same environment.
• Review the exposure window. If the feature was enabled on a vulnerable release, determine which runtime paths could invoke it and which destinations were reachable from the sandbox during that window.
• Review network and endpoint evidence. DNS logs, proxies, firewalls, VPC flow records, and endpoint telemetry are more likely to surface historical use than an application-level URL audit trail.

8. Exploit Implementation

Attack Scenario

The September 29 lab run used OpenClaw 2026.6.5 and 2026.6.6 with sandboxExecServer explicitly enabled, Codex app-server 0.154.0, and an SSH sandbox backend. Seven containers shared an internal Docker network without published host ports. The synthetic canary at http://canary:6379/admin was 172.29.0.5; the SSH sandbox host was 172.29.0.4.

The research harness starts an embedded OpenClaw agent with openclaw agent –local and connects a local research client to the registered exec-server capability. This tests the product HTTP path and SSH backend. The client, rather than a model, initiated the requests.

Prerequisites:

Docker and Docker Compose

The seven isolated lab containers, including the canary and SSH sandbox host

OpenClaw 2026.6.5 and 2026.6.6 with sandboxExecServer enabled

The /opt/lab/run-turn.sh research harness and its JSON-RPC client

Exploitation

1. Confirm that the lab is running and that the two OpenClaw versions use the same configured SSH backend.

2. Check that the synthetic service is reachable from the separate research-client container. This is a baseline network check, separate from the OpenClaw request.

3. Use the embedded-agent harness on 2026.6.5 to submit the canary URL through exec-server http/request.

Figure 1: OpenClaw 2026.6.5 returns the canary response through its exec-server. The lab client decodes bodyBase64 for display. The client exit code of 0 means the research harness handled its result; the HTTP 200 and returned body establish this request’s success.

4. Correlate the response with the canary access log and sandbox source address.

Figure 2: The matching second and SSH-host source address corroborate the sandbox origin of the vulnerable request. The separate research-client baseline used a different container.

5. Repeat the hostname request on 2026.6.6. The execution-side helper resolves and rejects the private destination.

Figure 3: The fixed version invokes the sandbox helper once, then its execution-side address check rejects the hostname. The lab client exits 0 after handling the JSON-RPC error; that exit code does not indicate request success.

6. Submit the canary’s literal private IP on 2026.6.6 to isolate the earlier TypeScript validation boundary.

Figure 4: The literal private IP is rejected before the sandbox HTTP helper runs. The per-run helper log count is zero; the JSON-RPC error identifies the rejection.

Demonstrated Impact

The vulnerable version returned the synthetic internal service’s status, headers, and response body through the SSH sandbox path. This establishes confidentiality impact for the tested reachable service. The run did not use model-driven initiation, real metadata endpoints, or actual credentials.

Figure 5: Impact recap from Figure 1. This is the same September 29 request and returned synthetic body, not a second test.