OpenClaw fixed a medium-severity authorization bypass in version 2026.3.24. A non-owner sender with command privileges could override the owner-only /send command to persistently alter a session’s delivery policy. This scores 5.4 on CVSS v3.1 (AV:N/AC:L/PR:L/UI:N/S:U/C:N/I:L/A:L), tagged CWE-285 for improper authorization.
Update now if you’re on v2026.3.23 or earlier. The flaw affects releases back to at least v2026.1.14-1. Developers verified it in the GitHub tag v2026.3.23 (commit ccfeecb6887cd97937e33a71877ad512741e82b2, published March 23, 2026).
The Flaw
OpenClaw treats the /send on|off|inherit slash command as owner-only, per its docs in docs/tools/slash-commands.md and docs/concepts/session-tool.md. Owners use it to control sendPolicy, which dictates reply delivery in sessions. Admins can also patch it via sessions.patch, a privileged scope.
But the handler in src/auto-reply/reply/commands-session.ts (lines 212-239) only checks if the sender is command-authorized via params.command.isAuthorizedSender. It skips the owner check. Once authorized, it mutates params.sessionEntry.sendPolicy and saves the session entry.
Command auth separates owner status. In src/auto-reply/command-auth.ts, senderIsOwner computes independently (lines 401-407). General auth succeeds even if senderIsOwner === false (lines 420-429). Tests in src/auto-reply/command-auth.owner-default.test.ts confirm this: non-owners run commands.
The vuln traces to a refactor at commit ea018a68ccb92dbc735bc1df9880d5c95c63ca35. It breaks OpenClaw’s privilege model, where session policy counts as sensitive state.
Impact and Why It Matters
A lower-trust sender with command access—for instance, via commands.allowFrom while the owner uses commands.ownerAllowFrom—runs /send unchecked. They disable replies (/send off), re-enable after owner shutdown (/send on), or reset (/send inherit). Changes persist across the session.
No confidentiality loss, no code execution, no sandbox escape. But integrity and availability take hits: suppressed replies disrupt chats, forced re-enables undermine owner control. In multi-party sessions—think team coordination or automated replies—this erodes trust. An adversary with command rights (maybe via misconfig) could sabotage communication without full owner privs.
Medium severity fits. It’s a clear auth bypass on documented owner-only ops, but scoped to one session’s policy. No cross-session or host compromise. Still, in high-stakes setups like secure gateways (src/gateway/method-scopes.ts hints at this), it matters. Misconfigured commands.allowFrom amplifies risk—admins must audit who gets command access.
OpenClaw positions as a session tool with auto-reply and slash commands, likely for chat platforms or bots. If you’re deploying it for controlled environments, this exposes sloppy auth design. Fair fix: the patch enforces owner checks properly. Skeptical note: docs claimed owner-only, code didn’t deliver—classic spec-code gap.
Fix, Versions, and Reproduction
Upgrade to 2026.3.24, the current release. It plugs the gap in handleSendPolicyCommand.
Affected: v2026.1.14-1 through v2026.3.23.
To repro on vulnerable tag:
1. git checkout v2026.3.23
2. Config channel: non-owner commands via `commands.allowFrom`, distinct owner via `commands.ownerAllowFrom`.
3. Start/reuse session with live `sessionEntry`.
4. Non-owner sends `/send off`.
5. Verify `sendPolicy` mutated, persists, replies suppressed.
Run OpenClaw, trigger from non-owner. Session entry updates sans owner auth.
Bottom line: Patch fast if exposed. Review command auth configs. This underscores auditing sender privs in session tools—auth bypasses like this cascade in shared systems.
