RustFS CVE-2026-45042

Attacker must (1) hold valid RustFS credentials with s3:GetObject permission on at least one source object and s3:PutObject permission on a destination bucket - consistent with PR:L in the CVSS vector - and (2) issue the S3 UploadPartCopy multipart operation specifying an x-amz-copy-source that the destination bucket's policy was meant to disallow; no user interaction, no special platform, and no non-default configuration is required, and the RustFS instance must be running any version prior to 1.0.0-beta.2. Exploitation is limited by the requirement for pre-existing authenticated access and is only security-relevant in deployments that rely on per-bucket copy-source policy constraints (typical of multi-tenant or policy-segmented object stores); single-tenant deployments where one principal already has cross-bucket access derive no additional capability from the bug.

The CVSS 4.0 vector AV:N/AC:L/AT:N/PR:L/UI:N/VC:H/VI:N/VA:N (base 7.1) indicates a network-reachable, low-complexity attack requiring low privileges, no user interaction, with high confidentiality impact but no integrity or availability impact - consistent with a data-exfiltration / unauthorized-copy primitive rather than RCE or destruction. The PR:L requirement is significant: the attacker must already hold valid credentials with GetObject on some source and PutObject on some destination, so this is a privilege-escalation / lateral-movement issue inside a multi-tenant or policy-segmented deployment rather than an unauthenticated internet-facing flaw. EPSS, KEV status, SSVC decision values, and POC availability were not provided in the input; no public exploit was identified at time of analysis and the CVE is not present in CISA KEV. Real-world priority is moderate-to-high for operators running RustFS as a shared/multi-tenant object store where bucket-level policy isolation is part of the security model, and lower for single-tenant deployments where any authenticated principal would already have broad object access.

An authenticated tenant in a shared RustFS deployment initiates a multipart upload to a destination bucket they control, then issues UploadPartCopy requests referencing objects in a second bucket whose policy was intended to forbid being used as a copy source to that destination; RustFS approves each request because GetObject and PutObject are evaluated independently, and the attacker assembles a complete copy of the restricted objects inside their own bucket. No public proof-of-concept was identified at time of analysis, but the attack is straightforward to script against any S3 SDK given valid credentials.