GPU VulnDB

Database/Control plane, storage & DevOps

OpenStack Swift: S3API does not strip X-Copy-From, allowing cross-tenant object reads

CVSS 6.0CVE-2026-71192Control plane, storage & DevOpscurated

Impact

With the non-default s3_acl=true setting, the S3API middleware passes Swift-native X-Copy-From and X-Copy-From-Account headers through from a signed S3 request. Because the middleware has already authorized the request against the attacker's own destination bucket, Swift performs the server-side copy without checking the source object's ACLs or ownership. Any object whose project_id, container and object name are known can be copied into the attacker's bucket and read. For a GPU cloud using Swift as the shared object store for datasets, checkpoints and model artefacts, that is a direct cross-tenant read of training data and weights, with no write or delete effect on the victim.

Who can reach it

Any authenticated tenant with an S3 credential and a bucket of their own, over the object storage endpoint. Requires knowledge of the target's project id, container name and object name, and only affects deployments configured with s3_acl=true.

What to do

Apply the Swift fix from OSSA-2026-030 to the proxy nodes and restart swift-proxy-server; proxies are stateless, so roll them behind the load balancer without touching storage nodes. If patching has to wait, set s3_acl=false (the default) in the S3API middleware config and restart the proxies - the vulnerable path does not exist without it, at the cost of S3-style ACL support. Affects Swift through 2.38.0.

References

Related entries

All Control plane, storage & DevOps entries

This entry is curated: imported from vendor advisories with machine assistance, not yet individually verified. Confirm against your vendor's advisory before acting, and report anything wrong.