CVE-2026-88045: Denial of Service via Uncontrolled Memory Preallocation and Integer Overflow in rclone S3 Compatibility Layer

CVE-2026-88045 is a high-severity Denial of Service (DoS) vulnerability in rclone's S3 compatibility layer, which is initiated via the serve s3 command. The flaw allows an attacker to cause system resource exhaustion on the host operating system, leading to process termination or server hangs. This weakness is categorized under CWE-789 (Memory Allocation with Excessive Size Value) and CWE-190 (Integer Overflow or Wraparound).

The vulnerability arises within the multipart upload component, specifically during the handling of UploadPart API requests. When a client initiates a request, the server parses the metadata to prepare buffer allocations for the incoming data payload. The application relies on client-supplied headers, such as Content-Length or X-Amz-Decoded-Content-Length, to determine the size of the memory buffer to reserve.

Because these values are processed before the server verifies or reads the actual bytes from the network socket, the S3 backend immediately attempts to allocate heap memory based on untrusted inputs. When anonymous access is enabled, any remote attacker can exploit this behavior without authentication. On authenticated deployments, an attacker requires a valid S3 access key, but the mechanics of the exploit remain identical.

The core weakness lies in the execution of immediate memory preallocation paired with an overflow-prone comparison logic. S3 multipart uploads require out-of-order part processing and temporary caching of incoming data segments. To manage these segments, rclone uses a pool-backed ReaderWriter struct from its lib/pool package, which allocates physical RAM dynamically in 1 MiB pages.

When an incoming UploadPart request is handled, the code extracts the part size from the request headers and immediately invokes multipart.NewRW().Reserve(contentLength). This function call allocates the exact number of 1 MiB pages matching the declared length directly within the system memory allocator. Because this allocation occurs prior to reading the request body, no network payload is required to trigger the allocation sequence.

In addition, the application uses an admission control function called waitForTurn to enforce buffer limits and prevent concurrent uploads from exhausting system memory. The function compares the total currently buffered size against a configured limit using the condition up.buffered+size <= up.bufferLimit. This calculation does not perform bounds checking and uses standard signed 64-bit integer addition, which is vulnerable to integer overflows.

A client can bypass the admission control limits by supplying an extremely large integer value, such as math.MaxInt64. When evaluated, the addition of the existing buffer size and the user-supplied size overflows the 64-bit signed integer boundary, wrapping the resulting value into a negative range. This negative result satisfies the comparison inequality, bypassing the safety check and allowing uncontrolled buffer reservation.

Analyzing the vulnerable codebase reveals the structural flaws in the S3 backend implementation. In cmd/serve/s3/multipart.go, the initialization logic for handling a part upload was constructed as shown below. The use of .Reserve(contentLength) forced immediate memory allocation from the global page pool.

// VULNERABLE CODE (Preallocation)
// Buffer the part in a pool-backed RW so we can MD5 it (for the ETag) and
// stream it once it is this part's turn.
rw := multipart.NewRW().Reserve(contentLength)

The corresponding admission logic in waitForTurn lacked input verification for negative sizes and used an unsafe addition operation. This made the check vulnerable to arithmetic wraparound, which bypassed the buffer limits entirely.

// VULNERABLE CODE (Admission Control)
func (up *multipartUpload) waitForTurn(partNumber int, size int64) error {
    up.mu.Lock()
    defer up.mu.Unlock()
    for {
        if up.closed {
            return gofakes3.ErrNoSuchUpload
        }
        if up.bufferLimit <= 0 || partNumber <= up.nextPart || up.buffered == 0 || up.buffered+size <= up.bufferLimit {
            up.buffered += size
            return nil
        }
        // ...
    }
}

To resolve the preallocation issue, the developers removed the .Reserve call in commit 7c1dfd99f3e6a22fcefd8686cc478226a15e63a1. The buffer now starts empty and grows page-by-page as bytes are read from the network stream, preventing immediate resource starvation.

