GHSA-mqpw-46fh-299h OpenClaw authorization bypass: operator.write can resolve exec approvals via chat.send -> /approve

• npm openclaw: < 2026.2.2 → fixed in 2026.2.2

Summary What this means (plain language) If you give a client “chat/write” access to the gateway (`operator.write`) but you do not intend to let that client approve exec requests (`operator.approvals`), affected versions could still let that client approve/deny a pending exec approval by sending the `/approve` chat command. This is mainly relevant for shared or multi-client setups where different tokens are intentionally scoped differently. Single-operator installs are typically less impacted. Technical summary A gateway client authenticated with a device token scoped only to `operator.write` (without `operator.approvals`) could approve/deny pending exec approval requests by sending a chat message containing the built-in `/approve` command. `exec.approval.resolve` is correctly scoped to `operator.approvals` for direct RPC calls, but the `/approve` command path invoked it via an internal privileged gateway client. Affected Packages / Versions • `openclaw` (npm): `= 2026.2.2`. • If you cannot upgrade: avoid issuing write-only device tokens to untrusted clients; disable text commands (`commands.text=false`) or restrict access to the webchat/control UI. References • Fix: `src/auto-reply/reply/commands-approve.ts` • Coverage: `src/auto-reply/reply/commands-approve.test.ts` Release Process Note This advisory is kept in draft; once the fixed npm versions are available, it can be published without further edits. Thanks @yueyueL for reporting.