glance: OpenStack Glance: Server-Side Request Forgery allows internal URL access by administrators

In OpenStack Glance through 32.0.0, the /v2/tasks API accepts type=import tasks that bypass import_filtering_opts, allowing an admin to fetch internal URLs from the Glance service network (aka SSRF), as long as https:// or http:// is used. This API has been available only to admins since Xena, and it has been deprecated for several releases.

OpenStack Ironic: ipmitool: OpenStack Ironic: Arbitrary Code Execution via Remote Hardware Management

OpenStack Ironic before 35.0.1 allows ipmitool execution in a non-default configuration that has a console interface.

Octavia QoS Policy Authorization Bypass Preventing Policy Deletion

OpenStack Octavia through 18.0.0 mishandles quality of service (QoS) policy authorization. By associating another project's QoS policy with an amphora, an authenticated user may prevent deletion of that policy. All Octavia deployments are affected.

ironic: OpenStack Ironic: Autodetect deploy interface fails to run cleaning

In OpenStack Ironic before 38.0.1, the autodetect deploy interface may fail to run cleaning immediately after enrollment with, or changing to, the autodetect deploy interface.

oslo.messaging: openstack: OpenStack oslo.messaging: Man-in-the-middle attack via improper TLS hostname verification

An issue was discovered in OpenStack oslo.messaging 1.0.0 through 17.3.0. The oslo.messaging RabbitMQ driver does not perform TLS hostname verification when connecting to the message broker. When ssl_ca_file is configured, the driver enables certificate chain validation but does not pass the expected broker hostname into the underlying TLS stack. Any certificate signed by the deployment CA is accepted regardless of hostname, allowing an attacker who can intercept control-plane traffic to impersonate the RabbitMQ broker and perform a man-in-the-middle attack on RPC and notification traffic. All OpenStack services using oslo.messaging with RabbitMQ over TLS are affected.

OpenStack Keystone: OpenStack Keystone: Unauthorized cross-project access due to improper validation in EC2 credential creation

An issue was discovered in OpenStack Keystone before 29.0.2. POST /v3/credentials did not validate that the caller-supplied project_id for an EC2-type credential matched the project of the authenticating application credential. This allowed an attacker holding an unrestricted application credential for project A to create an EC2 credential targeting project B; a subsequent /v3/ec2tokens exchange would then issue a Keystone token scoped to project B while still carrying the original app_cred_id, enabling cross-project lateral movement within the credential owner's role footprint.

OpenStack Glance: OpenStack Glance: Server-Side Request Forgery via HTTP redirects in image import

OpenStack Glance before 29.1.1, 30.x before 30.1.1, and 31.0.0 is affected by Server-Side Request Forgery (SSRF). By use of HTTP redirects, an authenticated user can bypass URL validation checks and redirect to internal services. Only glance image import functionality is affected. In particular, the web-download and glance-download import methods are subject to this vulnerability, as is the optional (not enabled by default) ovf_process image import plugin.

openstack-designate: designate: mDNS NOTIFY handler DoS via pool-blind zone lookup

In OpenStack Designate before 22.0.2, the mDNS handler performs pool-blind lookups when resolving record queries and NOTIFY requests. When two zones with the same name exist across different pools, the lookup fails with a deterministic error, causing the handler to return REFUSED for all DNS queries through that path. The _handle_notify path is exploitable via a single unauthenticated UDP packet. This is independently reachable through the cross-tenant zone overlap described in a different recent CVE, and also affects legitimate same-tenant cross-pool configurations. BIND9 views do not mitigate this issue as mDNS is a shared service upstream of any view configuration.

openstack-designate: designate: cross-tenant DNS zone overlap via pool-scoped ownership checks when using AttributeFilter scheduler

In OpenStack Designate before 22.0.1, zone creation checks (_is_subzone, _is_superzone, and the duplicate-zone DB constraint) are scoped to the target pool only. An authenticated user can bypass these checks by scheduling a zone to a different pool via the AttributeFilter scheduler, creating an overlapping zone that conflicts with another tenant's zone. This enables cross-tenant DNS hijack (redirecting traffic to attacker-controlled IPs) and DNS denial of service (NODATA responses). Exploitation requires a multi-pool deployment with AttributeFilter enabled in scheduler_filters, which is a non-default but documented and supported configuration for self-service tiering.

openstack-neutron: openstack-neutron: Shared-network consumer can re-scope another project's subnets via subnetpool onboarding

In OpenStack Neutron before 28.0.2, the subnetpool onboarding API does not verify ownership of the target subnets. An authenticated user can onboard subnets from another project's shared network into their own subnetpool, mutating the victim's subnet state and altering L3 routing and address scope behavior for victim routers.

openstack-swift: openstack-swift: S3API presigned URL unsigned header authorization bypass

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.

openstack-swift: openstack-swift: Unauthenticated denial of service via catastrophic backtracking in Accept header parser

In OpenStack Swift through 2.38.0, the proxy server Accept header parser contains a regular expression vulnerable to catastrophic backtracking (ReDoS). The "qdtext" pattern (?:[^"]|\\.)* allows an unauthenticated remote attacker to send a crafted Accept header that causes exponential CPU consumption in the proxy worker. A payload of 32 backslash-character pairs exceeds 30 seconds of CPU time. No authentication is required. Repeated requests can exhaust all proxy worker threads, resulting in a complete denial of service.

Cross-Project Exposure of Portgroup Assignments

In OpenStack Ironic through 38.0.0, a project reader that makes a crafted request to Ironic can return Portgroups assigned to Nodes owned or leased by another project.

OpenStack Zaqar through 22.0.0 allows authentication bypass via an EXTRA-SPEC header when a UUID is known.

Openstack nova: vnc proxy can connect to the wrong vm

OpenStack Compute (Nova) Grizzly, Folsom (2012.2), and Essex (2012.1) allows remote authenticated users to gain access to a VM in opportunistic circumstances by using the VNC token for a deleted VM that was bound to the same VNC port.

Keystone: openstack keystone: denial of service via large http request with long tenant name

A flaw was found in OpenStack Keystone. A remote attacker could exploit this vulnerability by sending a large HTTP request, specifically by providing a long tenant name when requesting a token. This could lead to a denial of service, consuming excessive CPU and memory resources on the affected system.

ironic-python-agent: OpenStack Ironic Python Agent: Arbitrary code execution via malicious configuration

In OpenStack Ironic Python Agent through 11.6.0, a project-scoped user with the manager role can achieve arbitrary code execution on a running Ironic-Python-Agent via a maliciously constructed configuration, because the value of ntp_server is passed to a shell.

ironic-python-agent: ironic-python-agent: Credential extraction from bootc container deployment via /proc/1/root

In OpenStack Ironic Python Agent through 11.5.0, a malicious bootc container, when deployed using ironic-python-agent, may be able to extract the credentials used to download it.

openstack-ironic: openstack-ironic: Arbitrary IPMI command execution via send_raw deployment step

In OpenStack Ironic before 37.0.1, an Ironic user with the ability to deploy nodes using the IPMI management interface can maliciously use the send_raw step to send arbitrary IPMI commands to a node, bypassing Ironic's access control.

openstack-ironic: Prevent rehoming resources to nodes with different owner

OpenStack Ironic through before 37.0.1 allows creation or modification of nodes cross-project without authorization.