GHSA-w4v6-g3wm-w36c: OpenClaw: QQBot admin auth bypass skips access checks

GHSA-w4v6-g3wm-w36c CRITICAL
Published July 2, 2026
CISO Take

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.

Sources: GitHub Advisory ATLAS

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?

Reach QQBot channel
Adversary obtains access to a QQ chat context (e.g., a shared group) monitored by the OpenClaw Gateway's QQBot integration, without needing to be an allowlisted DM sender.
Trigger exported admin command
Adversary sends the exported QQBot admin command; the vulnerable routing skips the DM-only and allowFrom checks meant to gate it.
AML.T0053
Admin behavior executes with elevated trust
The Gateway processes the request as if it came from a trusted operator, running the associated QQBot admin behavior (potentially including configuration changes).
AML.T0081
Unauthorized policy bypass
Attacker achieves admin-level control over QQBot behavior that policy should have restricted to vetted operators, with real-world impact scoped by whatever admin commands allow in that deployment.

What systems are affected?

Package Ecosystem Vulnerable Range Patched
OpenClaw npm < 2026.4.29 2026.4.29
4 dependents 41% 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
Moderate

What should I do?

1 step
  1. 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:

EU AI Act
Article 15 - Accuracy, robustness and cybersecurity
NIST AI RMF
GOVERN-1.5 - Accountability mechanisms and access controls for AI system actors
OWASP LLM Top 10
LLM06:2025 - Excessive Agency

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

agent frameworksplugin/tool integrationschat-ops gateways

MITRE ATLAS Techniques

AML.T0053 AI Agent Tool Invocation
AML.T0081 Modify AI Agent Configuration

Compliance Controls Affected

EU AI Act: Article 15
NIST AI RMF: GOVERN-1.5
OWASP LLM Top 10: LLM06:2025

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.

Timeline

Published
July 2, 2026
Last Modified
July 2, 2026
First Seen
July 2, 2026

Related Vulnerabilities