CVE-2026-100579: OpenClaw before 2026.7.1 Authentication Bypass via Spoofed Requester
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.
Affected Software
Remediation
Recommended actions to resolve this vulnerability, in priority order.
- Upgrade
Upgrade
openclawto a version that resolves this vulnerability.Fixed in 2026.7.1 - Configuration
Restrict message.action to administrators.
OpenClaw Gateway message.action access = administrators only - Configuration
Disable sensitive channel actions that rely on requester identity.
OpenClaw channel actions sensitive channel actions that rely on requester identity = disabled
Event History
Frequently Asked Questions
Which deployments are affected?
Affected deployments use an identity-bearing Gateway authentication mode that honors caller identity and applies narrower operator scopes. Shared-secret token and password callers are full trusted operators under the OpenClaw security model and are out of scope.
What access does an attacker need to exploit this issue?
The attacker needs write-scoped access and must be able to invoke message.action. They can then provide another sender's identifier so channel authorization checks evaluate the spoofed identity rather than the real caller.
What determines the practical impact?
Impact depends on the enabled channel, the action being invoked, and the permissions of the target account whose identifier is spoofed. The flaw can allow operations that the channel adapter would have denied to the real caller.
What can be done if upgrading is not immediately possible?
Restrict message.action to administrators and disable sensitive channel actions that rely on requester identity. Upgrade to version 2026.7.1 to apply the fix.