AI Threat Alert
OpenClaw, an AI agent gateway, shipped a flaw (CWE-863, Incorrect Authorization) where the native command handler could execute an owner-only command without enforcing the configured owner-only policy, letting a lower-trust sender run privileged actions on the agent. There is no public exploit and no Nuclei template, and it is not in CISA KEV, so opportunistic mass exploitation is unlikely today — but the bug requires no special skill once understood, only that the native command feature is enabled and reachable by an untrusted sender, which is a common setup when one Gateway is shared across a team or community. The package's track record adds context: 425 other CVEs are recorded against openclaw and its risk score is 0/100, suggesting a component with a broad, recurring attack surface, even though only 4 downstream dependents are currently tracked. Patch to 2026.5.6 immediately; until then, restrict native command surfaces to trusted senders, disable the feature if unused, and avoid sharing one Gateway between mutually untrusted users. Detection teams should audit command logs for owner-privileged actions (config changes, exec, shutdown) originating from non-owner sender identities during the exposure window.
What is the risk?
Rated high severity on CWE-863 (Incorrect Authorization) but with mitigating exploitation signals: no CVSS/EPSS scoring yet, no CISA KEV listing, no known public exploit or scanner template. Actual risk is highly configuration-dependent — exploitability requires the native command feature to be enabled and reachable by a sender who should not hold owner privileges, meaning single-owner or fully trusted-operator deployments are largely unaffected. Where OpenClaw gateways are shared across teams, communities, or externally-facing channels, the risk is materially higher because any participant able to trigger native command handling could escalate to owner-level actions. The package's broader history (425 other CVEs, OpenSSF/risk score 0/100) signals weak overall security hygiene in this component, which should raise baseline scrutiny of any deployment.
How does the attack unfold?
What systems are affected?
| Package | Ecosystem | Vulnerable Range | Patched |
|---|---|---|---|
| OpenClaw | npm | <= 2026.5.5 | 2026.5.6 |
Do you use OpenClaw? You're affected.
How severe is it?
What should I do?
1 step-
1) Patch to openclaw 2026.5.6 or later immediately. 2) Until patched, disable the native command feature if it is not required. 3) Restrict native command surfaces to explicitly trusted senders only; keep channel and tool allowlists as narrow as possible. 4) Never share a single Gateway instance between mutually untrusted users/tenants — segment deployments per trust boundary. 5) Detection: review logs for owner-privileged command executions (config changes, shutdown, exec-type actions) triggered by sender identities that are not the configured owner, particularly in the window before the patch was applied. 6) After patching, re-verify that owner-only command policy enforcement behaves as expected via a test message from a non-owner identity.
How is it classified?
Which compliance frameworks are affected?
This CVE is relevant to:
Frequently Asked Questions
What is GHSA-p73f-w79w-jqr5?
OpenClaw, an AI agent gateway, shipped a flaw (CWE-863, Incorrect Authorization) where the native command handler could execute an owner-only command without enforcing the configured owner-only policy, letting a lower-trust sender run privileged actions on the agent. There is no public exploit and no Nuclei template, and it is not in CISA KEV, so opportunistic mass exploitation is unlikely today — but the bug requires no special skill once understood, only that the native command feature is enabled and reachable by an untrusted sender, which is a common setup when one Gateway is shared across a team or community. The package's track record adds context: 425 other CVEs are recorded against openclaw and its risk score is 0/100, suggesting a component with a broad, recurring attack surface, even though only 4 downstream dependents are currently tracked. Patch to 2026.5.6 immediately; until then, restrict native command surfaces to trusted senders, disable the feature if unused, and avoid sharing one Gateway between mutually untrusted users. Detection teams should audit command logs for owner-privileged actions (config changes, exec, shutdown) originating from non-owner sender identities during the exposure window.
Is GHSA-p73f-w79w-jqr5 actively exploited?
No confirmed active exploitation of GHSA-p73f-w79w-jqr5 has been reported, but organizations should still patch proactively.
How to fix GHSA-p73f-w79w-jqr5?
1) Patch to openclaw 2026.5.6 or later immediately. 2) Until patched, disable the native command feature if it is not required. 3) Restrict native command surfaces to explicitly trusted senders only; keep channel and tool allowlists as narrow as possible. 4) Never share a single Gateway instance between mutually untrusted users/tenants — segment deployments per trust boundary. 5) Detection: review logs for owner-privileged command executions (config changes, shutdown, exec-type actions) triggered by sender identities that are not the configured owner, particularly in the window before the patch was applied. 6) After patching, re-verify that owner-only command policy enforcement behaves as expected via a test message from a non-owner identity.
What systems are affected by GHSA-p73f-w79w-jqr5?
This vulnerability affects the following AI/ML architecture patterns: agent frameworks, multi-tenant agent gateways, chat-integrated AI agents.
What is the CVSS score for GHSA-p73f-w79w-jqr5?
No CVSS score has been assigned yet.
What is the AI security impact?
Affected AI Architectures
MITRE ATLAS Techniques
AML.T0053 AI Agent Tool Invocation AML.T0081 Modify AI Agent Configuration AML.T0108 AI Agent Compliance Controls Affected
What are the technical details?
Original Advisory
### Summary Native command authorization could skip owner-command enforcement. In affected versions, a sender able to trigger native command handling could authorize a native command without enforcing the configured owner-only command policy. This advisory is scoped to the named feature and configuration. It does not change OpenClaw's trusted-operator model: authenticated Gateway operators, installed plugins, and intentional local execution surfaces remain trusted unless a separate policy, approval, allowlist, sandbox, or auth boundary is crossed. ### Impact When the affected feature is enabled and reachable, this could run an owner-style command from a sender that should not have that command access. Practical impact depends on the operator's configuration and whether lower-trust input can reach that path. ### Patched Versions The first stable patched version is `2026.5.6`. ### Mitigations keep native command surfaces limited to trusted senders until patched. As general hardening, keep channel and tool allowlists narrow, avoid sharing one Gateway between mutually untrusted users, and disable the affected feature when it is not needed.
Exploitation Scenario
An organization runs a shared OpenClaw agent gateway connected to a team chat channel, with the founder/admin configured as the sole authorized owner for sensitive commands (e.g., restart, reconfigure, or shell-adjacent actions). A regular channel member — or an external party who gains posting access to that channel — sends a message crafted to trigger OpenClaw's native command handling path. Because the owner-only enforcement check is skipped in the affected code path, the agent executes the privileged command as if it came from the owner, allowing the low-trust sender to reconfigure the agent, disrupt its operation, or pivot into other owner-scoped actions the deployment exposes through native commands — all without needing to compromise any credentials.
Weaknesses (CWE)
CWE-863 — Incorrect Authorization: The product performs an authorization check when an actor attempts to access a resource or perform an action, but it does not correctly perform the check.
- [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-30741 9.8 OpenClaw: RCE via request-side prompt injection
Same package: openclaw CVE-2026-32038 9.8 OpenClaw: sandbox bypass enables container lateral movement
Same package: openclaw CVE-2026-53838 9.8 OpenClaw: approval scope bypass via reconnection state
Same package: openclaw