In OpenStack Mistral through 23.0.0, the /v2/maintenance API controller clears the request context and calls the maintenance service directly without any policy enforcement. Any holder of a valid Mistral token, regardless of assigned role, can read and change the service's cluster-wide maintenance state. Setting the state to PAUSED stops processing of new workflow and execution objects across all tenant projects until an operator restores it.

Last updated 6 June 2026

A Server-Side Request Forgery (SSRF) vulnerability exists in the Image API (v2) of OpenStack Glance. When the showmultiplelocations 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

OpenStack Ironic before 39.0.1 sometimes allows a user to change the maintenance setting on a node via PATCH to /v1/nodes/{ident} - in other words, not using the specific maintenance endpoint.

An issue was discovered in OpenStack Nova before 23.2.2, 24.x before 24.1.2, and 25.x before 25.0.2. By creating a neutron port with the direct vnictype, creating an instance bound to that port, and then changing the vnictype of the bound port to macvtap, an authenticated user may cause the compute service to fail to restart, resulting in a possible denial of service. Only Nova deployments configured with SR-IOV are affected.

An issue was discovered in OpenStack Cinder before 19.1.2, 20.x before 20.0.2, and 21.0.0; Glance before 23.0.1, 24.x before 24.1.1, and 25.0.0; and Nova before 24.1.2, 25.x before 25.0.2, and 26.0.0. By supplying a specially created VMDK flat image that references a specific backing file path, an authenticated user may convince systems to return a copy of that file's contents from the server, resulting in unauthorized access to potentially sensitive data.

An issue was discovered in OpenStack Swift before 2.28.1, 2.29.x before 2.29.2, and 2.30.0. By supplying crafted XML files, an authenticated user may coerce the S3 API into returning arbitrary file contents from the host server, resulting in unauthorized read access to potentially sensitive data. This impacts both s3api deployments (Rocky or later), and swift3 deployments (Queens and earlier, no longer actively developed).

An uncontrolled resource consumption flaw was found in openstack-neutron. This flaw allows a remote authenticated user to query a list of security groups for an invalid project. This issue creates resources that are unconstrained by the user's quota. If a malicious user were to submit a significant number of requests, this could lead to a denial of service.

An authorization flaw was found in openstack-barbican. The default policy rules for the secret metadata API allowed any authenticated user to add, modify, or delete metadata from any secret regardless of ownership. This flaw allows an attacker on the network to modify or delete protected data, causing a denial of service by consuming protected resources.

An authorization flaw was found in openstack-barbican, where anyone with an admin role could add secrets to a different project container. This flaw allows an attacker on the network to consume protected resources and cause a denial of service.

Open Redirect vulnerability in Horizon Web Dashboard 19.4.0 thru 20.1.4 via the successurl parameter.

A flaw was found in the openstack-barbican component. This issue allows an access policy bypass via a query string when accessing the API.

A flaw was found in Keystone. There is a time lag (up to one hour in a default configuration) between when security policy says a token should be revoked from when it is actually revoked. This could allow a remote administrator to secretly maintain access for longer than expected.

A flaw was found in python-oslo-utils. Due to improper parsing, passwords with a double quote ( " ) in them cause incorrect masking in debug logs, causing any part of the password after the double quote to be plaintext

An incomplete fix for CVE-2023-1625 in openstack-heat was discovered. Some sensitive information may still be disclosed through openstack stack abandon command even with the hidden feature set to True and CVE-2023-1625 fix applied.

References:

https://storyboard.openstack.org/#!/story/2011007

An access-control flaw was found in the OpenStack Orchestration (heat) service before 8.0.0, 6.1.0 and 7.0.2 where a service log directory was improperly made world readable. A malicious system user could exploit this flaw to access sensitive information.

Description An access-control flaw was found in the Octavia service when the cloud platform was deployed using Red Hat OpenStack Platform Director. An attacker could cause new amphorae to run based on any arbitrary image. This meant that a remote attacker could upload a new amphorae image and, if requested to spawn new amphorae, Octavia would then pick up the compromised image.

Mitigation To prevent this vulnerability: 1. Update Octavia's configuration setting (octavia.conf) to ampimageownerid = $UUIDOFSERVICEPROJECT on all Octavia nodes. 2. Enable the new configuration by restarting both octaviaworker and octaviahealthmanager.

In OpenStack Murano through 16.0.0, when YAQL before 3.0.0 is used, the Murano service's MuranoPL extension to the YAQL language fails to sanitize the supplied environment, leading to potential leakage of sensitive service account information.

OpenStack Manila <7.4.1, >=8.0.0 <8.1.1, and >=9.0.0 <9.1.1 allows attackers to view, update, delete, or share resources that do not belong to them, because of a context-free lookup of a UUID. Attackers may also create resources, such as shared file systems and groups of shares on such share networks.

OpenStack Murano before 1.0.3 (liberty) and 2.x before 2.0.1 (mitaka), Murano-dashboard before 1.0.3 (liberty) and 2.x before 2.0.1 (mitaka), and python-muranoclient before 0.7.3 (liberty) and 0.8.x before 0.8.5 (mitaka) improperly use loaders inherited from yaml.Loader when parsing MuranoPL and UI files, which allows remote attackers to create arbitrary Python objects and execute arbitrary code via crafted extended YAML tags in UI definitions in packages.

A vulnerability was found in Heat. By launching a new Heat stack with a local URL an authenticated user may conduct network discovery revealing internal network configuration.

Upstream bug:

https://bugs.launchpad.net/ossa/+bug/1606500

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 usecowimages=False) are affected.

