GHSA-2rqg-gjgv-84jm: Workspace Boundary Bypass and Sandbox Escape in OpenClaw

The OpenClaw application utilizes a gateway architecture to manage and orchestrate agents. These agents execute tasks within restricted directory boundaries known as workspaces. The gateway relies on a Remote Procedure Call (RPC) interface to handle operations, including the instantiation of new subagents via the agent method.

An Improper Access Control flaw (CWE-284) exists in the parameter handling of this agent RPC method. The gateway exposes internal configuration fields to the public API schema, allowing callers to define their own execution environments. When a subagent is spawned, the gateway processes these caller-supplied parameters without strictly validating them against the parent agent's authorized workspace boundary.

This architectural oversight results in a direct sandbox escape vulnerability. An attacker with the ability to invoke the agent RPC method can override the target directory for the new subagent. The vulnerability allows an actor to break out of the intended workspace and interface directly with the underlying host filesystem.

The flaw affects all versions of the openclaw package prior to v2026.3.12. Successful exploitation provides the unauthorized subagent with the same filesystem permissions as the OpenClaw service itself, facilitating unauthorized data access and potential host compromise.

The root cause of this vulnerability is a Mass Assignment and Insecure Direct Object Reference (IDOR) condition within the OpenClaw gateway's schema definitions. The AgentParamsSchema defined the structure for incoming agent RPC requests. This public schema incorrectly included the workspaceDir and spawnedBy properties as optional, externally controllable string values.

When processing a request to spawn a new agent, the gateway handler located in src/gateway/server-methods/agent.ts extracted these parameters directly from the user-provided payload. The internal logic prioritized the caller-supplied workspaceDir string over any internally maintained session state. If the spawnedBy field was populated, the gateway assumed the request was a valid subagent invocation and blindly trusted the accompanying directory path.

The application lacked sufficient path validation and normalization checks. It failed to verify whether the provided workspaceDir was a subdirectory of the authenticated user's authorized workspace. No canonicalization or traversal prevention mechanisms were applied to the input before passing it to the execution engine.

Consequently, the trust boundary was improperly defined. The application relied on client-provided data for a critical security decision—the base directory of a code execution environment. This allowed external inputs to directly control the execution context of the spawned processes.

The remediation strategy implemented in PR #43801 focuses on removing the vulnerable parameters from the public schema and enforcing server-side state tracking. The patch first addresses the public exposure in src/gateway/protocol/schema/agent.ts.

 export const AgentParamsSchema = Type.Object(
   {
     // ... other fields
     idempotencyKey: NonEmptyString,
     label: Type.Optional(SessionLabelString),
-    spawnedBy: Type.Optional(Type.String()),
-    workspaceDir: Type.Optional(Type.String()),
   },
   { additionalProperties: false },
 );

By removing spawnedBy and workspaceDir from AgentParamsSchema, the gateway automatically rejects incoming RPC requests that attempt to specify these fields. The schema validation layer now acts as the primary defense against external parameter injection. The patch then alters the trust model within the gateway handler (src/gateway/server-methods/agent.ts).

         // Internal-only: allow workspace override for spawned subagent runs.
         workspaceDir: resolveIngressWorkspaceOverrideForSpawnedRun({
           spawnedBy: spawnedByValue,
-          workspaceDir: request.workspaceDir,
+          workspaceDir: sessionEntry?.spawnedWorkspaceDir,
         }),

The resolveIngressWorkspaceOverrideForSpawnedRun function no longer accepts the workspaceDir from the user request object. Instead, it retrieves the spawnedWorkspaceDir directly from the sessionEntry object. This session data is populated by an internal sessions.patch call that occurs before the agent execution sequence begins. This architectural shift ensures the workspace directory is strictly controlled by the server-side lineage tracking mechanism and remains immutable by external actors.

Exploitation of this vulnerability requires an attacker to have established access to the OpenClaw RPC interface. This access is typically achieved by a compromised subagent or a user account possessing basic write permissions within the OpenClaw environment. The attacker initiates an RPC call to the agent endpoint, appending the unauthorized parameters to the JSON payload.

The exploit payload defines the spawnedBy parameter to satisfy the gateway's condition for subagent execution. Concurrently, the attacker sets the workspaceDir parameter to an absolute path on the host filesystem, such as /etc or /root. Because the schema validation permits these fields and the handler trusts them, the request passes without raising security exceptions.

Upon processing the request, the gateway provisions a new subagent and sets its working directory to the attacker-supplied path. The new subagent now operates entirely outside the intended workspace boundary. The attacker can subsequently issue commands to this newly spawned agent to read sensitive files, modify host configurations, or extract credentials stored on the underlying server.

The primary impact of this vulnerability is the complete circumvention of the OpenClaw sandbox boundary. When an attacker escapes the designated workspace, the security guarantees of the isolation mechanism are nullified. The spawned agent inherits the file system permissions of the OpenClaw service process running on the host machine.

If the OpenClaw service operates with elevated privileges, the attacker gains arbitrary read and write access to the entire host filesystem. This level of access facilitates the extraction of sensitive data, including SSH keys, environment variables containing database credentials, and system configuration files. Write access allows the modification of authorized keys or execution scripts, leading to persistent host compromise.

The vulnerability also enables cross-session interference in multi-tenant environments. An attacker can set the workspaceDir to the execution directory of another user or agent. This permits the unauthorized viewing of proprietary code, the manipulation of concurrent task inputs, and the theft of session-specific access tokens belonging to other principals.

The definitive remediation for this vulnerability is upgrading the openclaw package to version v2026.3.12. This release contains the schema modifications and server-side state tracking mechanisms required to prevent user-supplied paths from influencing the agent execution context. Organizations must ensure all deployed instances of the gateway are updated immediately.

In environments where immediate patching is not feasible, administrators should review the permissions granted to the OpenClaw service account. The service should operate under the principle of least privilege, with filesystem access restricted strictly to the required application directories. Implementing mandatory access control (MAC) systems, such as AppArmor or SELinux, can further constrain the service and prevent access to sensitive host directories even if the sandbox is bypassed.

Security teams should actively monitor gateway logs for anomalous RPC activity. While the patch prevents exploitation, historical logs should be reviewed for past compromise attempts. Investigators should search for agent RPC invocations containing the workspaceDir and spawnedBy parameters, particularly those specifying absolute paths or traversal sequences outside the authorized workspace hierarchies.