high · 8Jul 2, 2026

CVE-2026-35630: openclaw QQBot Native Approval Button Authorization Bypass

Rohit Hatagale
AI Security Researcher, SecureLayer7

Any QQ user who can see an OpenClaw approval message could tap the native Allow button and authorize a pending exec or plugin action, even if they were not configured as an approver.

Packageopenclaw
Ecosystemnpm
Affected< 2026.5.18
Fixed in2026.5.18

The problem

OpenClaw's QQBot channel renders exec and plugin approval requests as native interactive buttons in QQ. Before 2026.5.18, the button callback path resolved those approvals without checking the configured approver identity.

The text-command path (/bot-approve) correctly enforced the allowFrom allowlist. The button callback did not. Any QQ user in the conversation who could see the approval message could tap Allow Once or Always Allow and make it stick.

Proof of concept

A working proof-of-concept for this issue in openclaw, with the exact payload below.

bash
# Precondition: openclaw.json has a QQBot account with a broad allowFrom,
# e.g. allowFrom: ["*"], and exec or plugin approval is enabled.
#
# An approval message arrives in a QQ group or C2C chat:
#
#   🔐 OpenClaw wants to run: rm -rf /tmp/work
#   [ ✅ Allow Once ]  [ ⭐ Always Allow ]  [ ❌ Deny ]
#
# A non-approver (any QQ user who can see the message) taps [ ✅ Allow Once ].
# The button callback fires with their openId.
# Affected versions resolve the approval immediately — no allowFrom check.
# The pending exec or plugin action is granted.

The root cause is a missing authorization check (CWE-862) on the button interaction callback. The text-command approval path validated the sender's QQ OpenID against the configured non-wildcard allowFrom list before resolving a pending approval. The button callback skipped that check entirely.

The patch added the same allowFrom identity guard to the button callback, bringing it in line with the slash-command path. The patched docs now state explicitly that native approval button clicks follow the same explicit non-wildcard command allowlist as admin slash commands, and that a wildcard allowFrom does not grant approval access.

The fix

Upgrade to openclaw 2026.5.18 or later. Before upgrading, set a specific approver OpenID in allowFrom (not a wildcard) and avoid delivering approval messages into group chats that include non-approvers. Run `openclaw doctor --fix` after upgrading to migrate any legacy toolPolicy entries.

Reporter not attributed.

References: [1][2]

Related research