OpenClaw: Matrix room control-command authorization no longer trusts DM pairing-store entries

Summary

Matrix room control-command authorization used the effective allowlist for room traffic, which included sender IDs learned from the Matrix DM pairing store. A sender who was allowed only for a Matrix DM could therefore authorize room control commands when they also posted in a bot room.

Impact

This bypass let a DM-paired Matrix sender cross the DM/room authorization boundary and run Matrix room control commands without being present in the configured room allowlist, room membership list, or group allowlist. The issue required a sender already present in the pairing store and able to send to the target Matrix room. Severity remains high because room control commands can drive privileged OpenClaw behavior depending on the deployment's command and tool policy.

Affected versions

• Affected: > 2026.3.28, < 2026.4.15
• Patched: 2026.4.15

Fix

OpenClaw 2026.4.15 fixes the authorization boundary. Room control-command authorizers now use only configured sender IDs, effective room users, and group allowlists; DM pairing-store entries no longer authorize room commands. A follow-up change also skips DM pairing-store reads on room traffic.

Verified in v2026.4.15:

• extensions/matrix/src/matrix/monitor/access-state.ts builds room command authorizers from commandAllowFrom, which excludes pairing-store sender IDs for room traffic.
• extensions/matrix/src/matrix/monitor/handler.ts gates room control commands through those authorizers.
• extensions/matrix/src/matrix/monitor/access-state.test.ts covers a DM pairing-store sender and verifies it cannot authorize room control commands.

Fix commits included in v2026.4.15 and absent from v2026.4.14:

• f8705f512b09043df02b5da372c33374734bd921 via PR #67294
• 2bfd808a83116bd888e3e2633a61473fa2ed81b6 via PR #67325

Thanks to @nexrin and Keen Security Lab for reporting this issue.