GHSA-C4QG-J8JG-42Q5: Server-Side Request Forgery in OpenClaw QQBot Extension

The OpenClaw platform operates as a modular framework utilizing the openclaw npm package to provide integration capabilities with various services. The extensions/qqbot component specifically facilitates interactions with the QQ Open Platform. This extension manages message processing, state synchronization, and direct media uploads, acting as an intermediary between the OpenClaw user base and the upstream QQ infrastructure.

The vulnerability is classified as CWE-918: Server-Side Request Forgery (SSRF). The flaw manifests in the media upload functions where user-supplied URLs are appended to configuration payloads and relayed to the QQ Open Platform without adequate server-side validation. The OpenClaw backend treats the externally provided URL as a trusted data point, blindly passing it to an upstream service that natively fetches external content.

While the vulnerability originates in the OpenClaw codebase, the execution of the forged request occurs on the infrastructure of the QQ Open Platform. This architecture creates a cross-boundary SSRF condition. The vulnerable application functions as an open proxy configuration endpoint, instructing the external API to initiate the HTTP fetch operation on the attacker's behalf.

The severity of this vulnerability is rated Low in the advisory, reflecting the specific prerequisites for exploitation. An attacker requires the ability to interact with the QQBot interface and submit structured media payloads. The actual impact depends heavily on the internal network posture and egress filtering rules implemented by the upstream QQ infrastructure.

The root cause of the vulnerability resides in the uploadC2CMedia and uploadGroupMedia functions located within the extensions/qqbot/src/api.ts file. These modules construct JSON payloads designated for the QQ API to facilitate the processing and distribution of rich media content. The application defines a specific data structure required by the upstream endpoint to process media URLs asynchronously.

The vulnerable implementation accepts an optional url parameter from external inputs. This parameter is directly assigned to the body.url property of the JSON payload. The application transmits this payload to endpoints such as https://api.sgroup.qq.com/v2/users/{openid}/files. The OpenClaw implementation performs no validation on the protocol scheme, the target hostname, or the resolved IP address of the supplied URL.

Because the OpenClaw backend relies on the upstream QQ infrastructure to fetch the media, the application effectively delegates the network fetch operation without enforcing security constraints. The unvalidated URL forces the upstream server to initiate HTTP requests to arbitrary network locations. The failure to sanitize the input allows an attacker to dictate the exact destination and protocol of the upstream server's outbound request.

The absence of strict input parsing creates a scenario where non-standard URI schemes or internally routable IP addresses bypass the intended application flow. The system assumes the URL points to a legitimate external image or document, but the lack of cryptographic or logical enforcement allows the URL to point to localized loopback addresses or cloud provider metadata services.

Exploitation requires the attacker to submit a malicious URL through the OpenClaw media attachment interface. The attacker must possess the necessary privileges to send messages or configure payloads processed by the QQBot extension. The attack sequence begins when the user supplies a crafted uniform resource indicator in a media submission form or API request.

The OpenClaw application processes the submission and relays the malicious URL directly to the QQ Open Platform via a backend API call. The attacker leverages the inherent trust relationship between the OpenClaw server and the QQ API. The QQ infrastructure receives the payload, parses the unvalidated URL, and executes an outbound network request to fetch the designated media.

If the attacker supplies a target such as http://169.254.169.254/latest/meta-data/, the upstream server attempts to retrieve the AWS Instance Metadata Service (IMDS). This specific vector allows the attacker to extract sensitive environmental variables, temporary IAM credentials, and internal provisioning configurations from the upstream hosting environment. The attacker views the resulting exfiltrated data if the upstream API returns the fetched content within an error message or a processing response.

The exploitation can also target internal services running on the upstream network. By iterating through private IP address ranges (e.g., 10.0.0.0/8, 192.168.0.0/16), the attacker can perform internal port scanning. The response times or specific error codes returned by the QQ API serve as a functional oracle, allowing the attacker to map internal service topologies without direct network access.

