rclone EUVD-2026-109446

Requires 'rclone serve s3' running in its documented default anonymous mode - i.e. started without --auth-key or --auth-proxy - with multipart streaming enabled (the affected streaming implementation first shipped in v1.75.0) and the listener network-reachable by the attacker. Under that configuration no credential is needed (matching PR:N); if --auth-key or --auth-proxy is set, the attacker must first present an accepted S3 credential, so authentication reachability limits exposure. The attacker must send real body bytes for the admitted out-of-order parts (not header-only amplification). Per the advisory, binding the service to a trusted interface reduces reachability but does not correct the arithmetic, and disabling streaming takes a different, intentionally memory-buffered path and is not a safe mitigation for memory exhaustion; upgrading to v1.75.2 is the fix.

This is a genuine but bounded availability risk, not a top-tier emergency. The vendor CVSS 4.0 vector (AV:N/AC:L/AT:N/PR:N/UI:N) describes a network-reachable, low-complexity, unauthenticated, deterministic attack against the default anonymous configuration of 'rclone serve s3', with impact limited to availability (VA:L, no confidentiality or integrity). The vuln.today decision label is 'this_month' (not act_now/emergency), consistent with a resource-exhaustion denial of service rather than code execution or data compromise. Exploitation is not listed in CISA KEV, so there is no evidence of active exploitation; however, a complete working PoC reproducer (poc/poc.py) is published in the vendor GHSA advisory, so a functioning demonstration of the memory-limit bypass is public. No EPSS score was provided in the input, so exploitation-probability cannot be compared against KEV/PoC signals here. One signal tension worth flagging: the vendor scores availability as VA:L (the bounded reproducer measured only ~49 MiB RSS growth), but the advisory itself states that repeating admitted parts or uploads 'can exhaust the rclone process or its host and interrupt all S3 operations served by that process' - a realistic sustained attack points toward full service outage, which I assess as higher availability impact than VA:L. Overall: a real priority to patch for anyone exposing serve s3 anonymously to untrusted networks, but moderate rather than critical given availability-only impact and no confirmed in-the-wild use.

An attacker who can reach an anonymously-exposed 'rclone serve s3' listener creates a multipart upload, then opens two concurrent PUT requests for the current part (partNumber=1), each declaring 5,000,000,000,000,000,000 bytes while withholding the bodies; summing the two declared lengths wraps the signed int64 reorder-accounting field to a large negative value. With the memory cap now defeated, the attacker streams real out-of-order parts that should have been rejected, and by repeating this exhausts the process or host memory, taking the S3 service offline. A complete working PoC demonstrating the 1 MiB-limit bypass is published in the vendor advisory.