GHSA-G8XP-QX39-9JQ9: Arbitrary Code Execution via Environment Variable Injection in OpenClaw Host Execution

OpenClaw operates as a personal AI assistant capable of executing actions on the underlying operating system via its host-exec functionality. This feature relies on a defined trust boundary between the untrusted Large Language Model (LLM) agent and the host system. The application enforces a Host Environment Security Policy to sanitize environment variables before any shell commands requested by the model are executed.

The vulnerability exists in the implementation of this sanitization mechanism. OpenClaw utilizes a negative security model (a denylist) defined in src/infra/host-env-security-policy.json to filter out dangerous environment variables. Prior to version v2026.3.31, this list failed to account for several critical variables used by standard build tools to locate compiler binaries.

This flaw allows a malicious or compromised LLM to perform environment variable injection (CWE-454). By supplying unverified compiler environment variables during a host-exec task, the model can override the path to the executable invoked by tools like Make or CMake.

The successful exploitation of this vulnerability results in arbitrary code execution on the host OS. The malicious code runs with the same privileges as the OpenClaw process, entirely bypassing the intended sandbox restrictions placed on the AI model.

The fundamental root cause is the reliance on an incomplete negative security model for environment variable validation. When OpenClaw receives a command execution request from the LLM, it processes an accompanying set of environment variable overrides. The system checks these overrides against its denylist, discarding any key that matches a known dangerous variable (such as LD_PRELOAD or PATH).

Build automation tools, including Make, CMake, and Cargo, dynamically determine which compiler to invoke by inspecting specific environment variables. For example, Make uses the CC variable to locate the C compiler, while Cargo relies on CARGO_BUILD_RUSTC. The OpenClaw denylist did not include these specific variables.

This omission introduces an Uncontrolled Search Path Element (CWE-427) condition. When the build tool executes a compilation step, it spawns a child process using the binary specified by the injected environment variable. Because the input from the LLM passes through the sanitization check unmodified, the build tool implicitly trusts the malicious path.

Exploitation requires the model to have authorization to utilize the host-exec capability and necessitates the execution of a command that consumes the targeted toolchain variables. The vulnerability manifests at the exact moment the host system attempts to execute the expected toolchain binary.

The vulnerable implementation resided primarily within src/infra/host-env-security-policy.json. This configuration file defined the array of string keys that the runtime application would strip from any execution request originating from the LLM. The absence of CC and similar variables meant the input validation logic explicitly permitted them to pass to the OS layer.

The patch implemented in commit e277a37f896b5011a1df06e6490c6630074d0afa expanded this denylist. The update added several variables specific to C, C++, and Rust build toolchains.

// Added to src/infra/host-env-security-policy.json
[
  "CC",
  "CXX",
  "CARGO_BUILD_RUSTC",
  "CMAKE_C_COMPILER",
  "CMAKE_CXX_COMPILER"
]

Additionally, the patch synchronized these changes with the macOS native bridge located at apps/macos/Sources/OpenClaw/HostEnvSecurityPolicy.generated.swift. This ensures that the native Swift validation logic, which executes commands on the macOS host, shares the exact same policy definitions as the TypeScript application layer.

While this fix successfully remediates the immediate attack vectors involving standard compiler overrides, the underlying architecture remains dependent on a denylist. This approach carries residual risk, as obscure build tools or specific language environments may utilize undocumented environment variables that are not present in the updated configuration file.

Exploitation begins with an attacker injecting a prompt that compels the OpenClaw agent to write a malicious payload to the host filesystem. This payload is typically a shell script containing the attacker's desired arbitrary commands. The script must be marked as executable by the host OS.

Once the payload is present on the disk, the agent initiates a legitimate build command via the host-exec interface. The command request includes an environment variable override that maps a compiler variable to the absolute path of the previously created malicious script.

The host system executes the build tool (e.g., make). When the tool reaches the compilation phase, it reads the injected CC variable. Instead of executing the system's standard C compiler, the tool executes the attacker's shell script. The script runs with the full system privileges of the parent OpenClaw process.

The regression test included in the fix commit demonstrates this precise proof-of-concept:

// Exploit scenario: Setting CC to a malicious script
const exploitPath = path.join(tempDir, "evil-cc");
fs.writeFileSync(exploitPath, `#!/bin/sh\ntouch /tmp/pwned\nexit 1\n`, "utf8");
fs.chmodSync(exploitPath, 0o755);
 
// The model triggers a command like 'make' with an environment override
await runMakeCommand(makePath, tempDir, {
  ...baseEnv,
  CC: exploitPath,
});

Successful exploitation of this vulnerability results in arbitrary code execution on the underlying host operating system. The attacker achieves complete control over the OpenClaw process, inheriting its user permissions, filesystem access, and network capabilities.

The estimated CVSS v3.1 vector for this vulnerability is CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:C/C:H/I:H/A:H, yielding a score of 10.0. The Scope is marked as Changed (S:C) because the exploit allows an untrusted entity (the AI model operating within a restricted context) to compromise the underlying host environment.

This level of access severely compromises both confidentiality and integrity. An attacker can exfiltrate sensitive files, harvest local API keys, or establish persistent access mechanisms on the compromised machine. The availability of the system can also be degraded if the attacker chooses to terminate processes or consume system resources.

For agentic AI frameworks, vulnerabilities of this nature highlight the inherent risks of granting LLMs direct execution capabilities. Flaws in the sanitization boundary amplify the impact of standard prompt injection attacks, elevating them from isolated logical errors to full system compromise.

The primary remediation step is to update the OpenClaw installation to version v2026.3.31 or later. This release contains the updated HostEnvSecurityPolicy which blocks the known set of toolchain environment variables. Administrators must ensure that the update is applied across all active instances, particularly those running the macOS native bridge.

Organizations utilizing OpenClaw should implement robust logging to monitor host-exec requests. Security teams must configure alerts for any execution request originating from the LLM that attempts to supply overrides for variables like CC, CXX, CARGO_BUILD_RUSTC, or PATH. These logs provide essential telemetry for detecting ongoing prompt injection attempts.

To mitigate the risk of zero-day bypasses in the denylist, OpenClaw instances should be deployed within tightly restricted environments. Administrators should containerize the application or utilize robust OS-level sandboxing (such as AppArmor or macOS Sandbox). The host environment should grant the OpenClaw process only the minimum filesystem and network permissions necessary for its intended tasks.

From a development perspective, future iterations of OpenClaw should transition the Host Environment Security Policy from a denylist to a strict allowlist. By exclusively permitting a minimal set of known-safe environment variables, the system can systematically prevent injection attacks regardless of the specific build tools invoked by the model.