CVE-2026-100530 in OpenClaw
Summary
by MITRE • 09/26/2026
OpenClaw versions before 2026.8.1 fail to bind working directory context to reusable exec approvals, allowing approved commands to execute in different directories. Attackers with an allow-always approval can reuse it to run the same command against unreviewed files or repositories with materially different effects.
If you want to get the best quality for vulnerability data then you always have to consider VulDB.
Analysis
by VulDB Data Team • 09/26/2026
The vulnerability identified in OpenClaw versions prior to 2026.8.1 represents a critical failure in context isolation within automated execution environments, specifically affecting how reusable approval tokens are handled during command execution. This flaw stems from the system's inability to bind the working directory context to executable approvals that have been marked for reuse. In secure software design, particularly when dealing with privileged or semi-privileged operations, it is imperative that any authorization token carries not only permission metadata but also strict environmental constraints such as file paths and current working directories. By failing to enforce this binding, OpenClaw allows an approved command template to be detached from its original operational context, creating a significant divergence between the intended scope of approval and the actual execution environment.
From a technical perspective, the core issue lies in the lifecycle management of exec approvals. When a user or automated process requests permission to execute a specific command, OpenClaw generates an approval token that is designed for reuse across multiple instances of similar tasks. However, the implementation neglects to capture and enforce the current working directory at the time of approval creation. Consequently, when this reusable token is invoked later, it executes the underlying binary or script without verifying whether the present working directory matches the one originally reviewed by the administrator or security policy engine. This decoupling means that the command operates in whatever directory context exists at the moment of invocation rather than being sandboxed to its approved origin point.
The operational impact of this vulnerability is severe, particularly for organizations relying on OpenClaw for continuous integration pipelines, automated deployment scripts, or any workflow involving sensitive repository data. An attacker who has obtained an allow-always approval can exploit this lack of context binding to perform path traversal attacks or unintended file modifications. For instance, if a developer approves the execution of a build script in their project root directory, they might inadvertently grant permission for that same command template to be executed against unreviewed files located elsewhere on the filesystem. If an attacker gains control over any part of the pipeline that triggers this reusable approval, they can direct the command toward critical system directories or sensitive repositories where the effects are materially different and potentially destructive compared to the original approved intent.
This vulnerability aligns closely with CWE-20 Improper Input Validation, as the system fails to validate that the execution context matches the expected parameters of the authorization token. Furthermore, it relates to CWE-78 Improper Neutralization of Special Elements used in an OS Command (OS Command Injection) because the attacker can manipulate the environment variables and working directory to alter command behavior beyond its intended scope. In terms of offensive security frameworks, this flaw facilitates techniques associated with MITRE ATT&CK T1059 Command and Scripting Interpreter, specifically allowing for lateral movement or privilege escalation by leveraging trusted binaries in unintended contexts. It also touches upon aspects of T1496 Resource Hijacking if the execution leads to resource exhaustion in unexpected locations, though the primary risk remains unauthorized data access or modification due to context confusion.
Mitigation strategies must focus on enforcing strict contextual binding for all reusable approvals. Developers should modify the approval mechanism to capture and validate the current working directory at the time of token generation and enforce it during every subsequent execution instance. Implementing a chroot environment or using containerized isolation for each approved command can further ensure that even if context validation fails, the blast radius is contained within a predefined boundary. Additionally, adopting a principle of least privilege by limiting reusable approvals to read-only operations where possible reduces the potential impact of such exploitation. Organizations should also audit existing workflows to identify any use cases relying on broad allow-always permissions and replace them with scoped, single-use tokens that expire after execution or are tied explicitly to specific file paths and directories.