EUVD-2026-53050
GHSA-6p2v-36c6-f6m5
Severity by source
CVSS:4.0/AV:N/AC:L/AT:P/PR:L/UI:N/VC:H/VI:N/VA:N/SC:N/SI:N/SA:N/E:X/CR:X/IR:X/AR:X/MAV:X/MAC:X/MAT:X/MPR:X/MUI:X/MVC:X/MVI:X/MVA:X/MSC:X/MSI:X/MSA:X/S:X/AU:X/R:X/V:X/RE:X/U:X
Non-default s3_acl=true required (AC:H); valid S3 tenant credential needed (PR:L); cross-tenant data access represents a scope change (S:C) with high confidentiality impact only.
Primary rating from Vendor (mitre).
CVSS VectorVendor: mitre
Lifecycle Timeline
2DescriptionCVE.org
In OpenStack Swift through 2.38.0, the S3API middleware does not sanitize Swift-native control headers (X-Copy-From, X-Copy-From-Account) from S3 API requests when s3_acl=true. An attacker can inject these headers into a signed PUT request targeting their own bucket, causing Swift to perform a server-side copy from another tenant's private object. The source object authorization is bypassed because the S3API middleware has already authorized the request against the destination. The attacker can read any object whose project_id, container name, and object name are known, regardless of the source object's ACLs or ownership. This requires the non-default s3_acl=true configuration.
AnalysisAI
Cross-tenant object exfiltration in OpenStack Swift through 2.38.0 allows authenticated S3 API users to bypass source-object authorization by injecting Swift-native server-side copy headers (X-Copy-From, X-Copy-From-Account) into a signed S3 PUT request. The S3API middleware authorizes the request against the attacker-controlled destination bucket and then forwards the copy headers to Swift's copy engine, which executes the cross-tenant copy without re-evaluating the source object's ACLs or ownership - a classic confused-deputy flaw (CWE-863). Exploitation is constrained to deployments with the non-default s3_acl=true option enabled, and no public exploit is identified at time of analysis.
Technical ContextAI
OpenStack Swift provides object storage with an S3-compatible API surface implemented via its S3API middleware layer. When s3_acl=true is configured, the middleware emulates S3-style bucket and object ACL semantics rather than relying solely on Swift's native access control model. The flaw lies in the middleware's failure to strip or reject Swift-native control headers (X-Copy-From, X-Copy-From-Account) that arrive inside S3-signed PUT requests - headers that are meaningful to Swift's server-side copy subsystem but carry no S3 semantic meaning. Because the S3API authorization check is scoped only to the destination resource (the attacker's bucket), the copy operation that follows inherits the already-granted permission without independently verifying access to the named source object. This is a correct-authorization failure (CWE-863): the system authorizes an action but applies that authorization to the wrong resource. All versions through 2.38.0 are affected per CPE cpe:2.3:a:openstack:swift:*:*:*:*:*:*:*:*, as documented in OSSA-2026-030.
RemediationAI
Apply the fix documented in OSSA-2026-030 (https://security.openstack.org/ossa/OSSA-2026-030.html); a specific patched release version number is not present in the available data and has not been independently confirmed - operators should monitor the OpenStack release channels and the Launchpad bug (https://launchpad.net/bugs/2158733) for the exact fixed version. As an immediate compensating control, operators who do not require S3 ACL semantics should set s3_acl=false (the default), which eliminates the vulnerable code path entirely with no impact to core S3 object operations; note that this degrades ACL emulation fidelity for S3 clients that rely on bucket or object ACL APIs. If s3_acl=true is operationally required and the patch cannot be applied immediately, restrict S3 API endpoint access to explicitly trusted tenant networks via firewall rules or a dedicated internal endpoint - this trades accessibility for isolation and does not fix the underlying flaw.
Oracle MySQL through 5.5.52, 5.6.x through 5.6.33, and 5.7.x through 5.7.15; MariaDB before 5.5.51, 10.0.x before 10.0.2
Eval injection vulnerability in the create method in the Bookmarks controller in Foreman before 1.2.0-RC2 allows remote
The create method in app/controllers/users_controller.rb in Foreman before 1.2.0-RC2 allows remote authenticated users w
Systems with microprocessors utilizing speculative execution and speculative execution of memory reads before the addres
The Floppy Disk Controller (FDC) in QEMU, as used in Xen 4.5.x and earlier and KVM, allows local guest users to cause a
Memory Corruption was discovered in the cmsgpack library in the Lua subsystem in Redis before 3.2.12, 4.x before 4.0.10,
The IPTables firewall in OpenStack Neutron before 7.0.4 and 8.0.0 through 8.1.0 allows remote attackers to bypass an int
An issue in OpenStack magnum yoga-eom version allows a remote attacker to execute arbitrary code via the cert_manager.py
An Integer Overflow issue was discovered in the struct library in the Lua subsystem in Redis before 3.2.12, 4.x before 4
glibc contains a vulnerability that allows specially crafted LD_LIBRARY_PATH values to manipulate the heap/stack, causin
Buffer overflow in the pcnet_receive function in hw/net/pcnet.c in QEMU, when a guest NIC has a larger MTU, allows remot
Code injection in OpenStack Vitrage query parser allows authenticated users to execute arbitrary Python code through cra
Same weakness CWE-863 – Incorrect Authorization
View allSame technique Authentication Bypass
View allVendor StatusVendor
Share
External POC / Exploit Code
Leaving vuln.today