GHSA-mgq6-vr84-7m2j: OpenClaw: QQBot approval button auth bypass

GHSA-mgq6-vr84-7m2j HIGH
Published July 2, 2026
CISO Take

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.

Sources: GitHub Advisory ATLAS

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?

Entry point
A non-approver user is present in a QQ conversation where OpenClaw delivers a native approval button for a pending exec or plugin action.
Exploitation
The non-approver clicks the approval button; the callback handler resolves the approval without verifying the clicker matches the configured QQBot approver identity.
AML.T0053
Impact
The pending exec or plugin action executes with the agent's granted privileges, having been authorized by an unintended, unauthorized party.
AML.T0108

What systems are affected?

Package Ecosystem Vulnerable Range Patched
OpenClaw npm < 2026.5.18 2026.5.18
3 dependents 37% patched ~3d to patch Full package profile →

Do you use OpenClaw? You're affected.

How severe is it?

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

What is the attack surface?

AV AC PR UI S C I A
AV Network
AC Low
PR Low
UI Required
S Unchanged
C High
I High
A High

What should I do?

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

EU AI Act
Article 14 - Human Oversight
ISO 42001
Annex A.9 - AI System Operational Controls
NIST AI RMF
MANAGE-1.1 - AI risks and benefits are managed based on assessed impact
OWASP LLM Top 10
LLM08 - Excessive Agency

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

agent frameworkshuman-in-the-loop approval workflowsplugin executionchat-based agent control channels

MITRE ATLAS Techniques

AML.T0050 Command and Scripting Interpreter
AML.T0053 AI Agent Tool Invocation
AML.T0108 AI Agent

Compliance Controls Affected

EU AI Act: Article 14
ISO 42001: Annex A.9
NIST AI RMF: MANAGE-1.1
OWASP LLM Top 10: LLM08

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

Timeline

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

Related Vulnerabilities