GHSA-j9pv-rrcj-6pfx: Insecure Environment Inheritance and Information Disclosure in OpenClaw

OpenClaw is an open-source personal AI assistant that utilizes sandbox environments to execute operations safely. The application architecture relies on SSH-based backends, specifically the ssh-backend and openshell extensions, to manage these isolated operations. The vulnerability resides in how these components handle the underlying system environment when invoking child processes.

The system fails to filter the parent process environment variables before spawning new system commands. Consequently, highly sensitive configuration data necessary for the application's core functionality, such as OPENAI_API_KEY and ANTHROPIC_API_KEY, are inadvertently passed to untrusted subprocesses. This design flaw maps directly to CWE-214 (Invocation of Shell Command with Insecure Environment) and CWE-200 (Exposure of Sensitive Information to an Unauthorized Actor).

Attackers can leverage this exposure to extract these credentials, leading to unauthorized consumption of paid AI services and potential data exposure. The scope of the vulnerability extends to both local system users and, depending on specific configuration parameters, remote entities interacting with the sandboxed environments.

The vulnerability originates from the implementation of the child_process module in Node.js within OpenClaw's sandbox management codebase. When developers invoke child_process.spawn to create processes like ssh or tar, the Node.js runtime defaults to inheriting the entire process.env object if no specific environment is defined. OpenClaw developers explicitly exacerbated this by manually passing the unfiltered process.env object to the env option.

In src/agents/sandbox/ssh-backend.ts and related modules, the parent process holds the critical API keys required to communicate with external AI providers. By supplying the parent environment wholesale to the child process, the security boundary between the management application and the utility subprocess is eliminated. The operating system subsequently allocates a dedicated memory space for the new process and copies the environment variables into it.

Once the environment variables reside within the child process's memory, the operating system tracks them in standard locations, such as the /proc filesystem on Linux. This mechanism ensures that any tool or process with adequate read permissions can access the exact execution state of the command, including the inadvertently shared API keys. The root cause is the absence of an explicit variable sanitization step prior to the execution of untrusted commands.

An analysis of the vulnerable code path in src/agents/sandbox/ssh-backend.ts reveals the explicit passing of the parent environment. The original implementation passed the process.env object directly into the standard spawn options.

// VULNERABLE CODE (Pre-Patch)
const child = spawn(argv[0], argv.slice(1), {
  stdio: ["pipe", "pipe", "pipe"],
  env: process.env, // Direct leakage of all parent variables
  signal: params.signal,
});

The remediation strategy introduced in commit cfe14459531e002a1c61c27d97ec7dc8aecddc1f establishes an explicit filtering mechanism. The developers introduced a utility module named sanitize-env-vars.ts that implements an allow-list or deny-list approach to strip out sensitive keys. The updated spawn invocation processes the environment map before execution.

// PATCHED CODE (v2026.3.31)
import { sanitizeEnvVars } from "../sanitize-env-vars";
 
const sshEnv = sanitizeEnvVars(process.env).allowed;
const child = spawn(argv[0], argv.slice(1), {
  stdio: ["pipe", "pipe", "pipe"],
  env: sshEnv, // Sanitized map with API keys removed
  signal: params.signal,
});

This implementation successfully severs the inheritance chain for specific sensitive credentials. The sanitizeEnvVars function iterates through the parent environment and filters out matches against known high-value targets, such as OPENAI_API_KEY and AWS_SECRET_ACCESS_KEY, ensuring they are omitted from the resulting sshEnv object.

Exploitation of this vulnerability requires the attacker to either maintain local access to the host machine running OpenClaw or to exploit a misconfigured remote SSH server. The local attack vector is trivial. A local user executes standard process monitoring commands to read the environment blocks of active processes.

To verify the vulnerability locally, an attacker observes the process table to identify OpenClaw's subprocesses. Using the pgrep utility, the attacker finds the PID of the targeted ssh process. Subsequently, the attacker reads the /proc/[pid]/environ pseudo-file. Since the variables are null-terminated, piping the output through tr '\0' '\n' renders the sensitive credentials in plain text.

The remote exploitation scenario relies on the host's SSH client configuration. If the SSH client utilizes the SendEnv directive with wildcard matching (e.g., SendEnv *API_KEY), the SSH binary forwards the inherited variables to the remote sandbox. An attacker who has compromised the remote sandbox environment can then extract the keys simply by executing the env command within their active session.

The direct impact of this vulnerability is the complete compromise of the AI service provider credentials configured within OpenClaw. Because OpenClaw relies on services like OpenAI and Anthropic to function, these keys often possess elevated privileges and high rate limits. An attacker obtaining these keys can immediately repurpose them for unauthorized AI workload execution.

The financial implications are significant. AI provider APIs are typically billed by token consumption. Stolen keys used in automated campaigns can incur substantial charges for the victim before the provider detects the anomalous activity and rotates the credentials. Additionally, if the keys grant access to specialized fine-tuned models or custom data endpoints, the attacker gains unauthorized read access to proprietary intellectual property.

The vulnerability is assessed with a base CVSS 3.1 score of 5.5 in environments restricted to local exploitation. However, in deployments where SendEnv actively forwards these variables to untrusted network segments, the CVSS 3.1 score elevates to 8.6, reflecting the remote nature of the exposure and the high confidentiality impact.

The primary remediation for this vulnerability is to upgrade the OpenClaw installation to version v2026.3.31 or later. This release incorporates the sanitizeEnvVars utility, permanently severing the environment inheritance chain for recognized sensitive variables. Administrators should prioritize this update to ensure the environment boundary is correctly maintained.

For systems where immediate patching is not feasible, administrators must apply compensating controls to the SSH configuration. Review the ~/.ssh/config and /etc/ssh/ssh_config files on the host machine running OpenClaw. Remove any SendEnv directives that match sensitive key patterns, such as wildcards that encompass API_KEY or SECRET.

Furthermore, adherence to the principle of least privilege mitigates the local attack vector. Ensure the OpenClaw process runs under a dedicated, unprivileged service account. Restrict local access to the server, preventing unauthorized users from accessing the /proc filesystem and reading the environment data of the OpenClaw service account.