OpenClaw CVE-2026-100549

Requires the QQBot voice attachment handling code path to be reachable - i.e., the QQBot channel integration must be enabled and the attacker must be able to deliver an inbound voice attachment that OpenClaw admits and stages (PR:L: a low-privilege but admitted/authenticated or steered sender, not an anonymous internet client). The core prerequisite is the specific double-decode behavior on attachment filenames in versions before 2026.8.1. Exploitation is LIMITED to versions <2026.8.1, to deployments that have the QQBot channel configured, and impact is bounded to locations writable by the OpenClaw process (no confidentiality/read primitive, VC:N). No user interaction beyond the attacker sending the attachment is required (UI:N).

This is a genuine but low-priority path traversal (CWE-22). The vendor CVSS 4.0 vector (AV:N/AC:L/AT:N/PR:L/UI:N/VC:N/VI:L/VA:L, base 5.3) is internally consistent with the description: network vector, low complexity, but requiring low-privilege access (PR:L) - meaning an already-admitted/authenticated or steered caller, not an anonymous internet attacker. Impact is limited to integrity and availability (VI:L/VA:L) with explicitly NO confidentiality impact (VC:N), which fits a write-primitive that drops files into other process-writable locations rather than reading secrets. There is no EPSS score, no CISA KEV listing, and no public exploit code provided, so exploitation status is 'no public exploit identified at time of analysis.' No signals conflict - every source points to a moderate-severity, authentication-gated write flaw. This is a real bug worth patching but not an urgent, widely-weaponizable issue; the PR:L requirement and bounded (VC:N) impact keep real-world risk low, and it should be prioritized behind any unauthenticated or RCE-class OpenClaw issues.

An attacker who can reach the QQBot channel and get an inbound message admitted sends a crafted voice attachment whose filename contains percent-encoded traversal sequences (e.g. %252e%252e%252f) that survive the sanitizer because the filename is URL-decoded twice. When the bot stages the voice file, the decoded '../' segments reappear and the file is written outside the intended staging directory to another process-writable path, potentially overwriting or planting files the agent process can access. No public proof-of-concept is available at time of analysis.