CVE-2026-43526: Openclaw SSRF Vulnerability

CVE-2026-43526 Overview

CVE-2026-43526 is a Server-Side Request Forgery (SSRF) vulnerability [CWE-918] in OpenClaw versions before 2026.4.12. The flaw exists in the QQBot reply media URL handling logic, where insufficient validation of remote media hostnames allows attackers to coerce the server into fetching arbitrary content. Bytes retrieved by the server can subsequently be re-uploaded through the channel, expanding the impact beyond a typical blind SSRF.

The vulnerability is reachable over the network without authentication and without user interaction, making it a viable target for opportunistic attackers scanning public OpenClaw deployments.

Critical Impact

Unauthenticated attackers can force OpenClaw to fetch arbitrary URLs, potentially reaching internal services, cloud metadata endpoints, and sensitive resources, then exfiltrate the fetched content via the bot channel.

Affected Products

• OpenClaw (Node.js distribution) versions prior to 2026.4.12
• OpenClaw extensions/qqbot component
• Deployments exposing the QQBot reply media URL handler

Discovery Timeline

• 2026-05-05 - CVE-2026-43526 published to NVD
• 2026-05-07 - Last updated in NVD database

Technical Details for CVE-2026-43526

Vulnerability Analysis

The vulnerability resides in extensions/qqbot/src/utils/file-utils.ts, which handles media URLs supplied to QQBot reply flows. Before the fix, the hostname allowlist permitted only a narrow set of domains, but the URL parsing and validation logic allowed attacker-controlled URLs to bypass the intended restrictions. When OpenClaw processes a reply containing a media URL, it issues an outbound HTTP request and reads the response into memory, then re-uploads those bytes through the bot channel.

Because the request originates from the OpenClaw server, the attacker inherits the network position of that host. Internal HTTP services, cloud instance metadata endpoints, and management interfaces normally protected by network segmentation become reachable. The re-upload behavior turns the SSRF into a content-exfiltration primitive, returning the body of internal responses directly to the attacker through the chat reply.

Root Cause

The root cause is incomplete hostname validation in the QQBot media fetcher. The QQBOT_MEDIA_HOSTNAME_ALLOWLIST constant did not enumerate the full set of legitimate Tencent media hosts, and the validation path failed to reject URLs that resolved to private or non-allowlisted destinations before the outbound fetch occurred.

Attack Vector

An attacker submits a crafted QQBot reply that references a malicious media URL. The OpenClaw server fetches the URL and forwards the response bytes back through the channel. Targets typically include http://169.254.169.254/ style cloud metadata services, internal admin panels, and unauthenticated localhost services bound to the OpenClaw host.

// Patch excerpt: extensions/qqbot/src/utils/file-utils.ts
export const LARGE_FILE_THRESHOLD = 5 * 1024 * 1024;

const QQBOT_MEDIA_HOSTNAME_ALLOWLIST = [
  // QQ富媒体
  "*.qpic.cn",
  "*.qq.com",
  "*.weiyun.com",
  "*.qq.com.cn",

  // QQ机器人
  "*.ugcimg.cn",

  // 腾讯云COS
  "*.myqcloud.com",
  "*.tencentcos.cn",
  "*.tencentcos.com",
];

Source: GitHub commit ddb7a8d. The patch redefines the hostname allowlist to enumerate the full set of legitimate Tencent media domains, ensuring the fetcher rejects URLs that fall outside these wildcards.

Detection Methods for CVE-2026-43526

Indicators of Compromise

• Outbound HTTP requests from the OpenClaw process to private RFC1918 ranges, 127.0.0.1, or cloud metadata addresses such as 169.254.169.254.
• QQBot reply events referencing media URLs whose hostnames are not in the post-patch allowlist (*.qpic.cn, *.qq.com, *.weiyun.com, *.qq.com.cn, *.ugcimg.cn, *.myqcloud.com, *.tencentcos.cn, *.tencentcos.com).
• Unusual spikes in bot replies containing binary or text payloads sized close to the LARGE_FILE_THRESHOLD of 5 MB.

Detection Strategies

• Log and alert on every outbound DNS resolution and TCP connection initiated by the OpenClaw Node.js process, then correlate against the documented allowlist.
• Inspect application logs for file-utils.ts fetch operations and flag any non-allowlisted hostname seen prior to upgrading.
• Hunt for QQBot reply payloads whose content does not match expected image or media MIME types, indicating possible internal HTTP responses being relayed.

Monitoring Recommendations

• Place egress filtering in front of OpenClaw and deny traffic to private network ranges and metadata services.
• Enable verbose request logging for the QQBot extension and ship logs to a centralized analytics platform for retention and search.
• Monitor for abnormal child process or network behavior originating from the OpenClaw container or host.

How to Mitigate CVE-2026-43526

Immediate Actions Required

• Upgrade OpenClaw to version 2026.4.12 or later, which contains the corrected QQBOT_MEDIA_HOSTNAME_ALLOWLIST.
• Restrict outbound network access from the OpenClaw host to only the Tencent media domains required for legitimate QQBot operation.
• Audit recent QQBot reply logs for non-allowlisted media URLs and treat any matches as suspected SSRF attempts.

Patch Information

The vendor released fixes in two GitHub commits: commit 08ae021 and commit ddb7a8d. Coordinated disclosure details are tracked in GHSA-2767-2q9v-9326 and the VulnCheck advisory.

Workarounds

• Disable the QQBot extension until the upgrade can be applied if the bot is not business-critical.
• Deploy an egress proxy that enforces the post-patch hostname allowlist at the network layer, blocking connections to internal addresses regardless of application behavior.
• Run OpenClaw in a network namespace that has no route to internal management subnets or cloud metadata services.

# Example egress allowlist using iptables on the OpenClaw host
# Block connections to cloud metadata and link-local addresses
iptables -A OUTPUT -d 169.254.169.254 -j REJECT
iptables -A OUTPUT -d 127.0.0.0/8 ! -o lo -j REJECT
iptables -A OUTPUT -d 10.0.0.0/8 -j REJECT
iptables -A OUTPUT -d 172.16.0.0/12 -j REJECT
iptables -A OUTPUT -d 192.168.0.0/16 -j REJECT