GHSA-w4v6-g3wm-w36c: OpenClaw: QQBot admin auth bypass skips access checks
GHSA-w4v6-g3wm-w36c CRITICALOpenClaw's QQBot integration exposes exported admin commands that are supposed to be reachable only via direct message from an explicitly allowlisted sender, but a routing flaw lets any sender able to trigger the command skip both the DM-only and allowFrom checks entirely. For CISOs running OpenClaw Gateways with QQBot enabled, this collapses a designed trust boundary — a group-chat or non-allowlisted sender can invoke admin behavior meant only for vetted operators — and the vendor rates it critical even though no CVSS score, EPSS percentile, or public exploit is currently published. There's no CISA KEV listing and no confirmed exploitation in the wild, but exploitation requires no special sophistication beyond reaching the QQBot channel, and the openclaw package already carries an unusually large advisory history (425 other CVEs), suggesting this ecosystem draws active security scrutiny. Downstream blast radius looks small on paper (4 known dependents), but any deployment that shares a single Gateway across mutually untrusted users with QQBot enabled should treat this as urgent. Patch to 2026.4.29 immediately, or as an interim step disable the exported QQBot admin commands or restrict QQBot access, and audit Gateway logs for admin-command invocations that didn't originate from an allowlisted DM sender.
What is the risk?
Rated critical by the vendor but unscored (no CVSS, no EPSS, not in CISA KEV, no public exploit or Nuclei template). Exploitability is low-complexity in principle — a sender only needs the ability to trigger the exported QQBot command, no credential theft or advanced tradecraft required — but exposure is conditional on the QQBot feature being enabled and reachable by lower-trust users, which limits blast radius to specific deployment configurations rather than all OpenClaw installs. The combination of trivial trigger conditions and a broken authorization boundary (CWE-863) makes this a high-priority patch item wherever QQBot is in use, even without evidence of active exploitation.
How does the attack unfold?
What systems are affected?
| Package | Ecosystem | Vulnerable Range | Patched |
|---|---|---|---|
| OpenClaw | npm | < 2026.4.29 | 2026.4.29 |
Do you use OpenClaw? You're affected.
How severe is it?
What should I do?
1 step-
Upgrade to OpenClaw 2026.4.29 or later, where the DM-only and allowFrom checks are correctly enforced for QQBot admin commands. Until patched, disable the exported QQBot admin commands or restrict QQBot access entirely. As general hardening: keep channel and tool allowlists narrow, avoid sharing a single Gateway between mutually untrusted users, and turn off the QQBot feature if it isn't actively needed. For detection, review Gateway/audit logs for admin-command invocations whose originating sender was not a DM or was outside the configured allowFrom list, and treat any such entries predating the patch as a potential policy-bypass event.
How is it classified?
Which compliance frameworks are affected?
This CVE is relevant to:
Frequently Asked Questions
What is GHSA-w4v6-g3wm-w36c?
OpenClaw's QQBot integration exposes exported admin commands that are supposed to be reachable only via direct message from an explicitly allowlisted sender, but a routing flaw lets any sender able to trigger the command skip both the DM-only and allowFrom checks entirely. For CISOs running OpenClaw Gateways with QQBot enabled, this collapses a designed trust boundary — a group-chat or non-allowlisted sender can invoke admin behavior meant only for vetted operators — and the vendor rates it critical even though no CVSS score, EPSS percentile, or public exploit is currently published. There's no CISA KEV listing and no confirmed exploitation in the wild, but exploitation requires no special sophistication beyond reaching the QQBot channel, and the openclaw package already carries an unusually large advisory history (425 other CVEs), suggesting this ecosystem draws active security scrutiny. Downstream blast radius looks small on paper (4 known dependents), but any deployment that shares a single Gateway across mutually untrusted users with QQBot enabled should treat this as urgent. Patch to 2026.4.29 immediately, or as an interim step disable the exported QQBot admin commands or restrict QQBot access, and audit Gateway logs for admin-command invocations that didn't originate from an allowlisted DM sender.
Is GHSA-w4v6-g3wm-w36c actively exploited?
No confirmed active exploitation of GHSA-w4v6-g3wm-w36c has been reported, but organizations should still patch proactively.
How to fix GHSA-w4v6-g3wm-w36c?
Upgrade to OpenClaw 2026.4.29 or later, where the DM-only and allowFrom checks are correctly enforced for QQBot admin commands. Until patched, disable the exported QQBot admin commands or restrict QQBot access entirely. As general hardening: keep channel and tool allowlists narrow, avoid sharing a single Gateway between mutually untrusted users, and turn off the QQBot feature if it isn't actively needed. For detection, review Gateway/audit logs for admin-command invocations whose originating sender was not a DM or was outside the configured allowFrom list, and treat any such entries predating the patch as a potential policy-bypass event.
What systems are affected by GHSA-w4v6-g3wm-w36c?
This vulnerability affects the following AI/ML architecture patterns: agent frameworks, plugin/tool integrations, chat-ops gateways.
What is the CVSS score for GHSA-w4v6-g3wm-w36c?
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 Compliance Controls Affected
What are the technical details?
Original Advisory
### Summary QQBot admin commands could skip DM-only and allowFrom policy. In affected versions, a QQBot sender able to trigger the exported command could route admin commands without the QQBot-specific DM-only and allowFrom checks. 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 QQBot admin behavior from a sender or context that policy should have blocked. 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.4.29`. ### Mitigations disable exported QQBot admin commands or restrict QQBot access 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 an OpenClaw Gateway with the QQBot plugin enabled so a small set of vetted operators can issue admin commands via direct message. Because the routing logic fails to enforce the DM-only and allowFrom checks for QQBot specifically, a lower-trust participant in a shared QQ group — someone who was never added to the allowlist and never used a DM — sends the trigger message from the group chat instead. The Gateway processes it as though it came from a trusted operator and executes the associated admin behavior (e.g., configuration changes or other privileged QQBot actions) without the intended restrictions, handing control that should have been locked to a narrow set of trusted senders to an unauthorized party.
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-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 CVE-2026-30741 9.8 OpenClaw: RCE via request-side prompt injection
Same package: openclaw