OpenClaw's QQBot channel lets human approvers click native buttons to authorize sensitive AI agent actions like code execution or plugin invocation, but a missing identity check meant the button-click handler resolved the approval without verifying the clicker was actually a configured approver. Any user who could simply see the approval message in a QQ conversation — not just the designated approver — could click the button and green-light a pending exec or plugin action, effectively defeating the human-in-the-loop control that is supposed to gate agentic execution. This is a CVSS 8.0 high with low attack complexity and only low privileges required, and it sits squarely in the AI agent trust boundary: with 4 known downstream dependents and 425 other CVEs already logged against this package, openclaw sees active security scrutiny, though there is no EPSS score, KEV listing, or public exploit/Nuclei template yet indicating opportunistic scanning. Patch to openclaw 2026.5.18 or later immediately on any deployment using QQBot native approval buttons; until patched, stop routing approval messages into QQ conversations that include anyone who is not an authorized approver, and fall back to the text-command approval path, which enforced authorization correctly.
What is the risk?
High severity (CVSS 8.0, AV:N/AC:L/PR:L/UI:R/S:U/C:H/I:H/A:H) driven by a missing authorization check (CWE-862) on a control that exists specifically to gate irreversible or high-impact agent actions (exec, plugin invocation). Exploitability is low-effort — no special tooling, no cryptographic bypass, just clicking a button visible to any participant in the QQ conversation — which keeps sophistication at the trivial-to-moderate end despite the narrow attack surface (requires QQBot native approval buttons to be enabled and an unauthorized user present in the approval thread). No EPSS score, CISA KEV listing, or public exploit/Nuclei template exists yet, so there is no evidence of active exploitation, but the low complexity and high confidentiality/integrity/availability impact combination means any organization exposing approval workflows to shared QQ channels should treat this as urgent-patch, not monitor-and-wait.
How does the attack unfold?
What systems are affected?
| Package | Ecosystem | Vulnerable Range | Patched |
|---|---|---|---|
| OpenClaw | npm | < 2026.5.18 | 2026.5.18 |
Do you use OpenClaw? You're affected.
How severe is it?
What is the attack surface?
What should I do?
1 step-
1) Upgrade to openclaw 2026.5.18 or later, which enforces the configured QQBot approver identity on the native button callback path. 2) Until patched, disable native QQBot approval buttons for any conversation that includes users who are not configured approvers, or avoid delivering approval prompts into shared/group QQ conversations entirely. 3) As an interim control, rely on the text-command approval path, which correctly enforced the authorization check throughout. 4) Post-patch, audit logs for exec/plugin approvals resolved via QQBot buttons prior to the upgrade to identify any approvals that did not originate from a configured approver. 5) Review approval-channel configuration across all chat integrations (not just QQ) for the same class of missing-identity-check pattern.
How is it classified?
Which compliance frameworks are affected?
This CVE is relevant to:
Frequently Asked Questions
What is GHSA-mgq6-vr84-7m2j?
OpenClaw's QQBot channel lets human approvers click native buttons to authorize sensitive AI agent actions like code execution or plugin invocation, but a missing identity check meant the button-click handler resolved the approval without verifying the clicker was actually a configured approver. Any user who could simply see the approval message in a QQ conversation — not just the designated approver — could click the button and green-light a pending exec or plugin action, effectively defeating the human-in-the-loop control that is supposed to gate agentic execution. This is a CVSS 8.0 high with low attack complexity and only low privileges required, and it sits squarely in the AI agent trust boundary: with 4 known downstream dependents and 425 other CVEs already logged against this package, openclaw sees active security scrutiny, though there is no EPSS score, KEV listing, or public exploit/Nuclei template yet indicating opportunistic scanning. Patch to openclaw 2026.5.18 or later immediately on any deployment using QQBot native approval buttons; until patched, stop routing approval messages into QQ conversations that include anyone who is not an authorized approver, and fall back to the text-command approval path, which enforced authorization correctly.
Is GHSA-mgq6-vr84-7m2j actively exploited?
No confirmed active exploitation of GHSA-mgq6-vr84-7m2j has been reported, but organizations should still patch proactively.
How to fix GHSA-mgq6-vr84-7m2j?
1) Upgrade to openclaw 2026.5.18 or later, which enforces the configured QQBot approver identity on the native button callback path. 2) Until patched, disable native QQBot approval buttons for any conversation that includes users who are not configured approvers, or avoid delivering approval prompts into shared/group QQ conversations entirely. 3) As an interim control, rely on the text-command approval path, which correctly enforced the authorization check throughout. 4) Post-patch, audit logs for exec/plugin approvals resolved via QQBot buttons prior to the upgrade to identify any approvals that did not originate from a configured approver. 5) Review approval-channel configuration across all chat integrations (not just QQ) for the same class of missing-identity-check pattern.
What systems are affected by GHSA-mgq6-vr84-7m2j?
This vulnerability affects the following AI/ML architecture patterns: agent frameworks, human-in-the-loop approval workflows, plugin execution, chat-based agent control channels.
What is the CVSS score for GHSA-mgq6-vr84-7m2j?
GHSA-mgq6-vr84-7m2j has a CVSS v3.1 base score of 8.0 (HIGH).
What is the AI security impact?
Affected AI Architectures
MITRE ATLAS Techniques
AML.T0050 Command and Scripting Interpreter AML.T0053 AI Agent Tool Invocation AML.T0108 AI Agent Compliance Controls Affected
What are the technical details?
Original Advisory
### Summary OpenClaw's QQBot channel can deliver native approval buttons for exec and plugin approvals. In affected releases, the button callback path resolved approvals without enforcing the configured QQBot approver identity. The text command approval path used the authorization check; the issue was specific to native QQBot approval buttons. ### Affected configurations This affects deployments where QQBot native approval buttons are enabled and an approval message is visible to a QQ user who is not configured as an approver. ### Impact A non-approver who could see the approval message could click an approval button and resolve the pending request. Depending on the pending approval, this could allow an exec or plugin action that should have required an authorized approver. ### Patched Versions The first stable patched version is `2026.5.18`. ### Mitigations Upgrade to `openclaw@2026.5.18` or later. Before upgrading, avoid delivering native approval buttons into QQ conversations that include users who should not be able to approve.
Exploitation Scenario
An OpenClaw agent is configured to require human approval before running an exec action or invoking a plugin, and that approval prompt is delivered via native QQBot buttons into a QQ group chat that includes both the authorized approver and other, non-approver members. A non-approver in that group sees the pending approval message — perhaps a request to run a shell command or invoke a filesystem/network plugin — and simply clicks the approval button before the legitimate approver does. Because the button callback path never checks whether the clicker is the configured approver, the request resolves as approved and the agent proceeds to execute the exec or plugin action with the privileges it was granted, giving an unauthorized party de facto control over a gated, potentially high-impact agent operation.
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.
CVSS Vector
CVSS:3.1/AV:N/AC:L/PR:L/UI:R/S:U/C:H/I:H/A:H 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