GHSA-X3H8-JRGH-P8JX: Execution Allowlist Bypass in OpenClaw via Heredoc Parsing Discrepancies

The openclaw NPM package utilizes an execution approval analyzer designed to validate shell commands against an allowlist. This mechanism serves as a security boundary to prevent the execution of unsafe operations or the exfiltration of sensitive data prior to runtime approval. The analyzer processes input shell commands and attempts to detect unapproved command structures or unauthorized variable expansions.

The vulnerability exists because the parsing engine within the analyzer does not accurately mirror POSIX shell behavior when handling unquoted heredocs (<<EOF). The analyzer relies on regular expressions and simplistic line-by-line evaluation, creating an interpretation conflict (CWE-436) between the validation phase and the execution phase.

Because the analyzer fails to properly account for standard shell expansion rules and line-splicing syntax, attackers can craft payloads that the analyzer deems safe. These same payloads are subsequently interpreted by the underlying shell as commands to expand sensitive environment variables, resulting in a direct bypass of the intended security policy.

The root cause of this vulnerability lies in the implementation of the splitShellPipeline and hasUnquotedHeredocExpansionToken functions within src/infra/exec-approvals-analysis.ts. The implementation suffered from three primary parsing failures regarding POSIX standards.

First, the analyzer exhibited incomplete expansion token detection. The logic exclusively checked for command substitution $(...) and curly-brace expansion ${...}. It failed to account for standard POSIX variable expansions like $VAR, special parameters such as $@ or $$, and arithmetic expansions like $[...].

Second, the analyzer failed to support POSIX line-splicing via trailing backslashes \. The parsing engine evaluated input on a strict physical line basis rather than forming logical lines. This design allowed attackers to split expansion tokens across multiple lines, breaking the regex-based detection mechanisms while remaining perfectly valid for runtime execution.

Third, the heredoc termination logic was fundamentally flawed. The analyzer terminated heredoc processing immediately upon encountering a line that matched the delimiter string. It did not verify whether a continuation backslash from the preceding line appended the delimiter to the current logical line. This discrepancy allowed payloads to prematurely terminate the analyzer's heredoc state while the actual shell continued processing.

The vulnerable code path resided in src/infra/exec-approvals-analysis.ts. The parsing logic processed lines independently and immediately shifted out of the pendingHeredocs queue upon encountering a matching delimiter. The function lacked a stateful buffer to track logical lines formed by line-splicing.

The patch applied in commit b2e8b7d4bb2f22eaa16f5c4b07547774e90b65a5 resolves this by introducing stateful logical line tracking. The developers added unquotedHeredocLogicalChunks and unquotedHeredocLogicalLength variables to buffer physical lines terminating with an unescaped backslash. Analysis for expansion tokens is now deferred until a complete logical line is constructed.

if (line === current.delimiter && unquotedHeredocLogicalChunks.length === 0) {
  pendingHeredocs.shift();
} else {
  const continued = stripUnquotedHeredocLineContinuation(line);
  unquotedHeredocLogicalChunks.push(continued.line);
  // ... length checks ...
  if (!continued.continues) {
    if (hasUnquotedHeredocExpansionToken(unquotedHeredocLogicalChunks.join(""))) {
      return { ok: false, reason: "shell expansion in unquoted heredoc", segments: [] };
    }
    unquotedHeredocLogicalChunks = [];
  }
}

Additionally, the hasUnquotedHeredocExpansionToken check was significantly broadened. It now correctly identifies standard variables, positional parameters, special parameters, and arithmetic expansions. The patch also introduces resource constraints, capping continuations at 1024 lines and logical lengths at 64 KB, protecting the analyzer from resource exhaustion attacks.

Exploiting this vulnerability requires the attacker to submit a crafted shell command to the OpenClaw execution approval workflow. The attacker utilizes an unquoted heredoc combined with line-splicing to evade the allowlist.

The most prominent attack vector involves variable exfiltration. An attacker supplies the following payload:

/usr/bin/cat <<KEY
$OPENAI_API_\
KEY

The vulnerable analyzer reads the first line of the heredoc body as $OPENAI_API_ and determines it contains no restricted tokens. It then reads KEY, identifies it as the delimiter, and terminates heredoc processing. When this approved command executes, the shell splices the line, evaluates $OPENAI_API_KEY, and outputs the secret value.

Attackers can also extract system state data using special parameter exfiltration. By submitting a payload like Internal status: $? or Process ID: $$ inside the heredoc, the analyzer ignores the tokens due to incomplete coverage. The runtime shell expands these tokens, providing the attacker with internal process metadata.

The primary impact of this vulnerability is the compromise of the system's security boundary. The OpenClaw analyzer acts as a gatekeeper against unauthorized command execution. Bypassing this analyzer renders the allowlist ineffective for any payload nested within an unquoted heredoc.

Attackers successfully exploiting this flaw gain the ability to read sensitive environment variables. This typically includes API keys, database credentials, or internal access tokens that the application utilizes. Exfiltration of these secrets facilitates lateral movement and secondary attacks against connected infrastructure.

While the flaw primarily manifests as an information disclosure issue, the execution environment dictates the full scope. If the environment contains commands that evaluate input strings, attackers may achieve arbitrary code execution by leveraging the bypassed expansion outputs.

The vulnerability is remediated in OpenClaw version 2026.4.22. Administrators must upgrade their instances to this version or later to restore the integrity of the execution approval analyzer. The patched version properly tracks logical lines and evaluates standard POSIX variables.

If immediate patching is not feasible, administrators should restrict the use of unquoted heredocs within the OpenClaw environment. Implementing strict validation on input commands via an external Web Application Firewall or proxy can provide temporary mitigation by blocking input containing <EOF or similar heredoc operators.

Security teams should conduct a manual audit of recent execution logs. Any commands approved prior to the patch that utilize heredocs should be reviewed for line-splicing anomalies or suspicious parameter expansions. Additionally, ensure that sensitive environment variables are scoped minimally and are not globally accessible to the OpenClaw execution context.