The vulnerability was addressed in commit 49db424c8001f2f419aad85f434894d8d85c1a09. The maintainers introduced a comprehensive validation function named assertDirectUploadUrlAllowed to enforce strict security constraints on all user-supplied URLs prior to payload construction. This function serves as an authoritative gateway for all media-related network targets.

The vulnerable code snippet assigned the URL to the outgoing request body without any programmatic checks:

export async function uploadC2CMedia(accessToken, openid, fileType, url, fileData) {
  const body = { file_type: fileType, srv_send_msg: true };
  if (url) {
    body.url = url; // Vulnerable: Direct assignment
  }
  return await fetchWithSsrFGuard(qqApiUrl, { method: "POST", body: JSON.stringify(body) });
}

The patched implementation introduces a three-tiered validation mechanism. First, the function utilizes the native Node.js URL constructor to verify syntactic validity. Second, it enforces a strict protocol whitelist, explicitly requiring https: and outright rejecting alternative schemes like http:, file:, or gopher:. This protocol restriction eliminates a broad class of SSRF attacks that rely on specialized URI handlers.

async function assertDirectUploadUrlAllowed(url: string): Promise<string> {
  const parsed = new URL(url);
  if (parsed.protocol !== "https:") {
    throw new Error("Direct-upload media URL must use HTTPS");
  }
  await resolvePinnedHostnameWithPolicy(parsed.hostname);
  return parsed.toString();
}

Finally, the patch executes resolvePinnedHostnameWithPolicy against the parsed hostname. This utility resolves the domain name to its corresponding IP address and validates the result against a strict security policy. By pinning the resolution and checking the absolute IP against a blocklist (rejecting internal, private, and reserved IP blocks), the system mitigates DNS Rebinding attacks. This prevents an attacker from supplying a domain that initially resolves to a safe IP during validation but subsequently points to an internal IP during the actual fetch operation.

The concrete security impact of this vulnerability centers on unauthorized network discovery and potential information disclosure within the upstream QQ Open Platform environment. By controlling the exact destination of outbound HTTP requests generated by the external API, an attacker effectively bypasses standard perimeter network controls and firewalls.

The severity is gated by the capabilities of the upstream server and the architectural design of the API relay. If the QQ platform operates within a cloud environment lacking rigorous egress filtering, the attacker can extract high-value credentials from endpoints such as the AWS IMDS. This extraction compromises the confidentiality of the infrastructure supporting the upstream service.

Furthermore, the vulnerability enables an attacker to interact with unauthenticated internal administrative interfaces, databases, or microservices accessible only to the upstream server. The SSRF acts as a pivot point, transforming a low-privileged external user into an internal network actor. The attack leaves minimal direct traces on the targeted internal systems, as the malicious requests originate from trusted, authorized upstream infrastructure.

Organizations operating the OpenClaw platform must upgrade the openclaw npm package to version 2026.4.20 or a subsequent release immediately. This updated package contains the finalized code modifications implementing the strict URL protocol validation and the DNS resolution policy. Upgrading the package resolves the root cause at the application layer.

Administrators must verify the configuration of the resolvePinnedHostnameWithPolicy utility within their OpenClaw environment. The deployment must define strict, explicit blocklists for internal IP ranges. The policy must cover standard RFC 1918 addresses (10.0.0.0/8, 172.16.0.0/12, 192.168.0.0/16), loopback interfaces (127.0.0.0/8), and known cloud metadata endpoints (e.g., 169.254.169.254).

If immediate patching is unfeasible due to deployment constraints, operators should apply rigorous input validation at the API gateway layer. Web Application Firewall (WAF) rules can be configured to inspect media submission payloads, rejecting any requests containing URLs that specify the http: protocol or target known internal IP structures. This virtual patching provides temporary protection against generic exploitation attempts.

Developers integrating with external APIs must adopt defensive programming practices when handling user-supplied network indicators. Relying on an upstream provider to enforce security controls is an architectural anti-pattern. Applications must parse, normalize, and validate all Uniform Resource Identifiers explicitly, utilizing DNS pinning to prevent Time-of-Check to Time-of-Use (TOCTOU) bypasses prior to relaying configurations to external endpoints.