CVE-2026-35620

OpenClaw before 2026.3.24 contains missing authorization vulnerabilities in the /send and /allowlist chat command handlers. The /send command allows non-owner command-authorized senders to change owner-only session delivery policy settings, and the /allowlist mutating commands fail to enforce operator.admin scope. Attackers with operator.write scope can invoke /send on|off|inherit to persistently mutate the current session's sendPolicy, and execute /allowlist add commands to modify config-backed allowFrom entries and pairing-store allowlist entries without proper admin authorization.

OpenClaw before 2026.3.24 contains missing authorization vulnerabilities in the /send and /allowlist chat command handlers. The /send command allows non-owner command-authorized senders to change owner-only session delivery policy settings, and the /allowlist mutating commands fail to enforce operator.admin scope. Attackers with operator.write scope can invoke /send on|off|inherit to persistently mutate the current session's sendPolicy, and execute /allowlist add commands to modify config-backed allowFrom entries and pairing-store allowlist entries without proper admin authorization.

Fixed in OpenClaw 2026.3.24, the current shipping release.

Title
Non-owner command-authorized sender can change the owner-only /send session delivery policy

CWE
CWE-285 Improper Authorization

CVSS v3.1
CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:N/I:L/A:L
Base score: 5.4 (Medium)

Severity Assessment
Medium. This is a real owner-only authorization bypass, but the demonstrated impact is limited to persistent mutation of the current session’s delivery policy rather than direct code execution, sandbox escape, or cross-host compromise.

Impact
A non-owner sender who is allowed to run commands can invoke /send on|off|inherit and persistently change the current session’s sendPolicy, even though OpenClaw documents /send as owner-only.

That lets a lower-trust participant:

• disable reply delivery for the current session (/send off), suppressing future replies in that chat;
• re-enable reply delivery (/send on) after the owner intentionally disabled it;
• remove the session override (/send inherit).

Affected Component
Verified against the latest published GitHub release tag v2026.3.23 (ccfeecb6887cd97937e33a71877ad512741e82b2), published 2026-03-23T23:15:50Z.

Exact vulnerable path on the shipped tag:

• src/auto-reply/reply/commands-session.ts:212-239
  • handleSendPolicyCommand(...) checks only params.command.isAuthorizedSender.
  • when true, it mutates params.sessionEntry.sendPolicy and persists the session entry.

Authorization behavior that makes this reachable:

• src/auto-reply/command-auth.ts:401-407
  • senderIsOwner is computed separately from general command authorization.
• src/auto-reply/command-auth.ts:420-429
  • command authorization can succeed even when senderIsOwner === false.
• src/auto-reply/command-auth.owner-default.test.ts:10-47
  • existing coverage confirms a sender can be command-authorized while not treated as owner.

Documented owner-only contract:

• docs/tools/slash-commands.md:112
  • /send on|off|inherit is documented as owner-only.
• docs/concepts/session-tool.md:156
  • sendPolicy is documented as settable via sessions.patch or owner-only /send on|off|inherit.

Related privilege model:

• src/gateway/method-scopes.ts:131-133
  • sessions.patch is admin-scoped, which reinforces that session-delivery-policy mutation is treated as privileged state.

Version history:

• The vulnerable handler exists in release history going back at least to commit ea018a68ccb92dbc735bc1df9880d5c95c63ca35 (refactor(auto-reply): split reply pipeline).
• Earliest released affected tag found: v2026.1.14-1
• Latest released affected tag verified: v2026.3.23

Technical Reproduction

1. Check out the shipped release tag v2026.3.23.
2. Configure a channel where:
   • a non-owner sender is allowed to run commands, for example through commands.allowFrom;
   • the owner identity is distinct, for example via commands.ownerAllowFrom.
3. Start or reuse a session with a live sessionEntry and sessionStore.
4. Send /send off as the non-owner but command-authorized sender.
5. Confirm the resolved command context has:
   • isAuthorizedSender === true
   • senderIsOwner === false
6. Observe that the handler still accepts the command, mutates sessionEntry.sendPolicy, and persists the session entry.

Demonstrated Impact
The vulnerable handler performs a real persistent session-state change:

• src/auto-reply/reply/commands-session.ts:232-238
  • /send inherit deletes sessionEntry.sendPolicy
  • other modes assign sessionEntry.sendPolicy = sendPolicyCommand.mode
  • the handler then calls persistSessionEntry(params)

The mutation is not gated by owner status, only by general command authorization.

That changes subsequent delivery behavior for the current session, which matches the documented meaning of sendPolicy.

Environment

• Product: OpenClaw
• Verified shipped tag: v2026.3.23
• Shipped tag…

