GHSA-RXXP-482V-7MRH: Memory Exhaustion via Unbounded Media Buffering in OpenClaw

OpenClaw integrates with various messaging platforms (Discord, Telegram, Zalo, Microsoft Teams, BlueBubbles) to process user interactions. These integrations necessitate handling rich media, such as images, videos, and documents, sent by users. The vulnerability exists within the media ingestion logic of these extensions.

Technically, this is a Resource Exhaustion flaw categorized under CWE-770 (Allocation of Resources Without Limits or Throttling) and CWE-400 (Uncontrolled Resource Consumption). The affected components fail to implement defensive programming practices when handling untrusted input streams from remote servers. By accepting the full payload before validation, the application exposes itself to trivial denial-of-service attacks that consume all available heap memory, leading to an immediate process termination by the Node.js runtime.

The root cause is a distinct anti-pattern in asynchronous I/O handling known as "sink-then-check." In the vulnerable implementation, the extensions utilize high-level HTTP client methods that resolve the entire response body into a generic buffer object (e.g., ArrayBuffer or Node.js Buffer) before passing control back to the application logic.

The specific failure occurs because the check for maxBytes (the configuration setting intended to limit file sizes) is executed after the await keyword has already resolved the full promise chain for the download. In Node.js, this means the V8 engine must allocate contiguous memory on the heap to store the incoming binary data. If the remote resource exceeds the V8 heap limit (typically 2GB-4GB depending on flags), the allocation fails, and the process crashes ungracefully. This occurs regardless of whether the application code intends to reject the file effectively immediately afterward.

The vulnerability is evident in the handling of the fetch response. The patch introduces a centralized utility that manages the stream directly.

Vulnerable Pattern (Before Fix):

The code blindly allocates a buffer for the entire response. Note that res.arrayBuffer() reads the full stream into memory.

// Vulnerable logic in extension handlers
const res = await fetch(url);
// CRITICAL: The entire file is loaded into RAM here
const buf = new Uint8Array(await res.arrayBuffer());
const maxBytes = opts.maxBytes || DEFAULT_LIMIT;
 
// The check happens too late; memory is already exhausted
if (buf.byteLength > maxBytes) {
  throw new Error("Attachment too large");
}

Patched Pattern (After Fix):

The fix, applied in commit 73d93dee64127a26f1acd09d0403b794cdeb4f5c, replaces the manual fetch logic with a runtime utility fetchRemoteMedia. This utility enforces limits at the chunk level or via Content-Length inspection before full allocation.

// Patched logic using centralized runtime utility
const fetched = await getMSTeamsRuntime().channel.media.fetchRemoteMedia({
  url: candidate.url,
  maxBytes: params.maxBytes, // Limit passed to the fetcher
  fetchImpl: (input, init) => fetchWithAuthFallback({ ... }),
});
 
// The utility monitors the stream and aborts early if size > maxBytes

Exploitation of this vulnerability requires network access to one of the messaging platforms where the target OpenClaw instance is active. No special tools are required; standard messaging clients suffice.

Attack Scenario:

1. Target Identification: The attacker locates a bot powered by a vulnerable version of OpenClaw on a platform like Discord or Telegram.
2. Payload Delivery: The attacker uploads a massive file (e.g., 10GB) to a public hosting service or hosts a malicious HTTP server that serves an infinite stream of random bytes.
3. Trigger: The attacker sends a message to the bot containing the URL to this file. Alternatively, if the platform supports it, they attach the file directly.
4. Execution: The OpenClaw extension receives the webhook event, parses the attachment URL, and initiates the download. The server attempts to allocate memory for the incoming stream. Once the heap limit is reached (usually within seconds), the Node.js process crashes with FATAL ERROR: Reached heap limit Allocation failed - JavaScript heap out of memory.

This vector can be automated to continuously crash the bot whenever it restarts, resulting in a persistent denial of service.

The primary impact is Availability. The vulnerability allows for a reliable, low-cost Denial of Service attack. Because OpenClaw is often deployed as a single Node.js process, a crash in an extension handler brings down the entire assistant, including unrelated processing threads or context management.

CVSS v3.1 Metrics:

• Attack Vector (Network): The attack is initiated remotely via messaging platforms.
• Privileges Required (None/Low): Depending on the platform configuration, the attacker may need to be a regular user in the chat channel (Low) or requires no authentication if the bot is public (None).
• User Interaction (None): The bot processes the message automatically without admin intervention.
• Availability (High): The service crashes completely.

There is no impact on Confidentiality or Integrity, as the memory exhaustion occurs before the application processes or stores the malicious data.

Users running OpenClaw with any of the affected messaging extensions should upgrade immediately. The fix is implemented in the core logic and extension handlers to use the streaming fetch utility.

Remediation Steps:

1. Update the openclaw package to the latest version via npm update openclaw or yarn upgrade openclaw.
2. Verify that custom extensions or forks utilize the fetchRemoteMedia utility provided by the PluginRuntime rather than raw fetch calls for handling user-provided URLs.
3. Ensure maxBytes is configured in the bot settings to a reasonable limit (e.g., 5MB or 10MB) to prevent resource waste even with the patch applied.

Workarounds: If an immediate update is not possible, users can mitigate the risk by disabling media processing capabilities in their bot configuration or restricting the bot to trusted, private channels where malicious payloads are unlikely.