GHSA-2ch6-x3g4-7759

### Summary `commands.allowFrom` is documented as a sender authorization allowlist for commands/directives, but command authorization could include `ctx.From` (conversation identity) as a sender candidate. When `commands.allowFrom` contained conversation-like identifiers (for example Discord `channel:<id>` or WhatsApp group JIDs), command/directive authorization could be granted to participants in that conversation instead of only the intended sender identity. ### Affected Packages / Versions - Package: `openclaw` (npm) - Affected versions: `<= 2026.2.22-2` - Patched version: `2026.2.23` (released) ### Details Root cause: `resolveSenderCandidates()` in `src/auto-reply/command-auth.ts` always included `ctx.From` in candidate evaluation used by `commands.allowFrom` authorization checks. `ctx.From` is sender-like in some direct-message contexts, but conversation-like in channel/group/thread contexts. This mixed principal handling allowed conversation identifiers to satisfy sender-only authorization. ### Impact In affected versions, command/directive authorization could become broader than intended when operators configured `commands.allowFrom` with conversation identifiers, allowing unintended users in that conversation to run command-only/directive-only flows. ### Fix Main branch now treats `commands.allowFrom` as sender-only: - `ctx.From` is no longer included as a general sender candidate. - `ctx.From` is only used as fallback when sender fields are absent and the value is not conversation-shaped. - Regression tests were added for conversation-id denial and direct-message fallback preservation. ### Fix Commit(s) - `08e2aa44e78a9c946d97bea62304e6f533b8fa8e` ### Release Process Note `patched_versions` is pre-set to the released version (`2026.2.23`). This advisory now reflects released fix version `2026.2.23`. OpenClaw thanks @jiseoung for reporting.