CVE-2026-71191: OpenStack Swift · Incorrect Authorization
Affects OpenStack SwiftSource CVE Database V5
Not known to be exploited · CVSS 6.0 Medium · fixed in 2.37.3 : update OpenStack Swift when convenient.
Data as of 3 Nov 2026, 22:58 UTC
- EPSS
- 0.5% chance of exploitation in 30 days – higher than 46% of CVEsExploit Prediction Scoring System: the likelihood attackers will use this flaw soon.
- Patch
- Available – fixed in 2.37.3, 2.36.3, 2.35.4
CVSS:4.0/AV:N/AC:L/AT:P/PR:L/UI:N/VC:H/VI:N/VA:N/SC:N/SI:N/SA:NExploitation evidence
Disclosed: evidence found.
CVE published 5 Aug 2026
Detectable: no evidence on record.
No public nuclei template indexed
Weaponized: no evidence on record.
No public exploit code indexed in Metasploit or Exploit-DB
Exploited in the wildExploited: no evidence on record.
Not in CISA KEV and no source reports exploitation
Observed by OffSeq MirageSeen by Mirage: no evidence on record.
No attack traffic recorded by OffSeq Mirage sensors
A missing step is not evidence of safety. Sources: cve.org (opens in a new tab), the Metasploit, Exploit-DB and nuclei-templates index as of 3 Nov 2026.
What to do
Upgrade OpenStack Swift to 2.37.3, 2.36.3 or 2.35.4.
Affected software
| Product | Affected | Fixed in |
|---|---|---|
| OpenStackSwift | Affected
| Fixed in
|
AI-suggested
Since OpenStack Swift is a cloud service, the vendor manages remediation server-side. A patch is available for this vulnerability. Users should verify with the vendor advisory that their deployment has been updated to a fixed version or that the cloud service has been patched. No additional user action is required if the service is managed by the vendor and patched accordingly.
Description
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.