GHSA-77pv-3w4q-vrj5: OpenClaw QQBot slash commands

Q: Is GHSA-77pv-3w4q-vrj5 actively exploited?

No confirmed active exploitation of GHSA-77pv-3w4q-vrj5 has been reported, but organizations should still patch proactively.

Q: How to fix GHSA-77pv-3w4q-vrj5?

Upgrade to openclaw 2026.4.27 or later, where the allowFrom check is enforced before command dispatch. Until patched, disable the QQBot slash-command feature if not required, or restrict QQBot exposure to fully trusted channels only. Keep channel and tool allowlists narrow as general hardening, and avoid sharing a single Gateway between mutually untrusted user groups. For detection, review dispatch/audit logs for slash command executions attributed to senders outside the configured allowFrom list on affected versions.

Q: What systems are affected by GHSA-77pv-3w4q-vrj5?

This vulnerability affects the following AI/ML architecture patterns: agent frameworks, multi-channel messaging integrations, command/tool dispatch pipelines.

Q: What is the CVSS score for GHSA-77pv-3w4q-vrj5?

No CVSS score has been assigned yet.

CISO Take

OpenClaw's QQBot integration could dispatch slash commands before evaluating the configured allowFrom sender allowlist, letting a sender who should have been blocked trigger command handling anyway. There's no CVSS score, no EPSS percentile, no CISA KEV listing, and no public exploit or Nuclei template — this reads as a configuration-scoped authorization flaw rather than something being actively weaponized in the wild. That said, openclaw is an AI agent framework with real downstream reach (4 tracked dependents) and a long CVE history in this codebase (425 other CVEs tracked for the package), so authorization bugs in its channel-dispatch layer are worth taking seriously wherever QQBot is exposed to mutually untrusted users. Patch to 2026.4.27; until then, disable or tightly restrict QQBot slash command exposure, keep channel and tool allowlists narrow, and avoid sharing one Gateway across untrusted senders. Detection: audit dispatch logs for slash commands executed from senders outside the configured allowFrom list on pre-2026.4.27 builds.

Sources: GitHub Advisory CISA KEV ATLAS

What is the risk?

Medium severity per the advisory, with no CVSS vector, EPSS score, KEV listing, public exploit, or scanner template available — indicating no known active exploitation. Risk is highly configuration-dependent: it only materializes when the QQBot slash-command feature is enabled and reachable by senders that the operator intended to exclude via allowFrom. The advisory explicitly scopes this to the named feature and does not alter OpenClaw's broader trusted-operator model, which narrows the blast radius considerably compared to a Gateway-wide authorization bypass.

How does the attack unfold?

Unauthorized Channel Access

An attacker with access to a QQBot channel connected to the OpenClaw Gateway is positioned to send slash commands, despite not being on the configured allowFrom list.

Slash Command Dispatch

The attacker sends a slash command that the affected version processes before evaluating the allowFrom authorization check, bypassing the intended control.

AML.T0107

Unauthorized Command Execution

The command executes as if sent by an authorized operator, invoking the agent action or tool tied to that slash command.

AML.T0053

Impact

Depending on which slash commands are exposed and the operator's configuration, the attacker gains unauthorized influence over agent behavior or Gateway state reserved for trusted senders.

Unauthorized Channel Access

An attacker with access to a QQBot channel connected to the OpenClaw Gateway is positioned to send slash commands, despite not being on the configured allowFrom list.

Slash Command Dispatch

The attacker sends a slash command that the affected version processes before evaluating the allowFrom authorization check, bypassing the intended control.

AML.T0107

Unauthorized Command Execution

The command executes as if sent by an authorized operator, invoking the agent action or tool tied to that slash command.

AML.T0053

Impact

Depending on which slash commands are exposed and the operator's configuration, the attacker gains unauthorized influence over agent behavior or Gateway state reserved for trusted senders.

What systems are affected?

Package	Ecosystem	Vulnerable Range	Patched
OpenClaw	npm	<= 2026.4.26	`2026.4.27`
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