// PATCHED CODE (No Preallocation)
// Buffer the part in a pool-backed RW so we can MD5 it (for the ETag) and
// stream it once it is this part's turn. The RW grows a page at a time as
// the body is read.
rw := multipart.NewRW()

The second patch in commit ab1f458013aaf6356e4bdeca61f7cb9139f8eb86 added a negative bounds check and restructured the inequality statement to prevent integer overflows. By rewriting up.buffered+size <= up.bufferLimit as size <= up.bufferLimit-up.buffered, the code avoids arithmetic overflow because up.bufferLimit and up.buffered are both verified positive boundaries.

// PATCHED CODE (Safe Overflow Check)
func (up *multipartUpload) waitForTurn(partNumber int, size int64) error {
	if size < 0 {
		return gofakes3.ErrInvalidArgument
	}
	up.mu.Lock()
	defer up.mu.Unlock()
	for {
		if up.closed {
			return gofakes3.ErrNoSuchUpload
		}
		if up.bufferLimit <= 0 || partNumber <= up.nextPart || up.buffered == 0 || size <= up.bufferLimit-up.buffered {
			up.buffered += size
			return nil
		}
		// ...
	}
}

Exploitation of this vulnerability requires network access to the rclone S3 service endpoint. The attacker first initiates a multipart upload session using a standard CreateMultipartUpload request to acquire a valid UploadID. On public, anonymous S3 deployments, this initial request does not require S3 authentication credentials.

The attacker then transmits a malicious UploadPart request specifying an out-of-order part number (e.g., PartNumber=2). The request contains an inflated Content-Length or X-Amz-Decoded-Content-Length header, such as 9223372036854775807. This extreme value triggers the integer overflow in the admission control system.

Once the comparison is bypassed, the handler processes the request and executes the allocation sequence. The lib/pool allocator tries to allocate thousands of 1 MiB pages to satisfy the oversized size parameter. The attacker does not need to send the actual request body payload, which allows the attack to be executed with minimal bandwidth.

The attacker can keep the TCP socket open without transmitting any data, which holds the reserved memory blocks in the server process heap. This leads to immediate physical RAM exhaustion, triggering the kernel's Out-Of-Memory (OOM) killer to terminate the rclone service.

The primary impact of CVE-2026-88045 is a complete Denial of Service (DoS) of the S3 storage service. When the rclone process is terminated by the operating system due to memory exhaustion, all active client connections are dropped, and all ongoing file synchronization operations are interrupted.

The vulnerability has a CVSS v3.1 base score of 7.5, reflecting a network attack vector with low complexity and no privileges required on anonymous instances. The impact is isolated to availability, as there is no associated threat of unauthorized data access, privilege escalation, or integrity modification.

Because the S3 endpoint is often exposed to public networks to facilitate remote storage access, this vulnerability presents a low-barrier vector for service disruption. Organizations relying on rclone as a backend daemon for data distribution are particularly vulnerable to operational outages.

The definitive solution for this vulnerability is to upgrade rclone to version 1.75.1 or later. This version contains the official patches that remove eager memory allocation and secure the admission control check against integer overflows. The release can be retrieved from the official repository release channel.

If upgrading the software is not immediately possible, several temporary workarounds should be applied to reduce the attack surface. First, ensure that anonymous access is disabled by requiring robust S3 credentials via the --auth-key option. This restricts the potential exploit audience to authenticated clients.

Additionally, administrators can configure a reverse proxy or Web Application Firewall (WAF) in front of the rclone service. The proxy should be configured to inspect S3 headers and drop requests containing anomalous or excessively large values in the Content-Length or X-Amz-Decoded-Content-Length headers, enforcing a reasonable upper bound such as 5 GiB.

Finally, reducing the socket timeout limits on front-end reverse proxies will terminate idle TCP connections. This prevents attackers from holding open connection channels to sustain the memory exhaustion state over an extended period.