GHSA-JJ82-76V6-933R: Execution Allowlist Bypass via Wrapper Injection in OpenClaw

OpenClaw, an open-source multi-channel AI gateway, implements an "exec approvals" and "allowlist" system designed to restrict which binaries the platform can execute on the host machine. This mechanism is critical for preventing the AI agent from performing unauthorized system operations or executing arbitrary code.

The vulnerability, identified as GHSA-JJ82-76V6-933R, resides in the logic used to validate these execution requests. The system performed a "shallow" analysis, validating only the primary executable (the first element of the command array) against the defined policy. It failed to inspect subsequent arguments, which is a critical oversight when dealing with wrapper binaries or shell dispatchers.

This flaw allows an attacker to "smuggle" unauthorized commands through the allowlist. If the policy permits a generic wrapper—such as /usr/bin/env, bash, or powershell—an attacker can invoke that permitted binary and pass a malicious payload as an argument. The system correctly identifies the wrapper as allowed but unknowingly executes the hidden payload, resulting in a complete bypass of the execution sandbox.

The root cause of this vulnerability is CWE-693: Protection Mechanism Failure, specifically stemming from CWE-20: Improper Input Validation within the resolveCommandResolutionFromArgv function.

The "Shallow" Check

Prior to version 2026.2.23, OpenClaw's validation logic operated on a simple premise: if argv[0] is in the safeBins list, the execution is safe. This logic ignores the operational semantics of command-line utilities. Many binaries, particularly shells and environment setters, are designed specifically to execute other programs defined in their arguments.

The env Vector

The /usr/bin/env utility is a prime example of this vector. Its primary purpose is to run a command in a modified environment. When OpenClaw receives a command array like ['/usr/bin/env', 'sh', '-c', 'malicious_script'], the validator only inspects index 0 (/usr/bin/env). If env is whitelisted (a common configuration for setting up runtime environments), the check passes. The operating system then executes env, which immediately hands control over to sh, executing the malicious script. The allowlist is effectively rendered moot because the security boundary does not extend to the semantic payload of the command.

The remediation involved a significant architectural change to how commands are resolved before validation. The fix was implemented in commit 2b63592be57782c8946e521bc81286933f0f99c7.

Before the Fix

The vulnerable logic roughly resembled this simplified flow:

// Vulnerable Logic
function validate(argv: string[]) {
  const executable = argv[0];
  if (allowlist.includes(executable)) {
    return true; // Vulnerable: Returns true without checking argv[1..n]
  }
  return false;
}

After the Fix

The patch introduces a recursive unwrapper, unwrapDispatchWrappersForResolution, which "peels" back layers of known dispatchers to find the effective executable. This logic is implemented in both TypeScript and Swift.

// Patched Logic (Conceptual)
function unwrapDispatchWrappersForResolution(argv: string[], depth = 0): string[] {
  // 1. Recursion limit to prevent DOS
  if (depth > 4) return argv;
 
  const cmd = argv[0];
  
  // 2. Check if the command is a known wrapper (env, bash, sh, etc.)
  if (isWrapper(cmd)) {
    // 3. Parse arguments to find the next command in the chain
    // e.g., for "env VAR=VAL cmd", skip VAR=VAL to find "cmd"
    const nextCommand = parseWrapperArgs(argv);
    
    // 4. Recursively resolve the next command
    return unwrapDispatchWrappersForResolution(nextCommand, depth + 1);
  }
 
  return argv;
}

The fix explicitly handles a wide range of shells (bash, zsh, fish, powershell, cmd.exe) and the env utility. It parses flags like -c (execute string) and handles environment variable assignments in env calls to locate the true target binary.

To exploit this vulnerability, an attacker requires the ability to trigger a command execution flow, such as through a system.run tool call or an authenticated API request to the Gateway. The attack relies on the presence of a "living off the land" binary in the allowlist.

Attack Scenario

1. Reconnaissance: The attacker identifies that /usr/bin/env or a shell like /bin/bash is present in the safeBins allowlist.
2. Payload Construction: The attacker constructs a JSON payload where the allowed binary is the entry point, but the actual malicious logic is passed as an argument.

Example Payload:

{
  "tool": "system.run",
  "args": [
    "/usr/bin/env",      // Allowed binary
    "python3",           // Forbidden binary (smuggled)
    "-c",
    "import os; os.system('cat /etc/passwd')"
  ]
}

3. Execution: The OpenClaw engine validates /usr/bin/env, approves the request, and spawns the process. env then executes python3, which executes the Python code, effectively bypassing the restriction on python3.

> [!NOTE] > This technique is effective even against strict allowlists if any dispatcher is permitted. A common misconfiguration is allowing bash to run legitimate maintenance scripts, which inadvertently opens the door to arbitrary script execution via bash -c.

The impact of this vulnerability is Remote Code Execution (RCE), dependent on the contents of the allowlist. While the CVSS score is 6.6 (Medium/High) due to the requirement of an allowed wrapper, the practical impact in default or common configurations is critical.

Confidentiality: An attacker can read sensitive files (SSH keys, configuration secrets) accessible to the OpenClaw process user. Integrity: An attacker can modify system files, install persistence mechanisms, or alter the behavior of the AI agent. Availability: An attacker can crash the service or consume system resources (e.g., fork bombs).

Since OpenClaw often runs with access to internal networks or sensitive data APIs, a breach here can serve as a pivot point for lateral movement within the infrastructure.

Users must upgrade to OpenClaw version 2026.2.23 or later immediately. The patch implements the recursive logic necessary to inspect nested commands.

Configuration Hardening

Even with the patch, relying on software logic to parse complex shell arguments can be fragile. Administrators should adopt a "Defense in Depth" approach:

1. Minimize the Allowlist: Remove generic wrappers (env, bash, sh, cmd.exe) from safeBins. Only allowlist specific, single-purpose binaries.
2. Use Sandbox Mode: Enable the platform's Sandbox Mode for public-facing agents. This provides containerization or isolation layers beyond simple binary allowlisting.
3. Audit Existing Policies: Review current execution policies for over-permissive entries using the new openclaw security audit command available in the patched version.

> [!WARNING] > The patch has a known limitation: it only recurses 4 levels deep. Extremely complex nested chains (e.g., env env env env env cmd) might still theoretically bypass the check, although this is an edge case. Strict allowlisting remains the most robust defense.