GHSA-FG3M-VHRR-8GJ6: Critical Command Injection in OpenClaw Lobster Extension via Windows Shell Fallback

The OpenClaw platform utilizes an extension architecture to integrate external tools. The "Lobster" extension specifically wraps the lobster CLI tool to perform pipeline operations. On Windows environments, npm packages are typically installed with .cmd or .bat wrapper scripts (shims) to make them executable from the command line. However, Node.js's child_process.spawn function cannot execute these batch files directly without a shell interpreter, often resulting in ENOENT or EINVAL errors when shell: false is set.

To mitigate these execution failures, the OpenClaw developers implemented a fallback mechanism. If the initial spawn attempt fails on Windows, the code catches the error and retries the execution with shell: true. While this allows the .cmd shim to run, it fundamentally changes how arguments are parsed. When shell: true is active, Node.js invokes cmd.exe /d /s /c <command>, passing the arguments as a single string to the Windows command interpreter.

This architectural decision creates a classic Command Injection vulnerability (CWE-78). Because the arguments passed to the shell include user-supplied data—specifically the pipeline name and configuration JSON—an attacker can craft inputs containing shell metacharacters (such as &, |, or >). The shell interpreter processes these characters before executing the intended command, allowing the attacker to break out of the argument context and execute arbitrary system commands.

The root cause lies in the unsafe error handling logic within extensions/lobster/src/lobster-tool.ts. The application prioritizes functional stability (successfully running the command) over security boundaries by dynamically enabling shell execution without sanitization.

The vulnerable logic follows this sequence:

1. Initial Attempt: The system attempts to spawn the executable path using spawn(path, argv, { shell: false }). This is the secure default in Node.js, as it passes arguments directly to the kernel as an array, bypassing the shell.
2. Failure Condition: On Windows, if path points to a .cmd script (common for npm global installs), the operating system fails to execute it directly, throwing an error.
3. Insecure Fallback: The code catches this specific error and re-invokes spawn with the shell: true option enabled.

By switching to shell: true, the application delegates argument parsing to cmd.exe. In this mode, the distinction between code (the executable) and data (the arguments) is lost. The command line is constructed by concatenating the executable and arguments into a string. If the arguments contain unescaped metacharacters, cmd.exe interprets them as control operators rather than literal string data. This allows an attacker to append malicious commands that the shell executes alongside the original process.

The following analysis highlights the transition from the vulnerable fallback logic to the robust shim parsing implemented in the patch.

Vulnerable Code (Pre-Patch)

In the unpatched version, the code explicitly enables the shell if the platform is Windows and a previous error occurred. Note the useShell variable which toggles the dangerous behavior.

// extensions/lobster/src/lobster-tool.ts
 
// 1. Initial spawn attempt configuration
const child = spawn(execPath, argv, {
  cwd,
  stdio: ["ignore", "pipe", "pipe"],
  env,
  shell: useShell, // DANGER: This becomes true in the fallback path
  windowsHide: useShell ? true : undefined,
});
 
// 2. The insecure fallback logic
child.on('error', async (err) => {
  if (process.platform === "win32" && isWindowsSpawnErrorThatCanUseShell(err)) {
    // If spawn failed, retry with shell: true
    return await runLobsterSubprocessOnce(params, true);
  }
});

Patched Code

The fix removes the fallback entirely. Instead, it implements resolveWindowsLobsterSpawn, which locates the actual Node.js script behind the .cmd shim and executes it directly using the current process.execPath. This maintains shell: false integrity.

// extensions/lobster/src/lobster-tool.ts (Patched)
 
// 1. Resolve the actual script entry point to avoid using shell
const { execPath: finalExecPath, args: finalArgs } = 
  await resolveWindowsLobsterSpawn(execPath, argv);
 
// 2. Spawn without shell, ensuring arguments are treated as data
const child = spawn(finalExecPath, finalArgs, {
  cwd,
  stdio: ["ignore", "pipe", "pipe"],
  env,
  shell: false, // SAFE: Shell is strictly disabled
  windowsHide: false,
});

The resolveWindowsLobsterSpawn function parses the batch file to extract the target script path, allowing OpenClaw to invoke node.exe <script> directly, bypassing the need for cmd.exe processing.

To exploit this vulnerability, an attacker requires authentication with sufficient privileges to invoke the Lobster tool (typically a standard user role). The attack targets the pipeline parameter in the tool invocation request.

Prerequisites

1. Target OS: The OpenClaw instance must be running on Windows.
2. Configuration: The configured path for the Lobster tool must point to a .cmd or .bat file (default behavior for npm installations) to trigger the spawn error and subsequent fallback.

Attack Vector

The attacker sends a crafted HTTP POST request to the tools API. The payload injects the & operator, which tells cmd.exe to execute the preceding command and then execute the following command.

POST /api/tools/invoke HTTP/1.1
Host: target-openclaw.local
Content-Type: application/json
Authorization: Bearer <user_token>
 
{
  "tool": "lobster",
  "action": "run",
  "pipeline": "dummy_pipeline & net user hacked P@ssw0rd123 /add",
  "argsJson": "{}"
}

When the vulnerable code executes this via cmd.exe /c, the effective command line becomes: lobster.cmd run dummy_pipeline & net user hacked P@ssw0rd123 /add

The system executes the Lobster tool (which may fail or run harmlessly) and immediately executes the net user command, creating a new local administrator account. Other payloads could include powershell reverse shells or data exfiltration commands.

The impact of this vulnerability is critical, categorized as CVSS 9.9. The successful exploitation results in Remote Code Execution (RCE) with the privileges of the OpenClaw service account.

Confidentiality: High. An attacker can read any file accessible to the OpenClaw process, including configuration files, environment variables containing secrets, and source code.

Integrity: High. The attacker can modify application data, overwrite system files, or install persistent backdoors (e.g., creating new users, scheduling tasks).

Availability: High. The attacker can crash the service, delete critical files, or shut down the host system, resulting in a complete denial of service.

Scope (Changed): The vulnerability is classified as Scope: Changed (S:C) because the vulnerable component (the OpenClaw application) allows the attacker to affect resources beyond its own security authority—specifically, the underlying Windows operating system. This significantly elevates the risk profile compared to a contained application compromise.

The vulnerability is addressed in OpenClaw version 2026.2.23-beta.1. The patch replaces the dangerous shell fallback with a secure mechanism for resolving Windows shims.

Immediate Action: Administrators should upgrade to the patched version immediately via npm:

npm update -g openclaw

Verification: After upgrading, ensure the running version matches 2026.2.23-beta.1 or higher. Check the package.json or the application's version output.

Alternative Mitigation: If an immediate upgrade is not feasible, administrators can manually configure the lobsterPath setting to point directly to the node executable and the target JavaScript file, or an .exe binary, bypassing the .cmd shim. This prevents the initial spawn failure that triggers the vulnerable fallback path. However, this configuration change is complex and error-prone; patching is the strongly recommended solution.