CVE-2026-71191
MediumCVSS 6.0Exploitation Probability (EPSS)
Low risk21th percentile - higher than 21% of all known CVEs
Summary
In OpenStack Swift through 2.38.0, the S3API middleware does not enforce that semantic x-amz-* headers are covered by the SigV4 signature on presigned URL requests. An attacker with a presigned PUT URL can inject an unsigned X-Amz-Copy-Source header, causing Swift to perform a server-side copy from an arbitrary source object using the signer's authorization context. This allows reading any object the signer has access to, provided the target project_id, container name, and object name are known.
Risk Assessment
The risk is unauthorized data access — an attacker can read sensitive objects accessible to the presigned URL owner without having their own permissions. This affects all deployments using the default s3_acl=false configuration.
Recommendation
Immediately upgrade OpenStack Swift to a version newer than 2.38.0 where the vulnerability is fixed. Until then, consider changing s3_acl to true or restricting the use of presigned URLs.
Other vulnerabilities in OpenStack Swift
See all- CVE-2026-97149Medium
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, so the list of disallowed headers is the only defense. 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.
- CVE-2026-71192Medium
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.
- CVE-2026-71190High
In OpenStack Swift through 2.38.0, the proxy server Accept header parser contains a regular expression vulnerable to catastrophic backtracking (ReDoS). The "qdtext" pattern (?:[^"]|\\.)* allows an unauthenticated remote attacker to send a crafted Accept header that causes exponential CPU consumption in the proxy worker. A payload of 32 backslash-character pairs exceeds 30 seconds of CPU time. Repeated requests can exhaust all proxy worker threads, resulting in a complete denial of service.
- CVE-2026-50221Medium
In OpenStack Swift before version 2.37.2, the proxy-server does not strip internal update headers (X-Container-Host, X-Container-Device, X-Delete-At-Host, X-Delete-At-Device) from client requests before forwarding them to object-servers. An authenticated user with write access can inject these headers to redirect container update requests to an attacker-controlled server, enabling server-side request forgery (SSRF).
- CVE-2026-49017Medium
In OpenStack Swift before 2.36.2 and 2.37.2, the s3api middleware enters an infinite loop when processing a truncated aws-chunked PUT request body. The StreamingInput class repeatedly appends an empty buffer and re-reads, causing the proxy-server worker to become permanently unresponsive with increasing CPU and memory consumption. An authenticated attacker can exhaust all proxy-server workers, resulting in denial of service. The defect was introduced in Swift 2.36.0.
Original NVD description (English source)
In OpenStack Swift through 2.38.0, S3API middleware does not enforce that semantic x-amz-* headers are covered by the SigV4 signature on presigned URL requests. An attacker who obtains a presigned PUT URL can inject an unsigned X-Amz-Copy-Source header, causing Swift to perform a server-side copy from an arbitrary source object using the signer's authorization context. The attacker can read any object the signer has access to, provided the target project_id, container name, and object name are known. This affects all deployments using the default s3_acl=false configuration.
Vulnerability data from NVD (NIST) · CISA KEV · EPSS

