OSSN-0108: Multiple authentication vulnerabilities in Ceph ---
Summary ###
The latest Ceph releases of Ceph 20.2.4 and Ceph 19.2.6 patch four CVEs across several components (CVE-2025-30156, CVE-2026-39944, CVE-2026-50152 Ceph servers should be upgraded and their CephX keyrings should be rotated. to be restarted or live migrated in order to load the new keyring.
Affected Services / Software ###
- Ceph: all versions prior to v20.2.4 or v19.2.6 - OpenStack services with CephX keyrings: Nova, Cinder, Glance, Manila - Ceph RADOS Gateway (RGW), when used as an Object Store (Swift/S3) backend
Discussion ###
Any OpenStack service with a CephX keyring (Nova, Cinder, Glance, Manila) is at risk. Data-at-rest encryption is not affected by CVE-2025-30156 but is affected by CVE-2026-50152. Both are fixed by the update in addition to CVE-2026-39944 and CVE-2026-54330.
For an OpenStack cloud using RBD, RGW or NFS, this can be considered an internal vulnerability, potentially enabling an insider to escalate privilege. For example, a Nova guest using Cinder RBD does not have access to the CephX key or Ceph's storage network; the Nova host has access to them but only an insider should have access to the Nova host. However, if an OpenStack tenant is using Manila with native CephFS (not with NFS-Ganesha), then those tenants could exploit these CVEs.
The hardcoded initialization vector means identical plaintexts produce identical ciphertexts. The missing HMAC allows CBC bit-flipping. An attacker who compromises any CephX entity (or obtains its shared secret from network traffic) can tamper with a ticket's permissions without detection and forge credentials for privileged services.
The fix modifies Ceph to use AES256-CTS-HMAC-SHA384-192 (RFC 8009), a new CephX key type named aes256k. Both Ceph server and client packages must be upgraded to use it. If krbd (in place of librbd) or CephFS kernel mounts (in place of ceph-fuse or NFS-Ganesha) are used, the client also requires Linux kernel 7.0 or later. Upgrading the servers and rotating their keys to aes256k resolves the vulnerabilities; clients that have not yet been upgraded continue to authenticate with their existing aes keys in the meantime.
Recommended Actions ###
- Upgrade Ceph to a patched release and update Ceph clients on OpenStack. - Re-create every CephX credential with the new aes256k cipher. - Every OpenStack Nova guest must be live migrated (or restarted) to pick up the new CephX key.
OpenStack Service Keyrings (Nova, Cinder, Glance) ####
To use RBD with Nova, Cinder or Glance, these services should be configured with a Ceph user that uses a CephX key to authenticate to the Ceph cluster. This OSSN will refer to a single client.openstack key for simplicity but configurations with multiple keys are possible. Before rotating or replacing this key:
- The Ceph cluster should be using the new cipher for its internals. For example, the Ceph Monitor, OSD, RGW, MDS and other services should already have rotated their CephX keys so they use the new cipher.
- The Ceph cluster should allow connections from both the old and new cipher as confirmed by the following command.
~~~ ceph mon dump | grep allowedciphers authallowedciphers aes, aes256k ~~~
There are two strategies:
1. Rotate: Use ceph auth rotate to rotate client.openstack. 2. Replace: Create a new CephX key (e.g. client.openstack2), which uses the new cipher, and switch clients to use the new key.
If you are concerned about the time required to migrate Nova guests (so they start using the new key), then use the replacement strategy.
There is no immediate downtime when the credential is rotated but there is limited time to switch to the new credential. The client will continue to function until it tries to reauthenticate with the Ceph Monitors to get new tickets. During that time you can rotate and then restart clients incrementally. Knowing exactly how long you have to rotate the key for all clients can be difficult to predict given the distributed nature of Ceph but we believe it to be a matter of hours, not days.
Rather than be bound by the above, you can have complete control of when the old credential is no longer valid by having two valid credentials and rotating them on your own schedule and then disabling support for the old credential's cipher.
The new CephX key must be distributed to every OpenStack node which connects to Ceph and be imported into libvirt prior migrating Nova guests to have them pick up the new key.
Manila with Native CephFS ####
With Manila, users create CephX keys for native CephFS share access. These keys are exposed to tenant VMs. To rotate, for each share:
1. Grant new share access (new CephX key with aes256k) 2. Remount the share using the new credentials 3. Revoke the old share access
All shares for a tenant must be covered. Partial rotation leaves the old CephX user and key valid for any shares not yet rotated.
Manila with NFS-Ganesha ####
The main NFS-Ganesha CephX key can be rotated and the service redeployed. Per-export CephX keys (created automatically per share) do not have a rotation mechanism yet. To rotate these, delete and recreate access rules for each share. This requires unmount/remount and is disruptive.
These per-export keys are internal to the Ceph cluster and not exposed to tenants. Operators can defer their rotation until Ceph provides a rotation mechanism if the risk is tolerable.
Enforcing the New Cipher ####
After all CephX keys have been rotated, enforce the new cipher: ~~~ ceph mon set authallowedciphers aes256k ~~~
Credits ###
- Erin Shepherd, e43.eu - David Mohren, Clyso - Mark Nelson, Clyso
Contacts / References ###
Authors: - John Fulton, Red Hat - Goutham Pacha Ravi, Red Hat - Sage McTaggart, IBM
This OSSN: https://wiki.openstack.org/wiki/OSSN/OSSN-0108 Original LaunchPad Bug: None Mailing List : [security-sig] tag on openstack-discuss () lists openstack org OpenStack Security : https://security.openstack.org/ CVE: CVE-2025-30156, CVE-2026-39944, CVE-2026-50152, CVE-2026-54330
========================================================================================================== ==========================================================================================================
:Date: June 16, 2026 :CVE: CVE-2026-46448
Affects ~~~~~~~ - Nova: >=18.0.0 <31.3.1, >=32.0.0 <32.2.1, >=33.0.0 <33.0.2
Description ~~~~~~~~~~~ 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 ~~~~~~~ References ~~~~~~~~~~ - https://launchpad.net/bugs/2151252 - http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2026-46448
-- Goutham Pacha Ravi OpenStack Vulnerability Management Team https://security.openstack.org/vmt.html
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)
========================================================================= OSSA-2026-002: Nova calls qemu-img without format restrictions for resize =========================================================================
:Date: January 17, 2026 :CVE: CVE-2026-24708
Affects ~~~~~~~ - Nova: <30.2.2, >=31.0.0 <31.2.1, >=32.0.0 <32.1.1
Description ~~~~~~~~~~~ Errata ~~~~~~ Patches ~~~~~~~ - https://review.opendev.org/977104 (2024.2/dalmatian) - https://review.opendev.org/977103 (2025.1/epoxy) - https://review.opendev.org/977101 (2025.2/flamingo) - https://review.opendev.org/977100 (2026.1/gazpacho)
Credits ~~~~~~~ - Dan Smith from Red Hat (CVE-2026-24708)
References ~~~~~~~~~~ - https://launchpad.net/bugs/2137507 - http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2026-24708
OSSA History ~~~~~~~~~~~~ - 2026-02-17 - Errata 1 - 2026-02-17 - Original Version
-- Jeremy Stanley OpenStack Vulnerability Management Team https://security.openstack.org/vmt.html
On 2026-02-17 17:10:27 +0100 (+0100), Salvatore Bonaccorso wrote: [...] Just a small heads-up: The title mentions CVE-2026-24708, but the mail body once CVE-2026-24708 and refers to CVE-2026-24709. My understandign is that CVE-2026-24708 should be the correct one as this was the CVE originally mentioned.
Jeremy, can you confirm: CVE-2026-24708 is the one to use?
-- Jeremy Stanley OpenStack Vulnerability Management Team https://security.openstack.org/vmt.html
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.
OpenStack nova base images permissions are world readable
A vulnerability was found in Nova Compute resource fault handling. If an API request from an authenticateduser ends in a fault condition due to an external exception, details of the underlying environment may be leaked in the response and could include sensitive configuration or other data.
An issue was discovered in the default FilterScheduler in OpenStack Nova 16.0.3. By repeatedly rebuilding an instance with new images, an authenticated user may consume untracked resources on a hypervisor host leading to a denial of service, aka doubled resource allocations. This regression was introduced with the fix for OSSA-2017-005 (CVE-2017-16239); however, only Nova stable/pike or later deployments with that fix applied and relying on the default FilterScheduler are affected.
By rebuilding an instance, an authenticated user may be able to circumvent the Filter Scheduler bypassing imposed filters (for example, the ImagePropertiesFilter or the IsolatedHostsFilter). All setups using Nova Filter Scheduler are affected.
Affected versions: <=14.0.9, >=15.0.0 <=15.0.7, >=16.0.0 <=16.0.2
Bug report:
https://launchpad.net/bugs/1664931
By rebuilding an instance, an authenticated user may be able to circumvent the Filter Scheduler bypassing imposed filters (for example, the ImagePropertiesFilter or the IsolatedHostsFilter). All setups using Nova Filter Scheduler are affected.
Affected versions: <=14.0.9, >=15.0.0 <=15.0.7, >=16.0.0 <=16.0.2
Bug report:
https://launchpad.net/bugs/1664931
An issue was discovered in exceptionwrapper.py in OpenStack Nova 13.x through 13.1.3, 14.x through 14.0.4, and 15.x through 15.0.1. Legacy notification exception contexts appearing in ERROR level logs may include sensitive information such as account passwords and authorization tokens.
The libvirt driver in OpenStack Compute (Nova) before 2013.2.2 and icehouse before icehouse-2 allows remote authenticated users to cause a denial of service (disk consumption) by creating and deleting instances with unique ostype settings, which triggers the creation of a new ephemeral disk backing file.
OpenStack Compute (Nova) Grizzly 2013.1.4, Havana 2013.2.1, and earlier uses world-writable and world-readable permissions for the temporary directory used to store live snapshots, which allows local users to read and modify live snapshots.
OpenStack Compute (Nova) Essex before 2011.3 allows remote authenticated users to cause a denial of service (Nova-API log file and disk consumption) via a long server name.
virt/disk/api.py in OpenStack Compute (Nova) 2012.1.x before 2012.1.2 and Folsom before Folsom-3 allows remote authenticated users to overwrite arbitrary files via a symlink attack on a file in an image that uses a symlink that is only readable by root. NOTE: this vulnerability exists because of an incomplete fix for CVE-2012-3361.
Nova 2011.3 and Essex, when using the OpenStack API, allows remote authenticated users to bypass access restrictions for tenants of other users via an OSAPI request with a modified projectid URI parameter.
From:
https://bugs.launchpad.net/nova/+bug/868360
If the secret key doesn't match for the ec2 request, the exception passed back to the user, showing the correct password.
To replicate: # export EC2ACCESSKEY='oomNAG3AGwnlKDAM9gFe' # export EC2SECRETKEY='anything' # euca-describe-instances [...] InvalidSignature: Invalid signature w6q++6lcvoEcBkcQuT1yNDURSpM8tq3a+WbhYeKWuX4= for user User('nova', 'nova', 'oomNAG3AGwnlKDAM9gFe', 'eXTMGYDx7FhSI7ng3YfE', True).
i.e. the correct password is leaked back to the user if the incorrect password is given
CVE 2011-4076 is reserved for the issue