OpenClaw versions prior to 2026.4.21 contain a logic flaw in command authorization where a wildcard channel `allowFrom: ["*"]` configuration is incorrectly treated as implicit owner identity, allowing any sender — not just the designated owner — to invoke privileged commands including `/send`, `/config`, and `/debug`. For security teams running OpenClaw-based agent deployments, this means an unauthorized external party could modify agent configuration or extract internal state without credentials or special privileges. With only 4 downstream npm dependents, no EPSS data, no public exploit, and no CISA KEV listing, the aggregate blast radius is limited; however, wildcard sender policies are a plausible default for public-facing agent channels, making the misconfiguration easy to land in inadvertently. The fix is straightforward: upgrade to `openclaw@2026.4.21`, or pre-upgrade, explicitly set `commands.ownerAllowFrom` to the intended owner identities or remove wildcard `allowFrom` on owner-enforced channels.
What is the risk?
Medium risk overall. CWE-862 (Missing Authorization) is the root cause — a logic error where wildcard channel policy is incorrectly reused in a separate authorization axis. Exploitation requires three simultaneous conditions: `enforceOwnerForCommands: true`, `allowFrom: ["*"]`, and no `ownerAllowFrom` configured. The conditional nature limits the vulnerable population, but open/wildcard sender policies are a reasonable default for public-facing agent deployments, making inadvertent misconfiguration plausible. No CVSS score or EPSS data is available. The 135 prior CVEs in the same package signal a codebase with sustained security debt, warranting scrutiny of any OpenClaw deployment.
How does the attack unfold?
What systems are affected?
| Package | Ecosystem | Vulnerable Range | Patched |
|---|---|---|---|
| OpenClaw | npm | <= 2026.4.20 | 2026.4.21 |
Do you use OpenClaw? You're affected.
How severe is it?
What should I do?
6 steps-
Upgrade openclaw to version 2026.4.21 or later (fix commits: 2aa93d44, 995febb7).
-
If immediate upgrade is not possible, explicitly configure
commands.ownerAllowFromwith a whitelist of intended owner identities on every channel usingenforceOwnerForCommands: true. -
Alternatively, remove wildcard
allowFrom: ["*"]on owner-enforced channels until patched — this is the most direct risk reduction. -
Audit all channel configurations for the triple-condition pattern: scan for channels where enforceOwnerForCommands is true, allowFrom includes wildcard, and ownerAllowFrom is absent.
-
Review command audit logs for unauthorized invocations of /send, /config, or /debug from non-owner sender identities prior to the patch.
-
Given 135 CVEs in this package, consider a broader security review of any OpenClaw deployment's attack surface.
How is it classified?
Which compliance frameworks are affected?
This CVE is relevant to:
Frequently Asked Questions
What is GHSA-c28g-vh7m-fm7v?
OpenClaw versions prior to 2026.4.21 contain a logic flaw in command authorization where a wildcard channel `allowFrom: ["*"]` configuration is incorrectly treated as implicit owner identity, allowing any sender — not just the designated owner — to invoke privileged commands including `/send`, `/config`, and `/debug`. For security teams running OpenClaw-based agent deployments, this means an unauthorized external party could modify agent configuration or extract internal state without credentials or special privileges. With only 4 downstream npm dependents, no EPSS data, no public exploit, and no CISA KEV listing, the aggregate blast radius is limited; however, wildcard sender policies are a plausible default for public-facing agent channels, making the misconfiguration easy to land in inadvertently. The fix is straightforward: upgrade to `openclaw@2026.4.21`, or pre-upgrade, explicitly set `commands.ownerAllowFrom` to the intended owner identities or remove wildcard `allowFrom` on owner-enforced channels.
Is GHSA-c28g-vh7m-fm7v actively exploited?
No confirmed active exploitation of GHSA-c28g-vh7m-fm7v has been reported, but organizations should still patch proactively.
How to fix GHSA-c28g-vh7m-fm7v?
1. Upgrade openclaw to version 2026.4.21 or later (fix commits: 2aa93d44, 995febb7). 2. If immediate upgrade is not possible, explicitly configure `commands.ownerAllowFrom` with a whitelist of intended owner identities on every channel using `enforceOwnerForCommands: true`. 3. Alternatively, remove wildcard `allowFrom: ["*"]` on owner-enforced channels until patched — this is the most direct risk reduction. 4. Audit all channel configurations for the triple-condition pattern: scan for channels where enforceOwnerForCommands is true, allowFrom includes wildcard, and ownerAllowFrom is absent. 5. Review command audit logs for unauthorized invocations of /send, /config, or /debug from non-owner sender identities prior to the patch. 6. Given 135 CVEs in this package, consider a broader security review of any OpenClaw deployment's attack surface.
What systems are affected by GHSA-c28g-vh7m-fm7v?
This vulnerability affects the following AI/ML architecture patterns: agent frameworks, AI agent deployments, chatbot platforms, automated workflow systems.
What is the CVSS score for GHSA-c28g-vh7m-fm7v?
No CVSS score has been assigned yet.
What is the AI security impact?
Affected AI Architectures
MITRE ATLAS Techniques
AML.T0049 Exploit Public-Facing Application AML.T0053 AI Agent Tool Invocation AML.T0081 Modify AI Agent Configuration AML.T0083 Credentials from AI Agent Configuration AML.T0084 Discover AI Agent Configuration Compliance Controls Affected
What are the technical details?
Original Advisory
## Impact OpenClaw deployments before `2026.4.21` could treat a non-owner sender as authorized for owner-enforced slash commands when all of the following were true: - a channel plugin declared `commands.enforceOwnerForCommands: true`; - the channel accepted wildcard inbound senders with `allowFrom: ["*"]`; - no explicit `commands.ownerAllowFrom` was configured. In that state, `src/auto-reply/command-auth.ts` reused the channel inbound wildcard as part of the command-owner decision. A sender who was not the owner could therefore pass the owner-command gate for commands such as `/send`, `/config`, or `/debug` on the affected channel. The issue is limited to the command-owner authorization axis. It does not by itself grant owner-only tool access, host/sandbox access, or gateway administrator scope. ## Affected Packages / Versions - Package: `openclaw` on npm - Affected versions: `<= 2026.4.20` - Patched version: `2026.4.21` The latest public release, `2026.4.21`, contains the fix. ## Patches The fix requires a concrete owner identity or internal operator-admin scope when a plugin enforces owner-only commands. Wildcard channel `allowFrom` no longer implies wildcard command ownership. Fix commits: - `2aa93d44a1b2c7058c371f261fda2b5d4de4a882` on `main` - `995febb7b1e811ff6a1df5b18c22de94103f4c9f` in the `2026.4.21` release line ## Workarounds Upgrade to `openclaw@2026.4.21` or later. Before upgrading, avoid wildcard/open-DM sender policy on owner-enforced channels, or configure `commands.ownerAllowFrom` to the intended owner identities. ## Credits OpenClaw thanks @zsxsoft for reporting.
Exploitation Scenario
An adversary identifies a publicly reachable OpenClaw channel configured for open inbound messaging (`allowFrom: ["*"]`) and discovers — through documentation, source code review, or probing — that the channel uses a plugin with `enforceOwnerForCommands: true` but has no `ownerAllowFrom` explicitly configured. The adversary sends a `/config` command as an arbitrary non-owner sender. The vulnerable `src/auto-reply/command-auth.ts` logic reuses the wildcard allowFrom as implicit owner authorization, passing the ownership gate. The adversary modifies the agent's routing or plugin configuration to redirect outbound messages or alter agent behavior. In a follow-on step, the adversary invokes `/debug` to extract internal state or credential material stored in the agent's configuration, potentially enabling further lateral movement within the organization's AI infrastructure.
Weaknesses (CWE)
CWE-862 — Missing Authorization: The product does not perform an authorization check when an actor attempts to access a resource or perform an action.
- [Architecture and Design] Divide the product into anonymous, normal, privileged, and administrative areas. Reduce the attack surface by carefully mapping roles with data and functionality. Use role-based access control (RBAC) [REF-229] to enforce the roles at the appropriate boundaries. Note that this approach may not protect against horizontal authorization, i.e., it will not protect a user from attacking others with the same role.
- [Architecture and Design] Ensure that access control checks are performed related to the business logic. These checks may be different than the access control checks that are applied to more generic resources such as files, connections, processes, memory, and database records. For example, a database may restrict access for medical records to a specific database user, but each record might only be intended to be accessible to the patient and the patient's doctor [REF-7].
Source: MITRE CWE corpus.
References
Timeline
Related Vulnerabilities
CVE-2026-33579 9.9 OpenClaw: scope bypass escalates low-priv to admin
Same package: openclaw CVE-2026-32922 9.9 OpenClaw: privilege escalation to RCE via token scope bypass
Same package: openclaw CVE-2026-32038 9.8 Analysis pending
Same package: openclaw CVE-2026-53838 9.8 OpenClaw: approval scope bypass via reconnection state
Same package: openclaw CVE-2026-30741 9.8 OpenClaw: RCE via request-side prompt injection
Same package: openclaw