The vulnerability (GHSA-w2cg-vxx6-5xjg) is a denial-of-service in the OpenClaw platform caused by uncontrolled resource consumption (CWE-400). The root cause is the premature decoding of base64-encoded media files and chat attachments. Attacker-controlled input in base64 format was decoded into a raw Buffer before the application checked if the resulting data would exceed the configured size limits.
The analysis of the fix commit 31791233d60495725fa012745dde8d6ee69e9595 reveals several functions responsible for handling these base64 inputs.
In src/gateway/chat-attachments.ts, the functions parseMessageWithAttachments and buildMessageWithAttachments were modified. The vulnerable code, Buffer.from(b64, "base64"), which performs the decoding and memory allocation, was previously called before any size validation. The patch replaces this with a call to a new estimateBase64DecodedBytes function, which safely calculates the potential size from the base64 string's length without decoding it. If the estimated size is too large, the operation is aborted, preventing the large allocation.
Similarly, while the diff for src/media/input-files.ts doesn't show the function bodies, the corresponding test file (src/media/input-files.fetch-guard.test.ts) was updated to explicitly verify that extractImageContentFromSource and extractFileContentFromSource no longer call Buffer.from(..., "base64") for oversized inputs. This confirms these functions were also vulnerable and were fixed to perform size estimation before decoding.
Finally, the original estimateBase64DecodedBytes function in src/media/input-files.ts was itself a minor source of allocation pressure, as it used string.trim().replace() on the input. The fix introduces a more efficient, non-allocating estimation algorithm in a new src/media/base64.ts module, which is used by all the patched functions.
Therefore, during exploitation, a profiler would show one of parseMessageWithAttachments, buildMessageWithAttachments, extractImageContentFromSource, or extractFileContentFromSource at the top of the stack, consuming significant CPU and memory while trying to allocate a large buffer from the malicious base64 input.