Bug 2491876 (CVE-2026-50221)

Summary:	CVE-2026-50221 openstack-swift: OpenStack Swift: SSRF via internal update header injection in proxy-server
Product:	[Other] Security Response	Reporter:	OSIDB Bzimport <bzimport>
Component:	vulnerability	Assignee:	Product Security <prodsec-ir-bot>
Status:	NEW ---	QA Contact:
Severity:	medium	Docs Contact:
Priority:	medium
Version:	unspecified	CC:	abarbaro, alizardo, dschmidt, eglynn, erezende, jchui, jhe, jjoyce, jlanda, jpretori, jschluet, kshier, ktsao, lhh, mburns, mgarciac, nboldt, oaljalju, psrna, simaishi, stcannon, teagle, yguenane
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 proxy-server. Internal container update routing headers (X-Container-Host, X-Container-Device, X-Delete-At-Host, X-Delete-At-Device) are not stripped from client requests before being forwarded to object-servers. An authenticated user with write access can inject these headers to redirect internal container update requests to an attacker-controlled server, resulting in server-side request forgery. This can lead to disclosure of internal cluster metadata and, when at-rest encryption is enabled, exposure of encrypted container-level key material. Additionally, the attacker can create unauthorized listings in arbitrary containers via the shard-range redirect mechanism.	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-06-23 18:02:29 UTC

In OpenStack Swift before 2.37.2, 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. The SSRF requests expose internal cluster metadata including storage policy indexes, partition mappings, device names, and when at rest encryption is enabled, cipher text and initialization vectors for the container-level encryption key. The attacker can also cause "ghost listings" in arbitrary containers via the shard-range redirect mechanism.