CVE-2026-100579 in OpenClaw
Summary
by MITRE • 09/26/2026
OpenClaw (npm package 'openclaw') before 2026.7.1 incorrectly trusts requester provenance in message.action. In identity-bearing Gateway deployments (authentication modes that honor caller identity and narrower operator scopes), a write-scoped caller can supply another sender's identifier to the channel authorization checks and invoke a channel action under that spoofed requester identity, reaching operations the channel adapter would have denied to the real caller. Practical impact depends on the enabled channel, the action, and the target account's permissions. Shared-secret token and password callers are full trusted operators under OpenClaw's security model and are out of scope. The issue is fixed in 2026.7.1; as a workaround, restrict message.action to administrators and disable sensitive channel actions that rely on requester identity.
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 the OpenClaw npm package prior to version 2026.7.1 represents a critical failure in access control logic within identity-bearing Gateway deployments. This flaw stems from an incorrect trust model regarding the provenance of incoming requests, specifically concerning how caller identities are validated during channel authorization checks. In security architectures that honor caller identity and enforce narrower operator scopes, it is imperative that the system verifies not only whether a user has permission to perform an action but also ensures that they are acting under their own verified identity rather than impersonating another entity. The vulnerability allows authenticated users with write-scoped permissions to manipulate the message.action field by supplying identifiers belonging to other senders. This manipulation effectively bypasses the intended authorization boundaries, enabling these callers to invoke channel actions as if they were different, potentially more privileged or differently scoped, entities.
From a technical perspective, this issue is classified under CWE-287, which covers Improper Authentication, and specifically relates to identity impersonation within application logic rather than network-level spoofing. The attack vector involves the modification of input data that directly influences security decisions made by the gateway. By injecting another sender's identifier into the authorization check mechanism, an attacker can trick the system into granting access based on the permissions associated with the spoofed identity. This bypasses the principle of least privilege and undermines the integrity of the role-based or attribute-based access control models implemented in these deployments. The operational impact is contingent upon several factors including the specific channel adapter enabled, the nature of the action being invoked, and the permission levels assigned to the target account associated with the spoofed identity. In scenarios where sensitive operations rely heavily on requester identity for security enforcement, this flaw can lead to unauthorized data access, modification, or deletion depending on what actions are exposed through the compromised channels.
It is important to note that OpenClaw's security model treats callers authenticating via shared-secret tokens and passwords as fully trusted operators. Consequently, these authentication methods fall outside the scope of this vulnerability because they do not rely on the same identity verification mechanisms susceptible to spoofing in other modes. The risk is primarily isolated to deployments utilizing identity-bearing gateway configurations where caller identity plays a central role in authorization decisions. This distinction highlights that while some parts of the system remain robust, specific architectural choices regarding authentication and identity propagation can introduce significant risks if not carefully implemented and validated.
To mitigate this vulnerability, organizations should immediately upgrade OpenClaw to version 2026.7.1 or later, which contains the necessary code corrections to properly validate requester provenance. For environments where an immediate upgrade is not feasible, a recommended workaround involves restricting access to message.action fields exclusively to administrators who possess higher-level privileges and are less likely to be targeted by lower-privilege attackers attempting privilege escalation via identity spoofing. Additionally, disabling sensitive channel actions that depend on accurate requester identification can reduce the attack surface. These measures help ensure that only authorized entities with verified identities can perform critical operations, thereby restoring the integrity of the access control framework. Security teams should also review their deployment configurations to ensure that no unnecessary channels or actions remain exposed in production environments, aligning with industry best practices for minimizing potential impact from such logic flaws.