GHSA-c28g-vh7m-fm7v: openclaw: auth bypass in owner command enforcement

GHSA-c28g-vh7m-fm7v MEDIUM
Published April 29, 2026
CISO Take

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.

Sources: GitHub Advisory ATLAS

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?

Target Identification
Adversary discovers an OpenClaw channel with wildcard `allowFrom: ["*"]`, `enforceOwnerForCommands: true`, and no `ownerAllowFrom` configured — the exploitable triple-condition state.
AML.T0084
Authorization Bypass
Adversary sends an owner-only command (/config, /debug, or /send) as an arbitrary non-owner sender; vulnerable command-auth.ts reuses the wildcard allowFrom as implicit owner authorization, passing the gate.
AML.T0049
Privileged Command Execution
Adversary successfully invokes owner-level agent commands, gaining ability to modify agent configuration, extract internal state and credentials, or inject unauthorized outbound messages.
AML.T0053
Impact
Adversary alters agent routing or plugin behavior via /config, exfiltrates credentials or internal state via /debug, or abuses /send to deliver unauthorized messages through the agent's trusted communication channels.
AML.T0081

What systems are affected?

Package Ecosystem Vulnerable Range Patched
OpenClaw npm <= 2026.4.20 2026.4.21
4 dependents 36% patched ~3d to patch Full package profile →

Do you use OpenClaw? You're affected.

How severe is it?

CVSS 3.1
N/A
EPSS
N/A
Exploitation Status
No known exploitation
Sophistication
Trivial

What should I do?

6 steps
  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.

How is it classified?

Which compliance frameworks are affected?

This CVE is relevant to:

EU AI Act
Article 15 - Accuracy, robustness and cybersecurity
ISO 42001
A.8.1 - AI system access control
NIST AI RMF
GOVERN 1.7 - Processes for AI risk management
OWASP LLM Top 10
LLM08 - Excessive Agency

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

agent frameworksAI agent deploymentschatbot platformsautomated workflow systems

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

EU AI Act: Article 15
ISO 42001: A.8.1
NIST AI RMF: GOVERN 1.7
OWASP LLM Top 10: LLM08

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.

Timeline

Published
April 29, 2026
Last Modified
April 29, 2026
First Seen
April 30, 2026

Related Vulnerabilities