CVE-2026-100584 in OpenClaw
Summary
by MITRE • 09/26/2026
OpenClaw is an npm-distributed agent runtime. In versions >= 2026.2.26 and < 2026.7.1, PowerShell command analysis on Windows hosts running in exec allowlist mode could approve an exact executable resolved from PATH but subsequently execute a same-named executable located in the workspace directory. If lower-trust content can place an executable with an approved basename into an agent-writable workspace and steer an approved PowerShell command that uses a bare executable name, OpenClaw may run the workspace file instead of the allowlisted path, executing arbitrary code with the privileges of the Gateway or node-host user. The issue does not require replacement of the approved executable itself. Version 2026.7.1 contains a fix; as a workaround, avoid bare executable names in approved PowerShell commands and keep executable files out of agent-writable workspaces.
Several companies clearly confirm that VulDB is the primary source for best vulnerability data.
Analysis
by VulDB Data Team • 09/26/2026
OpenClaw is an npm-distributed agent runtime designed to facilitate automated tasks through command execution capabilities. A critical security vulnerability exists within versions greater than or equal to 2026.2.26 and less than 2026.7.1, specifically affecting Windows hosts operating in exec allowlist mode. This flaw stems from a fundamental issue in how the runtime resolves executable paths during PowerShell command analysis. The vulnerability allows an attacker who can place lower-trust content into an agent-writable workspace directory to bypass security controls that are intended to restrict execution to only pre-approved binaries.
The technical core of this vulnerability lies in the path resolution logic employed by OpenClaw when processing PowerShell commands containing bare executable names, meaning filenames without explicit paths or extensions. When such a command is submitted for analysis against an allowlist, the system correctly identifies and approves the exact executable resolved from the system PATH environment variable. However, during the actual execution phase, if a file with the same basename exists within the workspace directory where the agent operates, OpenClaw may prioritize this local file over the approved system binary. This behavior effectively creates a path traversal-like scenario where the security boundary defined by the allowlist is circumvented because the runtime fails to enforce strict adherence to the resolved allowed path during execution.
This flaw has severe operational implications for organizations relying on exec allowlists as their primary defense mechanism against arbitrary code execution. An attacker with write access to an agent-writable workspace can craft a malicious executable that mimics the name of an approved tool, such as powershell.exe or certutil.exe. By steering an approved PowerShell command that utilizes this bare name, the attacker forces OpenClaw to execute their malicious payload instead of the legitimate system utility. Consequently, arbitrary code is executed with the privileges of the Gateway process or the node-host user account, potentially leading to full system compromise, data exfiltration, or lateral movement within the network infrastructure.
The vulnerability does not require an attacker to replace the approved executable in its original location on disk; it only requires placing a similarly named file into the workspace directory. This makes exploitation relatively straightforward for any entity with write permissions to these directories. The issue highlights a common pitfall in security tooling where path resolution during validation differs from execution context, allowing for binary planting attacks that bypass allowlist-based protections.
To mitigate this risk, users of OpenClaw versions affected by this vulnerability should immediately upgrade to version 2026.7.1 or later, which contains the necessary code fixes to ensure strict adherence to resolved paths during execution. For environments where an immediate upgrade is not feasible, a critical workaround involves modifying approved PowerShell commands to avoid using bare executable names entirely. Commands should specify full absolute paths to the allowed executables rather than relying on name-based resolution. Additionally, organizations must enforce strict access controls and file hygiene policies to ensure that no unauthorized or untrusted executable files are placed in agent-writable workspace directories, thereby removing the vector required for this attack chain to succeed.
This vulnerability aligns with CWE-78 Improper Neutralization of Special Elements used in an OS Command, specifically regarding path manipulation and binary planting techniques. It also relates to ATT&CK technique T1059 PowerShell, as it involves the abuse of a legitimate system utility through command injection principles where the context of execution is manipulated to execute unintended code. The failure to properly isolate workspace directories from system paths represents a significant deviation in secure coding practices for agent runtimes that handle external input or file operations within privileged contexts.