======================================================================================= =======================================================================================
:Date: September 03, 2026 :CVE: CVE-2026-71196, CVE-2026-71197, CVE-2026-71198
Affects ~~~~~~~ - Glance: >=16.0.0 <30.2.1, >=31.0.0 <31.1.1, >=32.0.0 <32.0.1
Description ~~~~~~~~~~~ Sergey Kanibor (Luntry), Sami Yessou (switch.ch), and Abhishek Kekane (Red Hat) reported three related SSRF vulnerabilities in OpenStack Glance.
The web-download import method ships with insecure default filtering that permits authenticated users to fetch arbitrary internal URLs, including cloud metadata endpoints. The URI validator does not perform DNS resolution before applying host filters, enabling bypass via attacker-controlled domains and DNS rebinding attacks. The HTTP image location API lacks host filtering entirely when the HTTP store is enabled, and fetched content is stored as image data accessible for download, converting blind SSRF into full-read exfiltration.
All Glance deployments using the web-download import method or HTTP image location APIs are affected.
Patches ~~~~~~~ - https://review.opendev.org/1003822 (2025.1/epoxy) - https://review.opendev.org/1003823 (2025.1/epoxy) - https://review.opendev.org/1003824 (2025.1/epoxy) - https://review.opendev.org/1003825 (2025.1/epoxy) - https://review.opendev.org/1003816 (2025.2/flamingo) - https://review.opendev.org/1003817 (2025.2/flamingo) - https://review.opendev.org/1003818 (2025.2/flamingo) - https://review.opendev.org/1003819 (2025.2/flamingo) - https://review.opendev.org/1003812 (2026.1/gazpacho) - https://review.opendev.org/1003813 (2026.1/gazpacho) - https://review.opendev.org/1003814 (2026.1/gazpacho) - https://review.opendev.org/1003815 (2026.1/gazpacho) - https://review.opendev.org/1003805 (2026.2/hibiscus (development)) - https://review.opendev.org/1003806 (2026.2/hibiscus (development)) - https://review.opendev.org/1003807 (2026.2/hibiscus (development)) - https://review.opendev.org/1003808 (2026.2/hibiscus (development))
Credits ~~~~~~~ - Sergey Kanibor from Luntry (CVE-2026-71196, CVE-2026-71197) - Sami Yessou from switch.ch (CVE-2026-71196) - Abhishek Kekane from Red Hat (CVE-2026-71198)
References ~~~~~~~~~~ - https://launchpad.net/bugs/2158998 - https://launchpad.net/bugs/2158999 - https://launchpad.net/bugs/2161330 - https://launchpad.net/bugs/2160020 - http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2026-71196 - http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2026-71197 - http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2026-71198
Notes ~~~~~ - All four commits in each patch set are interdependent and must be applied together, in the order listed above, as each builds on the previous. The DoS issue (LP#2160020) is addressed as part of this coordinated fix. - A related Tempest test compatibility fix was proposed at https://review.opendev.org/1003560
-- Goutham Pacha Ravi OpenStack Vulnerability Management Team https://security.openstack.org/vmt.html
In OpenStack Glance through 32.0.0, the /v2/tasks API accepts type=import tasks that bypass importfilteringopts, 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.
Glance through 0.8.5 contains an IP address spoofing vulnerability in the authentication handler that allows unauthenticated attackers to bypass brute-force lockout protections by supplying arbitrary values in the X-Forwarded-For request header when the server proxied option is enabled. Attackers can manipulate the leftmost value of the X-Forwarded-For header to make each login attempt appear to originate from a distinct IP address, preventing the per-IP failed-login counter from reaching the lockout threshold and enabling unlimited credential guessing against the authentication endpoint.
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
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) ovfprocess image import plugin.
Server-Side Request Forgery (SSRF) vulnerability in the web-download import workflow of OpenStack Glance. The issue arises because validateimporturi() validates only the initial URI using string-based hostname comparison, and urllib.request.urlopen() automatically follows HTTP redirects without revalidating the redirect destination. Additionally, alternative IP encodings (decimal, hexadecimal, octal representations) are not normalized prior to blacklist checks, allowing encoded internal IP addresses (e.g., 0x7f000001 for 127.0.0.1) to bypass validation. An authenticated user can supply a crafted URI that either redirects to an internal resource or directly references an encoded internal IP address, resulting in unauthorized internal network access and potential sensitive data exfiltration.
An SSRF issue was discovered in OpenStack Glance before Newton. The 'copyfrom' 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.
==================================================================== OSSA-2026-004: Server-Side Request Forgery (SSRF) vulnerabilities in OpenStack Glance image import functionality ====================================================================
:Date: March 19, 2026 :CVE: CVE-2026-pending
Affects ~~~~~~~ - Glance: <29.1.1, >=30.0.0 <30.1.1, ==31.0.0
Description ~~~~~~~~~~~ HyeongeunJi of Open the Window and Abhishek Kekane of Red Hat reported multiple Server-Side Request Forgery (SSRF) vulnerabilities in Glance image import. 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) 'ovfprocess' image import plugin. We discuss each of the vulnerabilities in turn below.
web-download Import Method SSRF ------------------------------- The web-download import method has two SSRF vulnerabilities:
HTTP Redirect Bypass ++++++++++++++++++++ The web-download import method did not validate redirect destinations when following HTTP redirects. An attacker could provide an initial URL that passed validation but redirected to an internal or disallowed resource; the redirected URL was not subject to security checks.
This is fixed by implementing a SafeRedirectHandler that validates redirect destinations before following them, using same validateimporturi() checks as the initial URL.
IP Address Encoding Bypass ++++++++++++++++++++++++++ The web-download import method URL validation could be bypassed by encoding IP addresses in alternative formats (decimal integer, hexadecimal, octal). For example, 127.0.0.1 could be encoded as 2130706433 (decimal) or 0x7f000001 (hexadecimal) to bypass blacklist checks.
This is fixed by implementing a normalizehostname() function that uses the Python standard library ipaddress module to validate IP addresses. The ipaddress module only accepts standard dotted-decimal notation for IPv4 and standard format for IPv6, automatically rejecting all encoded formats (decimal, hexadecimal, octal). Any attempt to use encoded IP formats is rejected, thereby preventing SSRF bypass attacks.
glance-download Import Method SSRF ---------------------------------- The glance-download import method had redirect validation bypass vulnerabilities in two steps of the import flow:
Image Data Download +++++++++++++++++++ When downloading image data from a remote Glance endpoint, redirects were not validated, allowing attackers to redirect to internal services.
Metadata Fetch ++++++++++++++ When fetching image metadata from a remote Glance endpoint, redirects were not validated, allowing attackers to redirect to internal services.
Both steps are fixed by using the SafeRedirectHandler described earlier to validate redirect destinations before following them.
OVF Processing SSRF ------------------- The OVF processing functionality had critical SSRF vulnerability with zero protection - no URI validation, no redirect validation, and no IP normalization. The code directly called urllib.request.urlopen(uri) without any validation checks. This is fixed by adding URI validation using validateimporturi() and redirect validation using SafeRedirectHandler.
Patches ~~~~~~~ - https://review.opendev.org/981300 (2023.1/antelope) - https://review.opendev.org/981299 (2024.2/dalmatian) - https://review.opendev.org/981298 (2025.1/epoxy) - https://review.opendev.org/981297 (2025.2/flamingo) - https://review.opendev.org/981296 (2026.1/gazpacho) - https://review.opendev.org/981295 (2026.2/hibiscus)
Credits ~~~~~~~ - HyeongeunJi from Open the Window (CVE-2026-pending) - Abhishek Kekane from Red Hat (CVE-2026-pending)
References ~~~~~~~~~~ - https://launchpad.net/bugs/2138602 - https://launchpad.net/bugs/2138672 - https://launchpad.net/bugs/2138675 - http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2026-pending
Notes ~~~~~ - A CVE request was filed with MITRE on 2026-02-16. - Prereleases of OpenStack software are not official production releases and so not covered by the affected versions list. The first Glance release candidate for gazpacho (32.0.0.0rc1) is vulnerable; 32.0.0.0rc2 will contain the fix. - The unmaintained/2023.1 branch, being unmaintained, will receive no new point releases, but a patch for it is provided as a courtesy.
store/swift.py in OpenStack Glance Essex (2012.1), Folsom (2012.2) before 2012.2.3, and Grizzly, when in Swift single tenant mode, logs the Swift endpoint's user name and password in cleartext when the endpoint is misconfigured or unusable, allows remote authenticated users to obtain sensitive information by reading the error messages.
The v1 API in OpenStack Glance Grizzly, Folsom (2012.2), and Essex (2012.1) allows remote authenticated users to delete arbitrary non-protected images via an image deletion request, a different vulnerability than CVE-2012-5482.
The v2 API in OpenStack Glance Grizzly, Folsom (2012.2), and Essex (2012.1) allows remote authenticated users to delete arbitrary non-protected images via an image deletion request. NOTE: this vulnerability exists because of an incomplete fix for CVE-2012-4573.
The API before 2.1 in OpenStack Image Registry and Delivery Service (Glance) makes it easier for local users to inject images into arbitrary tenants by adding the tenant as a member of the image.
OpenStack Image Registry and Delivery Service (Glance) before 2013.2.4, 2014.x before 2014.1.3, and Juno before Juno-3, when using the V2 API, does not properly enforce the imagesizecap configuration option, which allows remote authenticated users to cause a denial of service (disk consumption) by uploading a large image.
OpenStack Image Service (Glance) before 2014.2.4 (juno) and 2015.1.x before 2015.1.2 (kilo) allows remote authenticated users to bypass the storage quota and cause a denial of service (disk consumption) by deleting images that are being uploaded using a token that expires during the process. NOTE: this vulnerability exists because of an incomplete fix for CVE-2014-9623.
OpenStack Image Service (Glance) before 2014.2.4 (juno) and 2015.1.x before 2015.1.2 (kilo) allow remote authenticated users to change the status of their images and bypass access restrictions via the HTTP x-image-meta-status header to images/.
The V2 API in OpenStack Image Registry and Delivery Service (Glance) before 2014.1.4 and 2014.2.x before 2014.2.2 allows remote authenticated users to read or delete arbitrary files via a full pathname in a filesystem:// URL in the image location property. NOTE: this vulnerability exists because of an incomplete fix for CVE-2014-9493.
The glance-manage db in all versions of HPE Helion Openstack Glance allows deleted image ids to be reassigned, which allows remote authenticated users to cause other users to boot into a modified image without notification of the change.
OpenStack Image Service (Glance) before 2015.1.3 (kilo) and 11.0.x before 11.0.2 (liberty), when showmultiplelocations is enabled, allow remote authenticated users to change image status and upload new image data by removing the last location of an image.