Skip to main content
VulnerabilityPublished Updated

CVE-2026-53834: OpenClaw · QQBot pre-dispatch slash commands could skip allowFrom checks

Affects openclawSource GCVE Database

0

Mentioned vulnerabilities

CVSS 7.5 High : upgrade to 2026.4.27 soon.

Data as of 28 Aug 2026, 17:08 UTC

CVSS 3.1 base score
7.5High
How severe the flaw is on the 0–10 CVSS scale.
Patch
Available – fixed in 2026.4.27
CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:H/A:N

What to do

Upgrade openclaw to 2026.4.27.

Affected software

ProductAffectedFixed in
npmopenclawAffected
  • <2026.4.27
Fixed in
  • 2026.4.27

Check your own hosts for these packages with threat-finder (opens in a new tab), our free open-source scanner.

AI-suggested

A patch is available in OpenClaw version 2026.4.27 that addresses this issue. Operators should upgrade to this version to remediate the vulnerability. Until patched, it is recommended to restrict exposure of QQBot slash commands, keep channel and tool allowlists narrow, avoid sharing a Gateway instance among mutually untrusted users, and disable the affected feature if it is not needed.

Description

### 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.

References

Community reviews

Loading reviews…