CVE-2026-50221: OpenStack Swift Header Injection SSRF Vulnerability
OpenStack Swift's proxy server fails to filter out special internal headers from client requests before sending them to storage servers. An attacker with legitimate write access can exploit this to redirect storage operations to servers they control, exposing sensitive cluster information like encryption keys and internal topology details. This is a server-side request forgery (SSRF) vulnerability that requires existing authentication but can cause significant data exposure.
Source data · NVD / CISA · public domain
- CVSS
- 3.1 · 5.4 MEDIUM · CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:L/I:L/A:N
- Weaknesses (CWE)
- CWE-918
- Affected products
- 1 configuration(s)
- Published / Modified
- 2026-06-23 / 2026-06-29
NVD description (verbatim)
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.
4 reference(s) · View on NVD →
SEC.co analysis · AI-assisted, reviewed against source
Technical summary
CVE-2026-50221 is an SSRF vulnerability in OpenStack Swift versions before 2.37.2 affecting the proxy-server component. The proxy fails to strip four internal headers—X-Container-Host, X-Container-Device, X-Delete-At-Host, and X-Delete-At-Device—from authenticated client requests before forwarding them to backend object-servers. An authenticated attacker can inject these headers to redirect container update operations to attacker-controlled endpoints. The resulting SSRF requests leak internal cluster metadata including storage policy indexes, partition mappings, device identifiers, and (when encryption is configured) ciphertext and initialization vectors for container-level encryption keys. Additionally, the attacker can create 'ghost listings' in arbitrary containers by exploiting the shard-range redirect mechanism.
Business impact
This vulnerability affects confidentiality and integrity of OpenStack Swift deployments. Data exposure includes encryption key material and cluster topology, which could facilitate further attacks or policy violations in regulated environments. Ghost listings could corrupt container metadata visibility, potentially affecting backup verification, compliance auditing, and storage management workflows. Organizations relying on Swift for sensitive data storage may face disclosure risks if they allow untrusted users with write access.
Affected systems
OpenStack Swift installations running versions prior to 2.37.2 are affected. Any deployment exposing the Swift proxy API to authenticated users—particularly multi-tenant environments—is in scope. The vulnerability requires legitimate write credentials, so risk depends on user access policies and the sensitivity of what data is stored.
Exploitability
Exploitation requires valid authentication and write access to at least one container, a moderate barrier in managed deployments but a low barrier in open or developer environments. The attack is network-accessible and straightforward to execute once credentials are obtained. No user interaction is needed. The CVSS score of 5.4 (MEDIUM) reflects the authentication requirement but acknowledges the sensitive nature of leaked metadata.
Remediation
Upgrade OpenStack Swift to version 2.37.2 or later. Verify the patch version against your vendor advisory before deployment. For environments unable to patch immediately, restrict write access to trusted users and monitor proxy server logs for suspicious header patterns in client requests, particularly X-Container-Host and X-Delete-At-Host headers from non-administrative clients.
Patch guidance
Apply the official OpenStack Security Advisory for CVE-2026-50221, which is incorporated into Swift 2.37.2. Test the patch in a non-production environment to ensure compatibility with your deployment's custom middleware or extensions. If you maintain a custom proxy-server implementation, audit your request validation logic for similar header-stripping gaps. Verify the patch version against the upstream security advisory at security.openstack.org.
Detection guidance
Monitor proxy-server access logs for authenticated requests containing the headers X-Container-Host, X-Container-Device, X-Delete-At-Host, or X-Delete-At-Device—these should rarely appear in legitimate client requests and are diagnostic of exploitation attempts. Inspect outbound connections from proxy servers to unexpected hosts during container operations. Review container shard-range entries for unexpected mappings or ghost entries that do not correspond to real storage nodes. Correlate write operations from low-privilege users with metadata exposure events.
Why prioritize this
Although the CVSS score is MEDIUM, this vulnerability is significant for data-sensitive deployments because it directly exposes encryption key material and cluster topology to authenticated attackers. It is not currently in CISA's Known Exploited Vulnerabilities catalog, but the exploitation path is straightforward. Prioritize patching in multi-tenant Swift clusters or environments handling regulated data; lower priority for single-tenant or air-gapped deployments with strict access controls.
Risk score, explained
The CVSS 3.1 score of 5.4 reflects: (1) network accessibility (AV:N) and low attack complexity (AC:L) favoring the attacker, (2) requirement for prior authentication (PR:L) reducing the threat population, and (3) impact on confidentiality (C:L) and integrity (I:L) of cluster metadata without system availability impact (A:N). The score underweights the sensitivity of encryption key exposure; organizations handling cryptographic material should treat this as higher priority than the base score suggests.
Frequently asked questions
Who can exploit this vulnerability?
Any user with valid credentials and write access to at least one container in the affected Swift cluster. This includes legitimate application users and developers in environments where write access is broadly granted.
What encryption keys are at risk?
Container-level encryption keys used for at-rest encryption (when enabled) are exposed via ciphertext and initialization vectors leaked in SSRF responses. Full decryption would require additional attack steps, but the key material itself is disclosed to the attacker.
Do I need to rotate keys after a suspected compromise?
If you suspect exploitation and at-rest encryption is enabled, rotate container-level encryption keys as a precaution. Determine whether ciphertext was accessed in logs and whether decryption keys are stored separately; if so, assess the decryption risk independently.
Can this vulnerability be exploited without network access to the Swift proxy?
No. The attacker must reach the Swift proxy API over the network and possess valid authentication. Air-gapped deployments or those behind strict network ACLs have reduced exposure, but patching is still essential for defense-in-depth.
This analysis is based on the CVE record and OpenStack security advisories published through June 29, 2026. Exploit code and detailed proof-of-concept steps are not provided. Organizations should verify patch availability and compatibility with their specific Swift version and deployment before applying updates. Threat intelligence, including KEV status and active exploitation, may change; consult CISA and OpenStack security channels for the latest information. This content is for informational purposes and does not constitute professional security advice. Source: NVD (public-domain), retrieved 2026-07-29. Analysis generated by SEC.co (claude-haiku-4-5).
Related vulnerabilities
- CVE-2025-58175MEDIUMGeoServer SSRF Vulnerability in Proxy Configuration
- CVE-2026-10052MEDIUMQuay SSRF in LDAP/SMTP Validation—Internal Network Reconnaissance Risk
- CVE-2026-10177MEDIUMSSRF in Aider-AI Aider 0.86.3 AWS Metadata Endpoint
- CVE-2026-10239MEDIUMJeecgBoot Server-Side Request Forgery (SSRF) in Word Editing Module
- CVE-2026-10240MEDIUMJeecgBoot SSRF Vulnerability in /airag/airagModel/test Endpoint
- CVE-2026-10241MEDIUMJimuReport SSRF in File Download Function – Patch to 3.9.2
- CVE-2026-10274MEDIUMServer-Side Request Forgery in aem-mcp-server
- CVE-2026-10276MEDIUMJenkins-server-mcp SSRF Vulnerability (0.1.0)