An issue was discovered in OpenStack Keystone 14 through 26 before 26.1.1, 27.0.0, 28.0.0, and 29.0.0. Restricted application credentials can create EC2 credentials. By using a restricted application credential to call the EC2 credential creation API, an authenticated user with only a reader role may obtain an EC2/S3 credential that carries the full set of the parent user's S3 permissions, effectively bypassing the role restrictions imposed on the application credential. Only deployments that use restricted application credentials in combination with the EC2/S3 compatibility API (swift3 / s3api) are affected.

Unconstrained disk format handling vulnerability in OpenStack Nova when invoking the qemu-img utility. The flaw occurs because Nova does not strictly enforce the expected disk image format before calling qemu-img. An authenticated attacker can write a crafted QCOW2 header to a raw ephemeral or root disk. When Nova later performs operations such as instance resize, qemu-img interprets the disk as QCOW2 and overwrites arbitrary files on the compute host that Nova has write access to. This can be exploited without additional privileges or user interaction, allowing attackers to destroy other users’ data, corrupt Nova-managed files, or cause denial of service on the compute node.

An issue was discovered in OpenStack Keystone before 29.0.2. When combined with an application credential impersonation vulnerability, an attacker with the member role on a project can escalate to admin by chaining unrestricted application credentials with Keystone trusts. The impersonated token carries the victim's identity, which passes the trustor validation check. Keystone then validates the delegated roles against the victim's actual role assignments in the database, not the roles on the requesting token. This allows the attacker to create a trust delegating the victim's admin role to themselves. The trust persists independently, and additional trusts and application credentials can be created to maintain access. All actions are logged under the victim's identity.

Affects

- Nova: >=18.0.0 <31.3.1, >=32.0.0 <32.2.1, >=33.0.0 <33.0.2

Description Erichen from the Institute of Computing Technology, Chinese Academy of Sciences reported that Nova's server create API does not strip internal scheduler hints. An authenticated user can bypass Placement resource claims and scheduling constraint enforcement, including availability zone, host aggregate, and image trait restrictions. The resulting instance has no Placement allocation, which can lead to compute node resource exhaustion and cross-tenant data persistence on NVMe devices after instance deletion. Deployments running Nova 18.0.0 or later are affected.

Patches

- https://review.opendev.org/993604 (2025.1/epoxy) - https://review.opendev.org/993603 (2025.2/flamingo) - https://review.opendev.org/993602 (2026.1/gazpacho) - https://review.opendev.org/993601 (2026.2/hibiscus)

Credits - Erichen from Institute of Computing Technology, Chinese Academy of Sciences (CVE-2026-46448)

Maxence Bornecque from Orange Cyberdefense CERT Vulnerability Intelligence Watch Team reported a vulnerability in Keystone's EC2 credential creation endpoint. By using a restricted application credential to call the EC2 credential creation API, an authenticated user with only a reader role may obtain an EC2/S3 credential that carries the full set of the parent user's S3 permissions, effectively bypassing the role restrictions imposed on the application credential. Only deployments that use restricted application credentials in combination with the EC2/S3 compatibility API (swift3 / s3api) are affected.

An issue was discovered in OpenStack Keystone before 29.0.2. When combined with an application credential impersonation vulnerability, an attacker with the member role on a project can escalate to admin by chaining unrestricted application credentials with Keystone trusts. The impersonated token carries the victim's identity, which passes the trustor validation check. Keystone then validates the delegated roles against the victim's actual role assignments in the database, not the roles on the requesting token. This allows the attacker to create a trust delegating the victim's admin role to themselves. The trust persists independently, and additional trusts and application credentials can be created to maintain access. All actions are logged under the victim's identity.

An issue was discovered in OpenStack Cinder through 24.0.0, Glance before 28.0.2, and Nova before 29.0.3. Arbitrary file access can occur via custom QCOW2 external data. By supplying a crafted QCOW2 image that references a specific data file path, an authenticated user may convince systems to return a copy of that file's contents from the server, resulting in unauthorized access to potentially sensitive data. All Cinder and Nova deployments are affected; only Glance deployments with image conversion enabled are affected.

A vulnerability was found in python-glance-store. The issue occurs when the package logs the accesskey for the glance-store when the DEBUG log level is enabled.