GHSA-9q36-67vc-rrwg

OpenClaw: Sandboxed /acp spawn requests could initialize host ACP sessions

### Summary Sandboxed requester sessions could reach host-side ACP session initialization through `/acp spawn`. OpenClaw already blocked `sessions_spawn({ runtime: "acp" })` from sandboxed sessions, but the slash-command path initialized ACP directly without applying the same host-runtime guard first. ### Affected Packages / Versions - npm package: `openclaw` - Affected versions: `<= 2026.3.2` - Patched version: `>= 2026.3.7` ### Details ACP sessions run on the host, not inside the OpenClaw sandbox. The direct ACP spawn path in `src/agents/acp-spawn.ts` already denied sandboxed requesters, but `/acp spawn` in `src/auto-reply/reply/commands-acp/lifecycle.ts` called `initializeSession(...)` without first applying the same restriction. In affected versions, an already authorized sender in a sandboxed session could use `/acp spawn` to cross from sandboxed chat context into host-side ACP runtime initialization when ACP was enabled and a backend was available. ### Fix Commit(s) - `61000b8e4ded919ca1a825d4700db4cb3fdc56e3` ### Fix Details The fix introduced a shared ACP runtime-policy guard in `src/agents/acp-spawn.ts` and reused it from the `/acp spawn` handler in `src/auto-reply/reply/commands-acp/lifecycle.ts` before any ACP backend initialization. Regression coverage was added in `src/auto-reply/reply/commands-acp.test.ts` to prove sandboxed `/acp spawn` requests are rejected early, while existing ACP spawn behavior for non-sandboxed sessions remains unchanged. ### Release Process Note Patched version is pre-set to `2026.3.7` so the advisory can be published once that npm release is available. Thanks @tdjackey for reporting.