GHSA-2gvc-4f3c-2855

## 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.