Summary
A server-side request forgery vulnerability in the VMware datastore driver of OpenStack glance_store allows an authenticated attacker to supply an image location URI that points to an external server. During request retries, sensitive authentication headers may be forwarded to the attacker-controlled destination.
Affected context
The issue occurs in deployments using the VMware datastore driver when image locations can be influenced by authenticated users and the retry path sends requests without sufficiently validating the destination host. Risk increases when authentication headers contain credentials or tokens accepted by internal services.
Exploit preconditions
- Attack surface: OpenStack glance_store image location handling and VMware datastore requests
- Required access: Valid authentication and permission to provide or influence an image location URI
- Trigger point: A request retry involving the crafted external destination
- Why exploitation is possible: The destination host is not adequately validated before sensitive authentication headers are attached to the outgoing request
Why this happens
The vulnerability results from insufficient destination validation in an HTTP request retry path. The driver trusts a user-influenced image location and forwards authentication headers before confirming that the destination belongs to an approved host or service boundary. This behavior maps to CWE-918: Server-Side Request Forgery, because attacker-controlled input can influence server-side network requests and their associated credentials.
Potential impact
- Sensitive authentication headers may be disclosed to an external server
- Internal services may receive unauthorized requests from the OpenStack environment
- Cloud metadata or internal endpoint information could be exposed
- The attacker could potentially pivot toward additional systems accessible from the deployment
- Service integrity or confidentiality may be affected
General mitigation guidance
Mitigation generally focuses on reducing trust in user-controlled image locations and enforcing destination-aware request controls.
Common defensive patterns include:
- Allowing requests only to explicitly approved datastore hosts and schemes
- Validating the resolved destination before every request and retry
- Separating credential attachment from generic outbound request construction
- Never forwarding authentication headers across trust boundaries
- Applying network egress restrictions and least-privilege service permissions
- Using short-lived, narrowly scoped credentials where authentication is required
- Treating redirects, retries, and DNS resolution changes as fresh validation points
How teams detect issues like this
Organizations can look for:
- Static analysis findings involving user-controlled URLs, outbound HTTP clients, and authentication-header propagation
- Code review signals such as retry helpers that reuse headers without revalidating destinations
- Tests covering external hosts, redirects, alternate address resolution, and retry behavior
- Network monitoring for unexpected outbound requests from glance services
- Policy enforcement that restricts cloud-service egress to approved destinations
- Automated security review tools that identify SSRF-prone request construction
