GHSA-ccx3-fw7q-rr2r: Unbounded Base64 Decoding Leading to Denial of Service in OpenClaw

OpenClaw operates as a user-controlled local AI assistant, routinely processing user-supplied files and images. This processing frequently involves decoding base64-encoded data streams received via internal API endpoints. The underlying architecture relies heavily on the Node.js runtime to handle these incoming data payloads.

A vulnerability identified as GHSA-ccx3-fw7q-rr2r exists within multiple base64 processing code paths of the openclaw npm package. The software fails to validate the volumetric size of incoming base64 strings prior to allocating memory for the decoded output buffer. This flaw represents an instance of CWE-770 (Allocation of Resources Without Limits or Throttling).

By supplying excessively large base64 strings, an attacker can force the Node.js runtime to exhaust available heap memory. The resulting memory exhaustion triggers an immediate out-of-memory (OOM) crash, leading to a complete Denial of Service (DoS). The vulnerability affects all OpenClaw versions up to and including 2026.4.2.

The root cause resides in the lack of an early exit mechanism during memory allocation operations. When a Node.js application invokes Buffer.from(data, 'base64'), the V8 JavaScript engine synchronously calculates the required byte length and attempts to allocate the corresponding memory on the heap. The exact memory requirement is mathematically deterministic, equating to approximately 75% of the input string length.

In the vulnerable versions of OpenClaw, the application code passes user-controlled strings directly into the Buffer allocation API. The application logic assumes that upstream constraints or system-level limits will prevent abnormally large inputs. Because OpenClaw processes data continuously without strict payload size boundaries at the application layer, large inputs bypass these implicit assumptions completely.

Consequently, the application commits to allocating contiguous memory blocks proportional to the attacker's payload. If the requested allocation exceeds the configured heap limit of the Node.js instance, the memory allocator fails. This failure is uncatchable by standard JavaScript try/catch blocks because it occurs at the V8 engine level rather than within the user-space script execution context.

The Node.js process terminates abruptly with a FATAL ERROR: Reached heap limit Allocation failed exception. Since the vulnerability triggers a low-level V8 engine halt, standard application recovery mechanisms must intervene. This capability to induce continuous process termination degrades the availability of the local AI assistant.

Analyzing the fix introduced in commit d7c3210cd6f5fdfdc1beff4c9541673e814354d5 reveals the introduction of explicit length verification. The patch modifies the network and file processing modules to calculate the expected decoded size before invoking any Buffer operations. This proactive check ensures that the requested memory falls strictly within a predefined MAX_ALLOCATION_SIZE constant.

Prior to the patch, the code executed the memory allocation directly. The vulnerable implementation resembled the following pattern, where the incoming data was processed without any preliminary inspection:

function processUpload(req, res) {
    // Vulnerable: Direct allocation from user input
    const fileData = req.body.file;
    const decodedBuffer = Buffer.from(fileData, 'base64');
    processLocalAI(decodedBuffer);
}

The patched implementation calculates the theoretical size of the decoded payload mathematically. Base64 encoding utilizes four characters to represent three bytes of binary data. The patch code calculates the expected byte length using the formula (encodedString.length / 4) * 3 and compares it against the safety threshold prior to allocation.

The remediation introduces the validation layer as demonstrated below:

function processUpload(req, res) {
    const fileData = req.body.file;
    
    // Patch: Pre-allocation size check
    const expectedSize = (fileData.length / 4) * 3;
    if (expectedSize > MAX_ALLOCATION_SIZE) {
        return res.status(413).send("Payload too large");
    }
    
    const decodedBuffer = Buffer.from(fileData, 'base64');
    processLocalAI(decodedBuffer);
}

This architectural change effectively neutralizes the vulnerability by guaranteeing an early exit condition before the V8 memory allocator is engaged by the Buffer.from() operation.

Exploiting this vulnerability requires sending a specially crafted request to the OpenClaw local API. The attacker must target an endpoint that processes base64 strings, such as the local file upload or image processing routes. The attack vector is strictly local (AV:L), meaning the attacker requires access to the system or network interface where the OpenClaw application is listening.

The attacker generates a massive base64 string, typically several hundreds of megabytes in size. This string does not need to decode to a valid file format. It only needs to contain valid base64 characters to bypass any basic string validation and reach the Buffer allocation subroutine. A JSON payload is constructed containing this oversized string within the corresponding object key.

Below is an example of the structural payload used to trigger the denial of service:

{
  "filename": "malicious.bin",
  "file": "SGVsbG8gV29ybGQ... [repeated up to 1GB] ...",
  "action": "process"
}

Upon receiving the payload, the Node.js application attempts to parse the JSON and subsequently allocate the memory for the base64 string. The V8 garbage collector cannot free memory quickly enough to accommodate the massive contiguous allocation request. The process crashes immediately, rendering the AI assistant unresponsive until restarted by the operating system or a process manager.

The primary security impact of this vulnerability is a complete Denial of Service (DoS) for the OpenClaw process. Because the application crashes at the runtime engine level, all currently executing tasks, including unrelated local AI inference operations, are terminated abruptly. State data held in memory that has not been persisted to disk is permanently lost during the crash.

The CVSS v4.0 score evaluates to 2.3, reflecting a Low severity based on the specific operational environment. The metric AV:L indicates that the attacker must have local access to the environment hosting the OpenClaw instance. Confidentiality and Integrity metrics are correctly marked as None because the vulnerability does not allow memory disclosure, arbitrary code execution, or unauthorized data manipulation.

While the severity score is relatively low due to the local access requirement, the operational impact can be substantial in environments where OpenClaw operates continuously. Automated watchdogs can restart the service, but an attacker with persistent local execution capabilities can construct a script to crash the application repeatedly, effectively denying access to the service indefinitely.

The official resolution for this vulnerability is to upgrade the openclaw npm package to version 2026.4.8 or later. This release introduces the necessary pre-allocation bounds checking across all internal modules that process user-supplied base64 data. Developers should update their dependency manifests and rebuild their application images to incorporate the patched code.

In deployment scenarios where immediate patching is not feasible, administrators can implement request size limits at the reverse proxy layer. Configuring Nginx or a similar web server with a strict client body size directive restricts the maximum volume of data that can reach the vulnerable OpenClaw endpoints. This mitigation drops oversized payloads before they are processed by the Node.js runtime.

An example Nginx configuration snippet to limit incoming requests to a maximum of 50 megabytes is shown below:

server {
    listen 80;
    server_name openclaw.local;
    
    # Enforce request size limit to prevent memory exhaustion
    client_max_body_size 50M;
    
    location / {
        proxy_pass http://localhost:3000;
    }
}

This infrastructure-level control acts as an effective compensating control, mitigating the risk of memory exhaustion attacks against unpatched instances until an official update can be applied.