Bug 2539886 (CVE-2026-97149)

Summary: CVE-2026-97149 openstack-swift: openstack-swift: unauthorized read of other objects via TempURL and X-Copy-From
Product: [Other] Security Response Reporter: OSIDB Bzimport <bzimport>
Component: vulnerabilityAssignee: Product Security DevOps Team <prodsec-dev>
Status: NEW --- QA Contact:
Severity: medium Docs Contact:
Priority: medium    
Version: unspecifiedCC: eglynn, jjoyce, jpretori, jschluet, lhh, mburns, mgarciac
Target Milestone: ---Keywords: Security
Target Release: ---   
Hardware: All   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: ---
Doc Text:
A flaw was found in OpenStack Swift's tempurl middleware. A TempURL is a signed, time-limited link that should allow access to only one object. The signature does not cover extra request headers, and Swift did not block the X-Copy-From header on these signed upload requests. An attacker who already holds a valid upload TempURL for one object can name another object in the same account. Swift copies that object's contents into the allowed destination, and the attacker can then download it. This exposes data the TempURL was not meant to grant. The attacker must know the other object's container and name, and the copy cannot cross into a different account. Only deployments that use the tempurl middleware are affected.
Story Points: ---
Clone Of: Environment:
Last Closed: Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:

Description OSIDB Bzimport 2026-09-24 02:41:25 UTC
In OpenStack Swift before 2.38.2, the tempurl middleware does not reject the X-Copy-From header on PUT requests. A TempURL signature only covers the method, expiry, and path, and thus the list of disallowed headers is the only defense against a signed PUT request changing what the request does. An attacker holding a PUT TempURL for a single object can add an X-Copy-From header naming any object in the same account; the copy middleware copies that object to the destination, and the attacker then reads the victim's data back with a GET TempURL for the destination object. Copies across account boundaries are rejected. Only deployments using the shipped default proxy pipeline (tempurl and copy middleware) with account-level TempURL keys are affected.