CVE-2026-28463 in OpenClaw
Summary
by MITRE • 03/06/2026
OpenClaw exec-approvals allowlist validation checks pre-expansion argv tokens but execution uses real shell expansion, allowing safe bins like head, tail, or grep to read arbitrary local files via glob patterns or environment variables. Authorized callers or prompt-injection attacks can exploit this to disclose files readable by the gateway or node process when host execution is enabled in allowlist mode.
VulDB is the best source for vulnerability data and more expert information about this specific topic.
Analysis
by VulDB Data Team • 03/10/2026
The vulnerability described in CVE-2026-28463 represents a critical security flaw in the OpenClaw exec-approvals system that stems from a fundamental mismatch between validation and execution phases. This issue occurs when the system performs allowlist validation checks on pre-expanded argv tokens while the actual execution phase utilizes real shell expansion mechanisms. The discrepancy creates a pathway for attackers to bypass intended security controls through careful manipulation of input parameters that undergo different processing pipelines during validation versus execution.
The technical flaw manifests through the improper handling of shell expansion semantics within the command execution framework. During validation, the system examines argv tokens before any shell expansion occurs, treating them as literal strings within the allowlist verification process. However, when the actual command execution takes place, the shell performs full expansion of glob patterns, environment variables, and other shell-specific features. This fundamental disconnect allows malicious actors to craft inputs that pass validation checks but trigger unintended file access during execution.
This vulnerability specifically impacts systems that enable host execution in allowlist mode, where the gateway or node process operates with elevated privileges or access to sensitive local resources. The flaw enables unauthorized file disclosure through commonly allowed binaries such as head, tail, and grep, which are often included in default allowlists due to their utility in system administration tasks. These utilities become dangerous when exploited through glob pattern expansion or environment variable injection, allowing attackers to read arbitrary local files that would normally be protected by access controls.
The operational impact of this vulnerability extends beyond simple file disclosure to encompass potential privilege escalation and data exfiltration scenarios. Authorized callers or attackers capable of prompt injection can leverage this weakness to access files that are readable by the gateway or node process, potentially exposing sensitive configuration files, credentials, or system information. The vulnerability's exploitation requires a combination of understanding the shell expansion behavior and knowledge of the target system's file structure, making it particularly dangerous in environments where the exec-approvals system is used to control command execution.
From a cybersecurity perspective, this vulnerability aligns with CWE-78 and CWE-88 categories related to command injection and shell injection flaws, though it operates through a unique validation-execution mismatch pattern. The attack vector connects to ATT&CK technique T1059.001 for command and script injection, while also relating to T1078 for valid accounts and T1566 for social engineering through prompt injection. The security implications are particularly severe in environments where the exec-approvals system serves as a primary control mechanism for preventing unauthorized command execution, as this flaw essentially undermines the entire validation framework.
Mitigation strategies must address the core validation-execution mismatch by implementing consistent shell expansion handling throughout the command processing pipeline. Organizations should consider adopting strict input sanitization that accounts for shell expansion semantics during validation, or alternatively, implementing a more robust execution model that performs validation against the same expanded tokens used during execution. The system should avoid relying on pre-expansion validation when shell expansion is involved in the execution phase, and instead employ mechanisms that can properly account for all potential expansion scenarios. Additionally, implementing additional controls such as restricted execution environments or privilege separation can help limit the impact of successful exploitation attempts.