CVE-2026-29612: OpenClaw DOS Vulnerability

CVE-2026-29612 Overview

OpenClaw versions prior to 2026.2.14 contain a resource allocation vulnerability in the base64 media decoding functionality. The application decodes base64-backed media inputs into buffers before enforcing decoded-size budget limits, allowing remote attackers to supply oversized base64 payloads that trigger large memory allocations, resulting in memory pressure and denial of service conditions.

Critical Impact

Remote attackers can exploit this vulnerability to cause denial of service through memory exhaustion by sending oversized base64-encoded payloads to vulnerable OpenClaw instances.

Affected Products

• OpenClaw versions prior to 2026.2.14

Discovery Timeline

• 2026-03-05 - CVE CVE-2026-29612 published to NVD
• 2026-03-05 - Last updated in NVD database

Technical Details for CVE-2026-29612

Vulnerability Analysis

This vulnerability is classified under CWE-770 (Allocation of Resources Without Limits or Throttling). The core issue stems from improper sequencing of security checks during media file processing. When OpenClaw receives base64-encoded media inputs through chat attachments, it performs the full base64 decode operation before validating whether the resulting buffer size falls within acceptable limits.

This design flaw means that an attacker can craft payloads where the base64-encoded content decodes to an arbitrarily large buffer. Since Node.js and similar runtime environments must allocate the full decoded buffer in memory before size validation occurs, attackers can force the application to allocate excessive memory simply by submitting large base64 payloads.

Root Cause

The vulnerability exists because the decoded-size budget enforcement was implemented after the Buffer.from(..., "base64") operation rather than before. The fix introduces an estimateBase64DecodedBytes() function that calculates the expected decoded size by iterating through the base64 string without allocating additional memory, allowing the application to reject oversized payloads before performing the expensive decode operation.

Attack Vector

Exploitation requires local access with low privileges and no user interaction. An attacker can target the chat attachments functionality by sending specially crafted base64-encoded media files with inflated sizes. The attack is straightforward to execute as it only requires sending HTTP requests with large base64 payloads to the affected endpoint.

The security patch introduces pre-decode size estimation in src/gateway/chat-attachments.ts:

+import { estimateBase64DecodedBytes } from "../media/base64.js";
 import { detectMime } from "../media/mime.js";
 
 export type ChatAttachment = {

Source: GitHub Commit Update

The new estimateBase64DecodedBytes function in src/media/base64.ts performs size calculation without memory allocation:

+export function estimateBase64DecodedBytes(base64: string): number {
+  // Avoid `trim()`/`replace()` here: they allocate a second (potentially huge) string.
+  // We only need a conservative decoded-size estimate to enforce budgets before Buffer.from(..., "base64").
+  let effectiveLen = 0;
+  for (let i = 0; i < base64.length; i += 1) {
+    const code = base64.charCodeAt(i);
+    // Treat ASCII control + space as whitespace; base64 decoders commonly ignore these.
+    if (code <= 0x20) {
+      continue;
+    }
+    effectiveLen += 1;
+  }
+
+  if (effectiveLen === 0) {
+    return 0;
+  }
+
+  let padding = 0;
+  // Find last non-whitespace char(s) to detect '=' padding without allocating/copying.
+  let end = base64.length - 1;
+  while (end >= 0 && base64.charCodeAt(end) <= 0x20) {
+    end -= 1;
+  }
+  if (end >= 0 && base64[end] === "=") {
+    padding = 1;
+    end -= 1;
+    while (end >= 0 && base64.charCodeAt(end) <= 0x20) {
+      end -= 1;
+    }
+    if (end >= 0 && base64[end] === "=") {

Source: GitHub Commit Update

Detection Methods for CVE-2026-29612

Indicators of Compromise

• Unusually large HTTP request bodies containing base64-encoded data targeting chat attachment endpoints
• Rapid memory consumption spikes on OpenClaw server instances
• Server out-of-memory errors or process crashes following media upload requests
• Multiple requests with abnormally large Content-Length headers

Detection Strategies

• Monitor HTTP request sizes to chat attachment and media upload endpoints for anomalously large payloads
• Implement application-level logging to track base64 payload sizes before processing
• Configure alerts for sudden memory utilization increases on systems running OpenClaw
• Review web server logs for requests with unusually large body sizes targeting media processing endpoints

Monitoring Recommendations

• Set up resource utilization alerting with thresholds for memory consumption on OpenClaw deployments
• Enable request body size logging at the reverse proxy or load balancer level
• Monitor process restart frequencies that may indicate memory exhaustion crashes
• Track HTTP 5xx error rates which may spike during exploitation attempts

How to Mitigate CVE-2026-29612

Immediate Actions Required

• Upgrade OpenClaw to version 2026.2.14 or later immediately
• Implement request body size limits at the web server or reverse proxy layer
• Configure memory limits and auto-restart policies for OpenClaw processes
• Review and restrict access to media upload endpoints where possible

Patch Information

The security fix is available in OpenClaw version 2026.2.14 and later. The patch introduces the estimateBase64DecodedBytes() function that calculates decoded size without allocating memory, enabling rejection of oversized payloads before the expensive decode operation. For detailed patch information, see the GitHub Commit Update and GitHub Security Advisory.

Workarounds

• Configure web server or reverse proxy to enforce strict request body size limits on media upload endpoints
• Implement rate limiting on chat attachment endpoints to reduce attack surface
• Deploy OpenClaw behind a WAF with payload size inspection capabilities
• Consider temporarily disabling base64 media upload functionality until patching is complete

# Example nginx configuration to limit request body size
# Add to server or location block for OpenClaw
client_max_body_size 10M;

# Example rate limiting for media upload endpoints
limit_req_zone $binary_remote_addr zone=media_upload:10m rate=10r/s;
location /api/chat/attachments {
    limit_req zone=media_upload burst=5 nodelay;
    proxy_pass http://openclaw_backend;
}