Upgrade to openclaw 2026.4.27 or later, where the allowFrom check is enforced before command dispatch. Until patched, disable the QQBot slash-command feature if not required, or restrict QQBot exposure to fully trusted channels only. Keep channel and tool allowlists narrow as general hardening, and avoid sharing a single Gateway between mutually untrusted user groups. For detection, review dispatch/audit logs for slash command executions attributed to senders outside the configured allowFrom list on affected versions.

How is it classified?

Auth Bypass Agent Plugin AML.T0053 - AI Agent Tool Invocation AML.T0107 - Exploitation for Defense Evasion

Which compliance frameworks are affected?

This CVE is relevant to:

EU AI Act

Article 15 - Accuracy, robustness and cybersecurity

NIST AI RMF

MANAGE-4.1 - Risk treatments, including access controls, are documented and monitored

OWASP LLM Top 10

LLM08:2025 - Excessive Agency

Frequently Asked Questions

What is GHSA-77pv-3w4q-vrj5?

OpenClaw's QQBot integration could dispatch slash commands before evaluating the configured allowFrom sender allowlist, letting a sender who should have been blocked trigger command handling anyway. There's no CVSS score, no EPSS percentile, no CISA KEV listing, and no public exploit or Nuclei template — this reads as a configuration-scoped authorization flaw rather than something being actively weaponized in the wild. That said, openclaw is an AI agent framework with real downstream reach (4 tracked dependents) and a long CVE history in this codebase (425 other CVEs tracked for the package), so authorization bugs in its channel-dispatch layer are worth taking seriously wherever QQBot is exposed to mutually untrusted users. Patch to 2026.4.27; until then, disable or tightly restrict QQBot slash command exposure, keep channel and tool allowlists narrow, and avoid sharing one Gateway across untrusted senders. Detection: audit dispatch logs for slash commands executed from senders outside the configured allowFrom list on pre-2026.4.27 builds.

Is GHSA-77pv-3w4q-vrj5 actively exploited?

No confirmed active exploitation of GHSA-77pv-3w4q-vrj5 has been reported, but organizations should still patch proactively.

How to fix GHSA-77pv-3w4q-vrj5?

Upgrade to openclaw 2026.4.27 or later, where the allowFrom check is enforced before command dispatch. Until patched, disable the QQBot slash-command feature if not required, or restrict QQBot exposure to fully trusted channels only. Keep channel and tool allowlists narrow as general hardening, and avoid sharing a single Gateway between mutually untrusted user groups. For detection, review dispatch/audit logs for slash command executions attributed to senders outside the configured allowFrom list on affected versions.

What systems are affected by GHSA-77pv-3w4q-vrj5?

This vulnerability affects the following AI/ML architecture patterns: agent frameworks, multi-channel messaging integrations, command/tool dispatch pipelines.

What is the CVSS score for GHSA-77pv-3w4q-vrj5?

No CVSS score has been assigned yet.

What is the AI security impact?

Affected AI Architectures

agent frameworksmulti-channel messaging integrationscommand/tool dispatch pipelines

MITRE ATLAS Techniques

AML.T0053 AI Agent Tool Invocation

AML.T0107 Exploitation for Defense Evasion

Compliance Controls Affected

EU AI Act: Article 15

NIST AI RMF: MANAGE-4.1

OWASP LLM Top 10: LLM08:2025

What are the technical details?

Original Advisory

### Summary QQBot pre-dispatch slash commands could skip allowFrom checks. In affected versions, a QQBot sender able to invoke slash commands could dispatch the command before applying the configured allowFrom 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 trigger command handling from a sender 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.27`. ### Mitigations restrict QQBot slash command exposure 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 operator runs an OpenClaw Gateway with QQBot enabled and an allowFrom policy meant to restrict slash-command senders to a trusted subset. A QQBot user outside that allowlist sends a slash command; because the dispatch handler processes the command before the allowFrom check executes, the command runs as if it came from an authorized sender. The attacker gains unauthorized influence over whatever agent action, tool, or Gateway behavior that slash command maps to — bypassing a control the operator explicitly configured to prevent exactly this.

Weaknesses (CWE)

CWE-863 Incorrect Authorization Primary

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.