OpenStack Swift EUVD-2026-85786

Exploitation requires ALL of the following: (1) the deployment uses the shipped DEFAULT Swift proxy pipeline containing both the tempurl and copy middleware; (2) the deployment uses ACCOUNT-LEVEL TempURL keys; and (3) the attacker possesses a valid, unexpired PUT TempURL for at least one object. The attack is strictly bounded to a SINGLE account - copies across account boundaries are rejected - and the copied source must be an object in that same account. Limiting factors: it does not work against non-default pipelines lacking the copy middleware, does not cross account boundaries, and depends on the attacker legitimately holding or capturing a signed PUT TempURL (the capability token modeled as PR:L). No traditional user authentication or victim user interaction is required.

This is a genuine but bounded confidentiality issue rather than a high-urgency emergency. The vendor CVSS 4.0 vector (AV:N/AC:L/AT:N/PR:L/UI:N/VC:L/VI:N/VA:N, base 5.3, Medium) is consistent with the description: remote, low-complexity, but requiring possession of a valid signed PUT TempURL (reflected as PR:L) and limited to low confidentiality impact with no integrity or availability effect. CWE-184 (incomplete list of disallowed inputs) precisely captures the root cause - the disallowed-header list omits X-Copy-From. No EPSS score, no CISA KEV listing, and no public exploit code are provided in the input, so exploitation status is 'no public exploit identified at time of analysis.' The impact is contained by design: copies across account boundaries are rejected, so an attacker can only read objects within the same account for which they already hold a TempURL. One point worth verifying: because the flaw lets an attacker read ARBITRARY objects in the account (repeatably), the confidentiality impact is arguably higher than VC:L in aggregate - but per-request it remains partial, so VC:L is defensible. Net: a real priority for Swift operators running the default pipeline, but not a drop-everything item absent evidence of exploitation.

An attacker is legitimately given (or intercepts) a PUT TempURL for a single object in a Swift account - the normal use case for TempURL uploads. They send a PUT to that signed URL but add an X-Copy-From header naming a different, sensitive object in the same account; the copy middleware duplicates the victim object to the attacker-controlled destination, which the attacker then retrieves with a GET TempURL. No public exploit code is identified at time of analysis, but the technique is fully described and mechanically simple.