| CVE |
Vendors |
Products |
Updated |
CVSS v3.1 |
| A Server-Side Request Forgery (SSRF) vulnerability exists in the Image API (v2) of OpenStack Glance. When the show_multiple_locations configuration option is enabled in glance-api.conf, an authenticated attacker can manipulate the locations attribute of an image in the queued state by sending a crafted HTTP PATCH request |
| An issue in the VMware datastore driver of OpenStack glance_store. When an authenticated attacker provides a maliciously crafted image location URI pointing to an external server, the _retry_request function fails to validate the destination host before attaching sensitive authentication headers. |
| In OpenStack Zaqar before 22.0.2, WSGI transport mishandles the URL-Signature header. By sending a request with an empty URL-Signature header, an unauthenticated remote attacker who knows a target project's UUID may bypass both Keystone authentication and pre-signed URL verification, resulting in the ability to read, enumerate, create, and delete that project's queues, messages, claims, and subscriptions. By additionally claiming an administrative role, the attacker may also perform administrative operations, such as managing pools and flavors in admin_mode deployments. Only deployments using the WSGI transport with an authentication strategy configured are affected; the websocket transport is not affected. |
| In OpenStack Octavia before 18.0.1, the Amphora provider driver did not validate the listener and pool tls_ciphers field for control characters. The value is written verbatim into the HAProxy configuration generated on the amphora, and thus an authenticated project member who owns a TLS-enabled load balancer can embed a newline and inject arbitrary HAProxy configuration directives. Only deployments using the Amphora provider are affected. |
| 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, and thus the list of disallowed headers is the only defense against a signed PUT request changing what the request does. 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 for the destination object. Copies across account boundaries are rejected. Only deployments using the shipped default proxy pipeline (tempurl and copy middleware) with account-level TempURL keys are affected. |
| In OpenStack Swift before 2.36.2 and 2.37.2, 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 handling the request to become permanently unresponsive with increasing CPU and memory consumption. An authenticated attacker can systematically exhaust all proxy-server workers, resulting in denial of service. The defect was introduced in Swift 2.36.0. |
| In OpenStack Blazar before 17.0.1, the V2 lease API does not enforce object-level authorization on its update and delete operations (PUT /v2/leases/{lease_id} and DELETE /v2/leases/{lease_id}). The policy authorize() wrapper attempts to load the target lease to build the authorization target from its owner, but it looks up the lease under the keyword "lease_id" whereas the controller methods name the parameter "id" (and the wsme_pecan.wsexpose wrapper delivers it positionally). The lookup returns None, and thus authorization falls back to the requesting user's own project_id/user_id instead of the target lease owner. Any authenticated user who knows a lease ID can therefore modify or delete leases belonging to other users and projects, bypassing the intended ownership check. |
| In OpenStack Octavia before 18.0.1, the Amphora provider driver did not reject control characters in the L7 policy redirect_url and redirect_prefix fields. The RFC 3986 URL validator percent-encodes control characters before validating, and thus newlines passed structural checks, but Octavia stored and wrote the raw unencoded value directly into the HAProxy configuration generated on the amphora. An authenticated project member who owns a load balancer can therefore inject arbitrary HAProxy directives through a REDIRECT_TO_URL L7 policy. Only deployments using the Amphora provider are affected. |
| In OpenStack Blazar before 17.0.1, the V2 lease listing operation (GET /v2/leases) returns leases for every project without enforcing project scoping or an administrator-only policy. Any authenticated user with access to the Blazar REST API can enumerate leases belonging to other tenants, exposing lease IDs, reservation IDs, resource IDs, and reservation metadata. The exposed lease IDs also enable the object-level authorization bypass tracked in the companion request, allowing an attacker to then modify or delete the enumerated leases. |
| An SSRF issue was discovered in OpenStack Glance before Newton. The 'copy_from' feature in the Image Service API v1 allowed an attacker to perform masked network port scans. With v1, it is possible to create images with a URL such as 'http://localhost:22'. This could then allow an attacker to enumerate internal network details while appearing masked, since the scan would appear to originate from the Glance Image service. |
| An issue was discovered in OpenStack Keystone before 29.0.3. Tokens obtained via delegated authentication methods (EC2 credentials, application credentials, OAuth1 access tokens, and trusts) are not blocked from creating, modifying, or deleting credentials via the /v3/credentials API. EC2-derived tokens can additionally read credential blobs, exposing TOTP MFA seeds and other secrets. Also, PATCH /v3/credentials does not validate the requested post-update project_id, allowing any delegated token to move a credential to an unauthorized project. All Keystone deployments using delegated authentication are affected. |
| In OpenStack Glance before 32.0.1, the location API does not validate destination hosts when adding an HTTP location to an image. Unlike the web-download import path, the location API only checks the URL scheme and does not apply the import_filtering_opts host restrictions. An authenticated user can add a location pointing to internal endpoints such as the cloud metadata service (169.254.169.254), and retrieve the response by downloading the image data. This affects both the new POST /v2/images/{id}/locations API and the old PATCH API when show_multiple_locations is enabled. Deployments with the HTTP store backend enabled are affected. |
| OpenStack Ironic through 38.0.0 may send a username and password to an unexpected remote host when Image Service is configured for HTTP(S) Basic Authentication. |
| An issue was discovered in OpenStack Nova before 30.2.2, 31 before 31.2.1, and 32 before 32.1.1. By writing a malicious QCOW header to a root or ephemeral disk and then triggering a resize, a user may convince Nova's Flat image backend to call qemu-img without a format restriction, resulting in an unsafe image resize operation that could destroy data on the host system. Only compute nodes using the Flat image backend (usually configured with use_cow_images=False) are affected. |
| In OpenStack Keystone before 29.0.3, any authenticated user holding role:reader on any project can list every project-scoped role assignment under any domain by passing a domain ID as scope.project.id with include_subtree to the GET /v3/role_assignments endpoint. The domain's project record has domain_id=null, causing the policy domain_id check to pass for any caller. With include_names, the response discloses the names and home-domain IDs of every user, group, project, and role involved. The literal "default" domain ID works against any deployment created with keystone-manage bootstrap. An attacker can harvest domain IDs from the response and repeat the query to map role assignments across the entire cloud. This is caused by misuse of "None" in
list_role_assignments_for_tree. |
| A server-side request forgery (SSRF) vulnerability was found in OpenStack Glance. The web-download image import method allows authenticated users to provide a URI from which the Glance service fetches data. Due to insufficient default host filtering, an attacker with standard tenant credentials can make Glance issue HTTP requests to arbitrary internal network hosts, including the cloud metadata service. The fetched response is stored as image data and can be downloaded by the attacker, enabling exfiltration of sensitive internal data such as cloud instance credentials. |
| A flaw was found in OpenStack Glance. The web-download image import method can bypass host-based blocklist filtering. When an operator configures disallowed_hosts with IP addresses to block access to internal services, an attacker can circumvent this protection by using a hostname that resolves to the blocked IP address. The hostname-to-IP resolution result is not used for blocklist comparison, allowing an authenticated user to force the Glance server to make requests to internal network services that were intended to be blocked. |
| An issue was discovered in OpenStack ironic-python-agent 1.0.0 through 11.5.0. Ironic Python Agent (IPA) sometimes executes grub-install from within a chroot of the deployed partition image, leading to code execution in the case of a malicious image. |
| In OpenStack Keystone before 29.0.3, tokens obtained via OAuth1 access token, application credential, or trust-scoped authentication could create new long-lived credentials or authorize new delegations that persist independently of, and outlive, the credential used to obtain them. The delegation restrictions that block these operations did not consistently apply to all delegated token types, allowing an OAuth1-scoped token, for example, to create application credentials or authorize OAuth1 request tokens despite those operations being restricted for other delegated token types. All Keystone deployments that permit delegated authentication through OAuth1 access tokens, application credentials, or trusts are affected. |
| In OpenStack Keystone before 29.0.3, tokens obtained via delegated authentication mechanisms (OAuth1 access tokens, application credentials, trusts) could be submitted to the token-method authentication path for reauthentication to escape their intended project scope. When an application credential token was presented with no explicit scope, Keystone would issue a new token scoped to the credential owner's default project rather than the project for which the credential was issued, bypassing the intended project boundary. All Keystone deployments that permit delegated authentication through OAuth1 access tokens, application credentials, or trusts are affected. |
