GHSA-fv94-qvg8-xqpw: OpenClaw SSH Sandbox Symlink Escape and Arbitrary File Access

The OpenClaw framework provides an execution environment for AI agents, utilizing an SSH sandbox to isolate code execution and file modifications. The architecture relies on the uploadDirectoryToSshTarget function to synchronize the agent's local workspace directory with the remote execution environment. This synchronization process is fundamental to the agent's operation, ensuring that generated code, configuration files, and datasets are available in the sandbox before execution begins.

Prior to version 2026.3.31, the framework operated under the assumption that all files within the local workspace were strictly confined to that directory tree. The underlying implementation utilized archiving mechanisms to stream the directory contents over the SSH connection. The framework did not implement pre-flight validation checks to assess file metadata, specifically failing to detect or sanitize symbolic links residing within the synchronization source directory.

This architectural omission manifests as a vulnerability classified under CWE-61 (UNIX Symbolic Link Following) and CWE-59 (Improper Link Resolution Before File Access). When the synchronization process encounters a symbolic link, the archiver either dereferences the link and copies the target file's contents, or copies the link verbatim to the remote target. Without path resolution constraints, these behaviors inherently violate the intended directory boundaries established by the framework.

The resulting security impact compromises the integrity and confidentiality of both the host running the OpenClaw agent and the target SSH sandbox. An attacker capable of influencing the agent's local file operations can exploit this flaw to execute arbitrary file reads from the local host system or achieve arbitrary file writes on the remote host, effectively resulting in a comprehensive sandbox escape.

The root cause of GHSA-fv94-qvg8-xqpw resides in the asynchronous file synchronization logic of uploadDirectoryToSshTarget. In Node.js environments, standard file iteration methods do not automatically distinguish between standard files and symbolic links unless explicitly instructed using functions like fs.lstat() or the withFileTypes: true flag in fs.readdir(). The vulnerable OpenClaw implementation traversed the workspace directory using standard file operations that implicitly dereferenced symbolic links during the read phase.

When an AI agent receives instructions, it frequently generates or manipulates files within its local workspace. If an attacker directs the agent to execute shell commands or use file system APIs to create a symbolic link, the link is written to the local disk. For example, a link created pointing to /etc/shadow is treated as a valid workspace artifact by the agent. The core failure occurs because the synchronization loop processes this artifact without verifying that its absolute resolved path remains a descendant of the workspace root path.

During the SSH upload operation, the unvalidated symlink triggers one of two critical exploitation paths depending on the exact transport mechanism used by the OpenClaw runtime. If the transport layer dereferences the link locally, it reads the contents of the target file (e.g., the local /etc/shadow) and writes those contents as a standard file in the remote sandbox. If the transport layer preserves the symlink, the link itself is written to the remote sandbox, pointing to the remote system's /etc/shadow.

The conditions required to trigger this vulnerability are relatively low, demanding only that the attacker can supply input to the OpenClaw agent and that the agent possesses the capability to execute tool calls that modify the file system. Given that the primary utility of frameworks like OpenClaw is autonomous file and code generation, the agent inherently possesses the necessary prerequisites to construct the malicious filesystem state.

The patch implemented in commit 3d5af14984ac1976c747a8e11581d697bd0829dc introduces strict validation logic prior to the invocation of the remote synchronization logic. The core of this patch is the addition of the assertSafeUploadSymlinks function, which explicitly walks the local directory tree and evaluates the metadata of every entry.

// src/agents/sandbox/ssh.ts
async function assertSafeUploadSymlinks(localDir: string): Promise<void> {
  const rootDir = path.resolve(localDir);
  await walkDirectory(rootDir);
 
  async function walkDirectory(currentDir: string): Promise<void> {
    const entries = await fs.readdir(currentDir, { withFileTypes: true });
    for (const entry of entries) {
      const entryPath = path.join(currentDir, entry.name);
      if (entry.isSymbolicLink()) {
        try {
          await resolveBoundaryPath({
            absolutePath: entryPath,
            rootPath: rootDir,
            boundaryLabel: "SSH sandbox upload tree",
          });
        } catch (error) {
          const relativePath = path.relative(rootDir, entryPath).split(path.sep).join("/");
          throw new Error(
            `SSH sandbox upload refuses symlink escaping the workspace: ${relativePath}`
          );
        }
        continue;
      }
      if (entry.isDirectory()) {
        await walkDirectory(entryPath);
      }
    }
  }
}

The implementation leverages fs.readdir(currentDir, { withFileTypes: true }), which returns fs.Dirent objects instead of standard string arrays. This allows the application to synchronously check entry.isSymbolicLink() without incurring the performance overhead of executing fs.lstat() on every file. When a symbolic link is identified, the code passes the absolute path of the link to the resolveBoundaryPath utility function.

