AI Threat Alert
OpenClaw's QQBot streaming command can mutate Gateway configuration even when the requesting sender is not on an explicit, non-wildcard allowlist — a straightforward incorrect-authorization flaw (CWE-863) confined to one channel command rather than a break in OpenClaw's overall trusted-operator model. There is no CVSS vector, no EPSS score, no CISA KEV listing, no public exploit, and no Nuclei template for this one, so mass exploitation isn't imminent, but the package already carries 425 other tracked CVEs, signaling a large, actively-scrutinized attack surface for a component that sits at the center of agent tool invocation and config control. Anyone running OpenClaw with the QQBot streaming feature enabled — especially on a Gateway shared by users of different trust levels — should treat this as a live authorization gap, since a lower-trust sender reaching that command could silently change admin-intended policy. Patch to 2026.4.29 now; until then, disable the affected command or restrict it to explicit trusted QQBot sender IDs, keep channel/tool allowlists narrow, and monitor Gateway configuration-change logs for QQBot-originated writes that fall outside expected admin activity.
What is the risk?
Rated high severity by the advisory despite the absence of a CVSS vector, EPSS score, or known exploitation. The vulnerability is an authorization-boundary bypass (CWE-863) scoped to a single feature (QQBot streaming command), not a full compromise of OpenClaw's trust model — exploitability hinges entirely on operator configuration: whether the QQBot channel is enabled, reachable by untrusted or semi-trusted senders, and shared across users with differing trust levels. In that configuration the bar to exploit is low (no auth bypass of the Gateway itself is needed, just messaging the bot), but the blast radius is bounded to configuration state for the affected feature rather than arbitrary code execution or data exfiltration. Absent KEV listing, public PoC, or scanner coverage, near-term mass exploitation is unlikely, but this is exactly the class of quiet privilege-creep bug that compounds when Gateways are shared infrastructure.
How does the attack unfold?
What systems are affected?
| Package | Ecosystem | Vulnerable Range | Patched |
|---|---|---|---|
| OpenClaw | npm | <= 2026.4.27 | 2026.4.29 |
Do you use OpenClaw? You're affected.
How severe is it?
What should I do?
1 step-
1) Upgrade OpenClaw to 2026.4.29 or later, where the allowlist check is enforced correctly. 2) Until patched, disable the QQBot streaming command entirely, or restrict it to an explicit, non-wildcard list of trusted QQBot sender IDs. 3) As general hardening: keep all channel and tool allowlists narrow and explicit (avoid wildcard entries), and avoid sharing a single Gateway between mutually untrusted users or groups. 4) Detection: audit Gateway configuration-change logs for QQBot-sourced writes to streaming config that don't correspond to an admin-initiated change, and alert on any config mutation attributed to a sender outside the expected allowlist.
How is it classified?
Which compliance frameworks are affected?
This CVE is relevant to:
Frequently Asked Questions
What is GHSA-jvm4-4j77-39p6?
OpenClaw's QQBot streaming command can mutate Gateway configuration even when the requesting sender is not on an explicit, non-wildcard allowlist — a straightforward incorrect-authorization flaw (CWE-863) confined to one channel command rather than a break in OpenClaw's overall trusted-operator model. There is no CVSS vector, no EPSS score, no CISA KEV listing, no public exploit, and no Nuclei template for this one, so mass exploitation isn't imminent, but the package already carries 425 other tracked CVEs, signaling a large, actively-scrutinized attack surface for a component that sits at the center of agent tool invocation and config control. Anyone running OpenClaw with the QQBot streaming feature enabled — especially on a Gateway shared by users of different trust levels — should treat this as a live authorization gap, since a lower-trust sender reaching that command could silently change admin-intended policy. Patch to 2026.4.29 now; until then, disable the affected command or restrict it to explicit trusted QQBot sender IDs, keep channel/tool allowlists narrow, and monitor Gateway configuration-change logs for QQBot-originated writes that fall outside expected admin activity.
Is GHSA-jvm4-4j77-39p6 actively exploited?
No confirmed active exploitation of GHSA-jvm4-4j77-39p6 has been reported, but organizations should still patch proactively.
How to fix GHSA-jvm4-4j77-39p6?
1) Upgrade OpenClaw to 2026.4.29 or later, where the allowlist check is enforced correctly. 2) Until patched, disable the QQBot streaming command entirely, or restrict it to an explicit, non-wildcard list of trusted QQBot sender IDs. 3) As general hardening: keep all channel and tool allowlists narrow and explicit (avoid wildcard entries), and avoid sharing a single Gateway between mutually untrusted users or groups. 4) Detection: audit Gateway configuration-change logs for QQBot-sourced writes to streaming config that don't correspond to an admin-initiated change, and alert on any config mutation attributed to a sender outside the expected allowlist.
What systems are affected by GHSA-jvm4-4j77-39p6?
This vulnerability affects the following AI/ML architecture patterns: agent frameworks, multi-tenant agent gateways, chat/messaging channel integrations.
What is the CVSS score for GHSA-jvm4-4j77-39p6?
No CVSS score has been assigned yet.
What is the AI security impact?
Affected AI Architectures
MITRE ATLAS Techniques
AML.T0012 Valid Accounts AML.T0053 AI Agent Tool Invocation AML.T0081 Modify AI Agent Configuration Compliance Controls Affected
What are the technical details?
Original Advisory
### Summary QQBot streaming command could mutate config without explicit allowFrom. In affected versions, a QQBot sender reaching the affected command could change configuration without requiring an explicit non-wildcard allowlist entry. 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 modify QQBot streaming configuration outside the intended admin policy. 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 the command or restrict it to explicit trusted QQBot senders 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 a shared OpenClaw Gateway with the QQBot channel enabled to let both an internal team and external contacts interact with the agent via QQ. The QQBot streaming command is reachable by anyone who can message the bot, but the operator assumes only allowlisted senders can affect configuration. An external, non-allowlisted QQ contact sends the streaming command with crafted parameters; because the authorization check for this specific command doesn't require the sender to match an explicit non-wildcard allowlist entry, the request succeeds and mutates the streaming configuration — for example weakening output routing or scope for that feature. The change persists in Gateway config, silently altering behavior for all users of that channel until an admin notices the drift or the fix is deployed.
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