Executive brief
rclone's S3 server reserves memory based on request headers before reading the actual request body, allowing an attacker to cause memory exhaustion with just a crafted HTTP header. An unauthenticated client can declare a very large part size in a multipart upload and keep the connection open, forcing the server to allocate gigabytes of RAM without sending any actual data. Multiple concurrent requests or uploads can exhaust available memory and crash the service.
Technical details
The vulnerability is a resource exhaustion flaw in rclone's S3 multipart upload handling. In streamed multipart mode, the `UploadPart` handler calls `multipart.NewRW().Reserve(contentLength)` using the attacker-controlled `Content-Length` or `X-Amz-Decoded-Content-Length` header, allocating 1 MiB pool pages immediately before `io.Copy` reads any request body bytes. The admission logic (`waitForTurn`) permits the current in-order part regardless of size when the buffer is empty, even if it exceeds the `--multipart-streaming-buffer-limit`. An attacker can send a PUT request declaring Content-Length of 64 MiB or more and never send the body, retaining the allocation. Multiple uploads or concurrent connections amplify the effect. The default S3 configuration allows anonymous access (no `auth_key` required), so unauthenticated network clients on any network segment can trigger this. Affected versions are v1.75.0 and development builds with streamed multipart support; a patch is available in v1.75.1.
Affected products
- rclone rclone 1.75.0
Timeline
- 2026-09-04: disclosed: GitHub Security Advisory published
- 2026-09-10: patched: Patched in version 1.75.1