OpenClaw before 2026.3.24 contains missing authorization vulnerabilities in the /send and /allowlist chat command handlers. The /send command allows non-owner command-authorized senders to change owner-only session delivery policy settings, and the /allowlist mutating commands fail to enforce operator.admin scope. Attackers with operator.write scope can invoke /send on|off|inherit to persistently mutate the current session's sendPolicy, and execute /allowlist add commands to modify config-backed allowFrom entries and pairing-store allowlist entries without proper admin authorization.

OpenClaw before 2026.3.24 contains missing authorization vulnerabilities in the /send and /allowlist chat command handlers. The /send command allows non-owner command-authorized senders to change owner-only session delivery policy settings, and the /allowlist mutating commands fail to enforce operator.admin scope. Attackers with operator.write scope can invoke /send on|off|inherit to persistently mutate the current session's sendPolicy, and execute /allowlist add commands to modify config-backed allowFrom entries and pairing-store allowlist entries without proper admin authorization.

Fixed in OpenClaw 2026.3.24, the current shipping release.

Title
Non-owner command-authorized sender can change the owner-only /send session delivery policy

CWE
CWE-285 Improper Authorization

CVSS v3.1
CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:N/I:L/A:L
Base score: 5.4 (Medium)

Severity Assessment
Medium. This is a real owner-only authorization bypass, but the demonstrated impact is limited to persistent mutation of the current session’s delivery policy rather than direct code execution, sandbox escape, or cross-host compromise.

Impact
A non-owner sender who is allowed to run commands can invoke /send on|off|inherit and persistently change the current session’s sendPolicy, even though OpenClaw documents /send as owner-only.

That lets a lower-trust participant:

• disable reply delivery for the current session (/send off), suppressing future replies in that chat;
• re-enable reply delivery (/send on) after the owner intentionally disabled it;
• remove the session override (/send inherit).

Affected Component
Verified against the latest published GitHub release tag v2026.3.23 (ccfeecb6887cd97937e33a71877ad512741e82b2), published 2026-03-23T23:15:50Z.

Exact vulnerable path on the shipped tag:

• src/auto-reply/reply/commands-session.ts:212-239
  • handleSendPolicyCommand(...) checks only params.command.isAuthorizedSender.
  • when true, it mutates params.sessionEntry.sendPolicy and persists the session entry.

Authorization behavior that makes this reachable:

• src/auto-reply/command-auth.ts:401-407
  • senderIsOwner is computed separately from general command authorization.
• src/auto-reply/command-auth.ts:420-429
  • command authorization can succeed even when senderIsOwner === false.
• src/auto-reply/command-auth.owner-default.test.ts:10-47
  • existing coverage confirms a sender can be command-authorized while not treated as owner.

Documented owner-only contract:

• docs/tools/slash-commands.md:112
  • /send on|off|inherit is documented as owner-only.
• docs/concepts/session-tool.md:156
  • sendPolicy is documented as settable via sessions.patch or owner-only /send on|off|inherit.

Related privilege model:

• src/gateway/method-scopes.ts:131-133
  • sessions.patch is admin-scoped, which reinforces that session-delivery-policy mutation is treated as privileged state.

Version history:

• The vulnerable handler exists in release history going back at least to commit ea018a68ccb92dbc735bc1df9880d5c95c63ca35 (refactor(auto-reply): split reply pipeline).
• Earliest released affected tag found: v2026.1.14-1
• Latest released affected tag verified: v2026.3.23

Technical Reproduction

1. Check out the shipped release tag v2026.3.23.
2. Configure a channel where:
   • a non-owner sender is allowed to run commands, for example through commands.allowFrom;
   • the owner identity is distinct, for example via commands.ownerAllowFrom.
3. Start or reuse a session with a live sessionEntry and sessionStore.
4. Send /send off as the non-owner but command-authorized sender.
5. Confirm the resolved command context has:
   • isAuthorizedSender === true
   • senderIsOwner === false
6. Observe that the handler still accepts the command, mutates sessionEntry.sendPolicy, and persists the session entry.

Demonstrated Impact
The vulnerable handler performs a real persistent session-state change:

• src/auto-reply/reply/commands-session.ts:232-238
  • /send inherit deletes sessionEntry.sendPolicy
  • other modes assign sessionEntry.sendPolicy = sendPolicyCommand.mode
  • the handler then calls persistSessionEntry(params)

The mutation is not gated by owner status, only by general command authorization.

That changes subsequent delivery behavior for the current session, which matches the documented meaning of sendPolicy.

Environment

• Product: OpenClaw
• Verified shipped tag: v2026.3.23
• Shipped tag…