CVE-2026-88045: 
Rclone vulnerability analysis and mitigation

CVE-2026-88045 is a memory exhaustion (Denial of Service) vulnerability in rclone's serve s3 streamed multipart upload path, allowing unauthenticated or authenticated network attackers to exhaust process or host memory. It affects rclone version 1.75.0 only; version 1.75.1 contains the fix. The vulnerability was published on September 10, 2026, with a CVSS v3.1 base score of 7.5 (High) (GitHub Advisory, Feedly).

The root cause is classified as CWE-789 (Memory Allocation with Excessive Size Value) and CWE-770 (Allocation of Resources Without Limits or Throttling). In cmd/serve/s3/multipart.go, the UploadPart handler calls multipart.NewRW().Reserve(contentLength) before reading any request body bytes, immediately allocating 1 MiB pool pages (via lib/pool/pool.go) proportional to the attacker-controlled Content-Length or X-Amz-Decoded-Content-Length header. The waitForTurn() admission logic unconditionally admits the first part of any upload (satisfying both partNumber <= up.nextPart and up.buffered == 0), bypassing the --multipart-streaming-buffer-limit guard regardless of declared size. A secondary integer overflow issue in the admission counter allowed negative or huge declared lengths to wrap the running total and admit further out-of-order parts past the buffer limit, also fixed in v1.75.1 (GitHub Advisory, Fix Commit, Overflow Fix).

Successful exploitation causes complete loss of S3 service availability: the rclone process can be terminated via OOM, or request handlers can be permanently blocked when the global memory semaphore cannot satisfy an oversized acquisition (which waits on context.Background() indefinitely). There is no confidentiality or integrity impact — the vulnerability is purely a Denial of Service primitive. Multiple concurrent connections multiply the memory reservation effect, and anonymous deployments (no auth_key configured) are exploitable without any credentials (GitHub Advisory).

A proof-of-concept exploit is publicly available in the GitHub Security Advisory, including concrete Python and Go code demonstrating header-only memory amplification against a real rclone S3 server (GitHub Advisory). The attack is fully automatable (no user interaction, no authentication required for anonymous deployments), and Feedly classifies the exploit confidence as high with a poc_steps label. The EPSS score is approximately 0.535%, and there is no evidence of in-the-wild exploitation or CISA KEV catalog listing as of the report date (Feedly).

1. Reconnaissance: Identify internet-facing or network-accessible rclone serve s3 instances running version 1.75.0. Check whether anonymous access is enabled (no auth_key set) by attempting an unauthenticated S3 API call.
2. Initiate a multipart upload: Send an HTTP POST to /bucket/object?uploads with Content-Length: 0. Parse the XML response to extract the UploadId value returned by the server.
3. Construct a malicious UploadPart request: Prepare an HTTP PUT to /bucket/object?partNumber=1&uploadId=<UploadId> with a large Content-Length header (e.g., 67108864 for 64 MiB, or larger). No valid S3 credentials are needed in anonymous mode.
4. Send headers only, withhold the body: Open a raw TCP connection and transmit only the HTTP request headers. Do not send any body bytes. Keep the TCP connection open.
5. Server allocates memory immediately: The server's UploadPart handler calls Reserve(contentLength) before reading any body, allocating 1 MiB pool pages proportional to the declared length (e.g., 64 pages for a 64 MiB declaration).
6. Multiply reservations: Open additional TCP connections and repeat steps 2–5 with new or the same upload IDs. Each open connection retains its memory reservation independently, multiplying total consumption.
7. Achieve DoS: Maintain enough concurrent open connections with large declared lengths to exhaust process or host memory, causing the rclone process to be OOM-killed or request handlers to block indefinitely (GitHub Advisory).

• Network: Unusual volume of HTTP POST requests to /bucket/<name>?uploads followed immediately by HTTP PUT requests to ?partNumber=1&uploadId=... with large Content-Length values but no corresponding body data; multiple long-lived TCP connections to the rclone S3 listener with no data transfer after the initial headers.
• Logs: rclone log entries containing ERROR : serve s3: unexpected EOF correlated with large declared part sizes; NOTICE: serve s3: No auth provided so allowing anonymous access indicating anonymous mode is active and being targeted.
• Process/System: Rapid increase in rclone process RSS memory without corresponding upload throughput; OOM killer events (dmesg showing Out of memory: Kill process for rclone); process exit with code 137 (SIGKILL) in container environments.
• Application Metrics: Pool in-use page count (pool.Global().InUse()) growing proportionally to incoming Content-Length headers without corresponding data reads; S3 service becoming unresponsive to legitimate clients (GitHub Advisory).

The primary remediation is to upgrade rclone to version 1.75.1, which removes the Reserve(contentLength) call from the untrusted HTTP path so the pool-backed buffer grows incrementally as body bytes are actually received, and also fixes the integer overflow in the admission counter (rclone v1.75.1 Release, Fix Commit). As interim mitigations: enable auth_key authentication to require valid S3 credentials (eliminating anonymous exploitation); bind the S3 listener to loopback or a trusted management network interface; and implement upstream network-level rate limiting and connection limits to reduce the impact of concurrent reservation attacks. Note that --multipart-streaming-buffer-limit and --max-buffer-memory are not effective mitigations for this vulnerability (GitHub Advisory).

The vulnerability was reported by researcher cyberlanc3r and remediated by rclone maintainer Nick Craig-Wood (ncw), who published the advisory and patch on September 4, 2026 (GitHub Advisory). The Italian CSIRT published multiple advisories referencing this CVE across their Telegram channel. Red Hat tracked the issue via Bugzilla and their CVE advisory page. No significant broader media coverage or notable independent researcher commentary was identified beyond the official advisory and standard vulnerability aggregator coverage.