[MEDIUM] Security Advisory: OpenClaw: Mutating internal `/allowlist` chat commands missed `operator.admin` scope enforcement (openclaw)

OpenClaw developers fixed a medium-severity authorization flaw in version 2026.3.24, their current shipping release. Attackers with authenticated access to the internal Gateway, holding only operator.write scope, could mutate /allowlist chat commands. These changes bypassed the required operator.admin scope, allowing persistent alterations to config-backed allowFrom entries and pairing-store allowlists.

The vulnerability carries a CVSS v3.1 base score of 6.5 (Medium): AV:N/AC:L/PR:L/UI:N/S:U/C:N/I:H/A:N. Network access suffices, low complexity, but demands low-privilege authentication. No confidentiality or availability impact, yet high integrity risk. This aligns with CWE-862: Missing Authorization. Comparable mutating commands in OpenClaw—like those for config, MCP, plugins, and ACP—already enforced operator.admin, exposing inconsistent scope modeling here.

Technical Breakdown

The flaw hit OpenClaw from v2026.1.20 to v2026.3.23, introduced in commit 555b2578a8cc6e1b93f717496935ead97bfbed8b (“feat: add /allowlist command”). Verified on GitHub tag v2026.3.23 (commit ccfeecb6887cd97937e33a71877ad512741e82b2, published 2026-03-23).

Key vulnerable paths:

src/auto-reply/reply/commands-allowlist.ts:251-254

Here, /allowlist authorization relied solely on rejectUnauthorizedCommand(...), skipping requireGatewayClientScopeForInternalChannel(..., operator.admin, ...).

src/auto-reply/reply/commands-allowlist.ts:386-524

Mutating writes to config and pairing-store proceeded unchecked.

Reachability stems from src/gateway/method-scopes.ts:94-109, where chat.send counts as write-scoped. Tests in src/gateway/server.chat.gateway-server-chat.test.ts:539-559 confirm slash commands route via chat.send without agent execution. Internal callers gain senderIsOwner only with operator.admin in src/auto-reply/command-auth.ts:574-577.

Reproduce it:

1. Checkout v2026.3.23.
2. Set internal context: Provider = "webchat", Surface = "webchat", GatewayClientScopes = ["operator.write"], params.command.channel = "webchat".
3. Send via chat.send.
4. Run /allowlist mutation—succeeds without operator.admin.

Why It Matters

OpenClaw operates as an internal control plane for chat-based automation, likely in enterprise or AI orchestration setups. Allowlists dictate trusted sources—think IP whitelists or pairing approvals. A operator.write holder escalating to admin-like mutations risks locking out legit users or granting undue access. No host compromise or multi-tenancy needed; any Gateway-auth’d caller with write scope suffices.

This isn’t theoretical. Persistent changes survive restarts, baked into config and stores. In production, a compromised write-scoped service account—or insider—could reshape access controls undetected. CVSS nails it at medium: PR:L limits blast radius, but I:H flags real harm potential. Fair fix speed: patched in days post-3.23 ship.

Skeptically, OpenClaw’s scope model aims fine-grained RBAC, yet slips like this erode trust. Internal APIs demand ironclad checks; one lapse cascades. Operators: audit scopes now, upgrade to 2026.3.24. Developers: automate auth audits across command surfaces. Broader lesson—CWE-862 plagues 20%+ of apps per OWASP; consistent enforcement beats ad-hoc gates.

Context: OpenClaw appears tied to gateway/chat infra, possibly for AI agents or comms platforms (auto-reply, plugins hint automation). No public exploits yet, but tags like “openclaw” suggest open-source scrutiny. If running affected versions, isolate Gateway callers, revoke excess scopes, monitor allowlist diffs.