GHSA-F7WW-2725-QVW2: TOCTOU Approval Bypass in OpenClaw via Symlink Rebinding

OpenClaw acts as an autonomous agent capable of executing system commands via the system.run interface. To maintain security, the framework implements a 'Gateway' pattern where sensitive operations requested by a Node (agent) must be explicitly approved by a human administrator or a policy engine. This approval process relies on inspecting the parameters of the request, specifically the command arguments (argv) and the working directory (cwd).

The vulnerability stems from a Time-of-Check Time-of-Use (TOCTOU) discrepancy in how file paths are handled during this workflow. The system validates the cwd path as a string during the approval phase. However, it does not ensure that the filesystem objects referenced by that path remain static until execution. In a Linux/Unix environment, paths containing symbolic links are resolved dynamically by the kernel at the moment of access. If an attacker can modify the symlink targets after approval is granted, the validation logic becomes irrelevant.

This flaw undermines the core security model of OpenClaw, effectively allowing an agent or a local attacker to trick an administrator into authorizing execution in a sandbox environment, only to have the execution actually occur in a privileged or sensitive directory. This is classified as an Authorization Bypass via Race Condition (CWE-367).

The root cause is the lack of atomicity between the path validation step and the process instantiation step, combined with the presence of mutable symbolic links in the path components. When system.run is invoked, the path is presented to the approver. The approver evaluates the risk based on the path's resolution at that moment. Once approved, the system queues the command for execution.

The execution engine eventually calls the operating system's process spawn primitives (e.g., execve or Node.js child_process.spawn), passing the originally approved string as the cwd. The OS resolves this path at the instant of execution. If any component of that path is a symbolic link that has been modified since the approval, the final destination of the cwd changes.

Specifically, the vulnerability exploits the gap between the Check (Approval) and the Use (Execution). Because the system did not lock the filesystem state or enforce the use of a pre-resolved file descriptor, the path name is merely a pointer that can be retargeted. This is particularly dangerous when the path traverses directories where the attacker has write permissions, allowing them to replace a symlink with a new one pointing to a restricted location.

The remediation involves two major architectural changes: creating immutable execution plans and strictly validating path components for mutable symlinks. The fix was introduced in version 2026.2.26.

Vulnerable Logic (Conceptual): Previously, the system likely accepted a request object, displayed it to the user, and upon approval, passed that same object to the execution handler. There was no verification that the path components were immutable.

Patched Logic: The fix introduces hasMutableSymlinkPathComponentSync, which recursively checks every segment of the target path. It ensures that no component is a symbolic link residing in a writable directory. If a path relies on a symlink that the current process user can modify (delete/recreate), it is rejected as unsafe.

Below is the critical validation logic added in src/node-host/invoke-system-run-plan.ts (Commit 78a7ff2d50fb3bcef351571cb5a0f21430a340c1):

// Validation: Ensure no component of the path is a mutable symlink
function hasMutableSymlinkPathComponentSync(targetPath: string): boolean {
  // Iterate through every directory component from root to target
  for (const component of pathComponentsFromRootSync(targetPath)) {
    try {
      // Check if the component is a symlink
      if (!fs.lstatSync(component).isSymbolicLink()) {
        continue;
      }
      // If it is a symlink, check if the PARENT directory is writable
      const parentDir = path.dirname(component);
      if (isWritableByCurrentProcessSync(parentDir)) {
        return true; // REJECT: Attacker could swap this link
      }
    } catch {
      return true; // Fail closed on error
    }
  }
  return false;
}

Additionally, the system now uses a systemRunPlanV2 object (Commit 4b4718c8dfce2e2c48404aa5088af7c013bed60b). This plan is generated during a prepare phase where paths are canonicalized. The execution phase strictly adheres to the prepared plan, rejecting any late-bound parameters that differ from the approved plan.

Exploiting this vulnerability requires the attacker to have write access to a directory used in the cwd path of a requested command. The attack follows a standard race condition pattern against the human-in-the-loop approval mechanism.

Prerequisites:

1. Ability to trigger system.run requests (as an agent or user).
2. Write access to a directory within the proposed cwd path.

Attack Steps:

1. Setup: The attacker creates a directory structure /tmp/exploit/safe_target. They then create a symlink /tmp/exploit/link pointing to /tmp/exploit/safe_target.
2. Request: The attacker requests system.run with the command ls -la and cwd set to /tmp/exploit/link.
3. Deception: The administrator receives the approval request. They inspect /tmp/exploit/link and see it points to a safe, empty directory. They approve the request.
4. The Switch: Immediately after the approval is sent (or during the delay before the agent picks it up), the attacker executes:

   rm /tmp/exploit/link
   ln -s /root /tmp/exploit/link

5. Execution: The OpenClaw Node receives the approved command. It attempts to spawn the process in /tmp/exploit/link. The OS follows the new symlink, executing ls -la inside /root.

This technique allows the attacker to execute commands in any directory on the system, bypassing the administrator's intent to restrict the agent to a sandbox.

The impact of this vulnerability is High, as it completely negates the primary security control (human approval) for agentic actions.

Confidentiality: An attacker can execute read commands (e.g., cat, grep) in sensitive directories like /etc, /root, or source code repositories, exfiltrating secrets, keys, or configuration data.

Integrity: If the command allows file modification (e.g., touch, rm, sed), the attacker can corrupt system files, inject backdoors into startup scripts, or modify application code, provided the OpenClaw process has the necessary OS-level permissions.

Availability: An attacker could execute destructive commands in critical system directories, leading to denial of service.

While the attacker is limited by the permissions of the user running the OpenClaw Node, in many deployment scenarios, agents run with significant privileges to perform their automation tasks. The vulnerability bypasses the logical authorization layer, elevating the risk to the full extent of the process's OS capabilities.

The primary remediation is to upgrade the OpenClaw package to version 2026.2.26 or later. This version enforces immutable approval plans and validates the immutability of symlinks in the path.

Immediate Actions:

• Upgrade: Run npm update openclaw or yarn upgrade openclaw to pull the latest patched version.
• Audit: Review logs for system.run executions that involved paths in temporary directories (e.g., /tmp, /var/tmp) where symlink races are most common.

Defense in Depth:

• Restrict Permissions: Ensure the OpenClaw Node runs with the least privilege necessary. Do not run agents as root.
• Filesystem Hardening: Mount sensitive directories as read-only for the agent process where possible.
• Avoid Temp Dirs: Configure agents to use dedicated, restricted working directories rather than shared, world-writable locations like /tmp for execution contexts.