GHSA-R6QF-8968-WJ9Q: Security Gating Bypass via Off-By-One Logic Error in OpenClaw system.run

OpenClaw incorporates a security feature designed to gate potentially dangerous command executions. The system.run command dispatcher acts as the primary interface for triggering system-level commands. When configured in security=allowlist mode, OpenClaw mandates manual approval for commands that fall outside predefined safe parameters.

To accurately assess incoming commands, the system employs a recursive unwrapping mechanism. This mechanism strips away recognized dispatch wrappers to reveal the underlying command intended for execution. Common wrappers include utilities such as /usr/bin/env or sudo, which modify the execution context without serving as the primary payload.

A logical flaw exists in how the system restricts this unwrapping process. A discrepancy between the command classifier and the execution planner creates an evasion vector. Attackers leverage this discrepancy to execute arbitrary shell commands without triggering the mandatory approval prompt.

The vulnerability stems from an off-by-one boundary condition in the depth-boundary enforcement logic of the system.run command dispatcher. The system restricts recursive unwrapping to a maximum depth defined by the MAX_DISPATCH_WRAPPER_DEPTH constant, which is set to a value of four. This limitation prevents infinite recursion when analyzing nested wrapper sequences.

In the vulnerable implementation, the classification logic utilizes a strict inequality check (depth >= MAX_DISPATCH_WRAPPER_DEPTH) to terminate the unwrapping analysis. When a command sequence reaches exactly four wrappers, the classifier halts its inspection. It fails to evaluate the subsequent element in the sequence, assuming the parsed wrappers constitute the entirety of the executed command.

Because the recognized wrappers exist within the configured allowlist, the classifier determines that the command is safe. It subsequently fails to trigger the ask=on-miss approval prompt. The actual execution planner processes the same wrapper sequence but possesses a more permissive unwrapping threshold, resulting in unverified execution.

The flaw resides within the src/infra/exec-wrapper-resolution.ts file of the OpenClaw repository. The classification function implements a depth check to halt execution wrapper resolution. The original conditional statement improperly terminated the loop at the exact boundary of the depth limit.

// Vulnerable classification logic
if (depth >= MAX_DISPATCH_WRAPPER_DEPTH) {
    return false;
}

This implementation ensures that the fourth wrapper is evaluated, but any element at index five is completely ignored by the security classifier. The execution planner proceeds to unwrap the sequence and execute the payload found at the fifth position. The patch modifies the boundary condition to permit evaluation of the payload element located exactly at the depth boundary.

// Patched code in commit 2fc95a7cfc1eb9306356510b0251b6d51fb1c0b0
if (depth > MAX_DISPATCH_WRAPPER_DEPTH) {
    return false;
}

By replacing the greater-than-or-equal-to operator with a strict greater-than operator, the classifier aligns its depth threshold with the execution planner. The system now correctly evaluates the final element in a four-wrapper sequence, identifies the restricted shell command, and triggers the required approval prompt.

Exploitation of this vulnerability requires the attacker to possess sufficient privileges to invoke the system.run command dispatcher. The target environment must also be operating with the security=allowlist configuration enabled. The attacker does not need elevated system privileges, merely access to the OpenClaw command execution interface.

The attack methodology relies on constructing a payload that perfectly aligns with the MAX_DISPATCH_WRAPPER_DEPTH constant. The attacker prepends exactly four dispatch wrappers to the target shell command. A standard payload utilizes /usr/bin/env as the wrapper to maintain command functionality while incrementing the depth counter.

/usr/bin/env /usr/bin/env /usr/bin/env /usr/bin/env /bin/sh -c "echo PWNED > /tmp/bypass.txt"

When this payload is submitted to the system, the classifier processes the four env wrappers and terminates its analysis. The allowlist gating logic evaluates the env binary as permitted and approves the sequence. The execution planner subsequently unwraps the sequence and executes the /bin/sh payload, granting the attacker unapproved command execution capabilities.

Successful exploitation results in a complete bypass of the allowlist security gating mechanism. An attacker with standard access to the OpenClaw command interface can execute unauthorized system commands. The impact is directly tied to the privileges of the OpenClaw service account.

If OpenClaw operates with administrative or root privileges, the attacker gains full control over the underlying host operating system. The vulnerability effectively neutralizes the primary security control designed to restrict command execution. The system fails to log the event as an unapproved execution attempt, hindering incident response and detection efforts.

The presence of this vulnerability undermines the integrity of environments relying on OpenClaw for secure command delegation. Administrators cannot trust the audit logs generated by the gating system for highly nested commands.

The definitive remediation strategy requires upgrading the OpenClaw installation to version 2026.3.7 or a later release. The patch modifies the unwrapping logic within the core infrastructure components, ensuring consistent behavior between the classifier and execution planner.

If immediate patching is unfeasible, administrators should restrict access to the system.run interface to highly trusted users. The allowlist configuration should not be treated as a primary security boundary for unauthenticated or low-privilege actors. Security teams can monitor process execution logs at the operating system level to detect repetitive invocation of dispatch wrappers.

Detection engineering teams can implement rules to identify sequences containing multiple instances of /usr/bin/env or similar wrapper binaries. Process monitoring solutions should flag command-line arguments exhibiting deep nesting patterns.