The resolveBoundaryPath function acts as the security boundary enforcer. It computes the fully resolved path of the symlink target using Node.js path resolution APIs and verifies that the resulting path begins with the rootDir string prefix. If the resolved path traverses outside the root directory, resolveBoundaryPath throws an error. This error is caught in assertSafeUploadSymlinks, wrapped with a descriptive error message indicating the relative path of the offending symlink, and re-thrown.

This fix strategy employs a fail-fast mechanism. By throwing an exception upon the discovery of the first boundary violation, the entire uploadDirectoryToSshTarget process is aborted before any network transmission occurs. This ensures that the synchronization state remains atomic and prevents partial uploads of malicious structures. The recursive nature of walkDirectory ensures that deeply nested malicious links are also detected and neutralized.

The exploitation of GHSA-fv94-qvg8-xqpw requires the attacker to manipulate the AI agent's behavior to interact with the file system. This is typically achieved through prompt injection or malicious instructions supplied in the agent's input context. The attacker instructs the agent to create a symbolic link pointing to a sensitive target using standard command-line tools or available agent APIs.

Once the link is created within the local workspace directory, the attacker must induce the agent to synchronize the workspace with the remote SSH sandbox. This synchronization is often an automatic consequence of the agent preparing to execute a script or run a test suite within the sandbox environment. The uploadDirectoryToSshTarget function initiates the transfer process, encompassing the newly created symbolic link.

If the objective is to exfiltrate local data, the attacker ensures the link points to a local file. The synchronization process reads the target file and uploads its contents to the sandbox. The attacker then issues a subsequent command to the agent to read the uploaded file from within the sandbox and output its contents, completing the exfiltration loop. If the objective is remote host compromise, the attacker crafts the link to point to a remote location like ~/.ssh/authorized_keys. The link is synced, and a subsequent write operation by the agent overwrites the remote file.

Academic research detailing this vulnerability, published in arXiv:2603.10387 under the title "Don’t Let the Claw Grip Your Hand: A Security Analysis and Defense Framework for OpenClaw", highlights the effectiveness of this methodology. The researchers demonstrated that the native OpenClaw architecture possessed an average defense rate of merely 17% against these specific sandbox escape vectors prior to the implementation of the patch.

The exploitation of this vulnerability yields severe consequences regarding data confidentiality on the machine hosting the OpenClaw framework. By constructing a symbolic link targeting sensitive configuration files, environment variable files (such as .env), or system credential stores, an attacker can coerce the framework into transferring these files into the SSH sandbox. Once the files reside in the sandbox, the attacker can leverage standard agent capabilities to access and exfiltrate the data.

The vulnerability equally impacts the integrity of the remote system hosting the SSH sandbox. In scenarios where the symbolic link is preserved during the transfer process, the link acts as a conduit for arbitrary file writes on the remote host. An attacker can instruct the agent to write a payload to the deployed symlink within the sandbox directory, which the operating system will transparently redirect to the symlink's target destination on the broader filesystem.

This bidirectional traversal capability constitutes a complete sandbox escape. The isolation guarantees provided by the SSH sandbox architecture are nullified, as the attacker gains read and write primitives outside the restricted directory tree. This allows for lateral movement, privilege escalation on the remote host, and persistent access mechanisms depending on the specific files targeted by the write operations.

Organizations utilizing unpatched versions of OpenClaw in automated pipelines or user-facing applications expose their infrastructure to significant risk. The vulnerability allows an untrusted input vector (the AI prompt) to achieve file-system level compromise, demonstrating a critical failure in the boundary enforcement mechanisms between the AI application layer and the underlying host operating system.

The definitive remediation for GHSA-fv94-qvg8-xqpw is to upgrade the openclaw npm package to version 2026.3.31 or a subsequent release. This version incorporates the assertSafeUploadSymlinks logic, which successfully blocks the synchronization of malicious symbolic links. Administrators should audit their dependency trees and continuous integration pipelines to ensure the vulnerable versions are entirely purged from the deployment environment.

As a defense-in-depth measure, administrators should enable the Human-in-the-Loop (HITL) execution mode within the OpenClaw configuration. The HITL feature intercepts potentially destructive tool calls and file system operations, requiring explicit human authorization before execution. While not a replacement for patching the underlying vulnerability, HITL severely constrains the autonomy required for an attacker to successfully construct and execute the exploit chain.

System-level hardening of the SSH sandbox environment is critical to minimizing the blast radius of any file write vulnerabilities. The SSH user account designated for the sandbox execution must operate under the principle of least privilege. It should be restricted from accessing sensitive system directories, utilizing strict ownership and permission models to prevent modifications to critical files like SSH authorized keys or system binaries.

Finally, organizations should implement runtime monitoring on the file systems hosting the AI agent workspaces. Security information and event management (SIEM) systems or endpoint detection and response (EDR) agents should be configured to flag the creation of symbolic links within these specific directories. Anomalous file metadata operations within the workspace tree serve as a strong indicator of compromise for this specific class of vulnerability.