- OpenStack-announce - lists.openstack.org

[OSSA-2026-004] Glance: Server-Side Request Forgery (SSRF) vulnerabilities in OpenStack Glance image import functionality (CVE-2026-pending)
by Brian Rosmaita 19 Mar '26

19 Mar '26

==================================================================== 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 ~~~~~~~~~~~ Hyeongeun_Ji 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) 'ovf_process' 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 validate_import_uri() 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 normalize_hostname() 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 validate_import_uri() 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 ~~~~~~~ - Hyeongeun_Ji 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.

1 0

[OSSA-2026-003] OpenStack Vitrage: Remote code execution through Vitrage query parser (CVE-2026-28370)
by Jeremy Stanley 04 Mar '26

04 Mar '26

================================================================= OSSA-2026-003: Remote code execution through Vitrage query parser ================================================================= :Date: March 03, 2026 :CVE: CVE-2026-28370 Affects ~~~~~~~ - Vitrage: <12.0.1, ==13.0.0, ==14.0.0, ==15.0.0 Description ~~~~~~~~~~~ Khalil Lemtaffah (Nokia) reported a vulnerability in the Vitrage query parser. A user allowed to access the Vitrage API may trigger code execution on the Vitrage service host as the user the Vitrage service runs under. This may result in unauthorized access to the host and further compromise of the Vitrage service. All deployments exposing the Vitrage API are affected. Patches ~~~~~~~ - https://review.opendev.org/962671 (2023.1/antelope) - https://review.opendev.org/962713 (2024.1/caracal) - https://review.opendev.org/962712 (2024.2/dalmatian) - https://review.opendev.org/962646 (2025.1/epoxy) - https://review.opendev.org/962658 (2025.2/flamingo) - https://review.opendev.org/962617 (2026.1/gazpacho) Credits ~~~~~~~ - Khalil Lemtaffah from Nokia (CVE-2026-28370) References ~~~~~~~~~~ - https://storyboard.openstack.org/#!/story/2011539 - http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2026-28370 Notes ~~~~~ - The stable/2023.1 branch is unmaintained and will receive no new point releases, but a patch for it is provided as a courtesy. -- Jeremy Stanley OpenStack Vulnerability Management Team https://security.openstack.org/vmt.html

1 0

[all][elections][tc] 2026.2 Hibiscus Technical Committee Election Results
by Ian Y. Choi 26 Feb '26

26 Feb '26

Please join me in congratulating the 5 newly elected members of the Technical Committe (TC). - Amy Marrich (spotz) - Dan Smith (dansmith) - Goutham Pacha Ravi (gouthamr) - Michal Nasiadka (mnasiadka) - Dmitriy Rabotyagov (noonedeadpunk) Election process details and results are also available here: https://governance.openstack.org/election/ Thank you to all of the candidates, having a good group of candidates helps engage the community in our democratic process. Thank you to all who voted and who encouraged others to vote. We need to ensure your voice is heard. Thank you for another great round.

1 0

[OSSA-2026-002] OpenStack Nova: calls qemu-img without format restrictions for resize (CVE-2026-24708)
by Jeremy Stanley 18 Feb '26

18 Feb '26

========================================================================= OSSA-2026-002: Nova calls qemu-img without format restrictions for resize ========================================================================= :Date: January 17, 2026 :CVE: CVE-2026-24709 Affects ~~~~~~~ - Nova: <30.2.2, >=31.0.0 <31.2.1, >=32.0.0 <32.1.1 Description ~~~~~~~~~~~ Dan Smith from Red Hat reported a vulnerability in nova. 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. 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-24709 -- Jeremy Stanley OpenStack Vulnerability Management Team https://security.openstack.org/vmt.html

1 1

[CVE-2026-22797] OpenStack keystonemiddleware: Privilege Escalation via Identity Headers in External OAuth2 Tokens (CVE-2026-22797)
by Jeremy Stanley 17 Jan '26

17 Jan '26

==================================================================== OSSA-2026-001: Privilege Escalation via Identity Headers in External OAuth2 Tokens ==================================================================== :Date: January 15, 2026 :CVE: CVE-2026-22797 Affects ~~~~~~~ - Keystonemiddleware: >=10.0.0 <10.7.2, >=10.8.0 <10.9.1, >=10.10.0 <10.12.1 Description ~~~~~~~~~~~ Grzegorz Grasza with Red Hat reported a vulnerability in the external_oauth2_token middleware for keystonemiddleware. This middleware fails to sanitize incoming authentication headers before processing OAuth 2.0 tokens. By sending forged identity headers such as X-Is-Admin-Project, X-Roles, or X-User-Id, an authenticated attacker may escalate privileges or impersonate other users. All deployments using the external_oauth2_token middleware are affected. Patches ~~~~~~~ - https://review.opendev.org/973499 (2024.1/caracal) - https://review.opendev.org/973497 (2024.2/dalmatian) - https://review.opendev.org/973496 (2025.1/epoxy) - https://review.opendev.org/973495 (2025.2/flamingo) - https://review.opendev.org/973494 (2026.1/gazpacho) Credits ~~~~~~~ - Grzegorz Grasza from Red Hat (CVE-2026-22797) References ~~~~~~~~~~ - https://launchpad.net/bugs/2129018 - http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2026-22797 Notes ~~~~~ - The unmaintained/2024.1 branches will receive no new point releases, but patches for them are provided as a courtesy. - This bug was possible because the middleware only conditionally set certain headers (e.g., X-Is-Admin-Project was only set when the token had admin privileges), leaving spoofed values intact when conditions were not met. - The fix adds a call to remove_auth_headers() at the start of request processing to sanitize all incoming identity headers, matching the behavior of the main auth_token middleware. - The external_oauth2_token middleware was introduced in keystonemiddleware 10.0.0. -- Jeremy Stanley OpenStack Vulnerability Management Team https://security.openstack.org/vmt.html

1 1

[OSSA-2025-002] OpenStack Keystone: Unauthenticated access to EC2/S3 token endpoints can grant Keystone authorization (CVE PENDING)
by Jeremy Stanley 18 Nov '25

18 Nov '25

========================================================================= OSSA-2025-002: Unauthenticated access to EC2/S3 token endpoints can grant Keystone authorization ========================================================================= :Date: November 04, 2025 :CVE: PENDING Affects ~~~~~~~ - Keystone: <26.0.1, ==27.0.0, ==28.0.0 Description ~~~~~~~~~~~ kay reported a vulnerability in Keystone’s ec2tokens and s3tokens APIs. By sending those endpoints a valid AWS Signature (e.g., from a presigned S3 URL), an unauthenticated attacker may obtain Keystone authorization (ec2tokens can yield a fully scoped token; s3tokens can reveal scope accepted by some services), resulting in unauthorized access and privilege escalation. Deployments where /v3/ec2tokens or /v3/s3tokens are reachable by unauthenticated clients (e.g., exposed on a public API) are affected. Patches ~~~~~~~ - https://review.opendev.org/966073 (2024.2/dalmatian(keystone)) - https://review.opendev.org/966067 (2024.2/dalmatian(swift)) - https://review.opendev.org/966071 (2025.1/epoxy(keystone)) - https://review.opendev.org/966064 (2025.1/epoxy(swift)) - https://review.opendev.org/966070 (2025.2/flamingo(keystone)) - https://review.opendev.org/966063 (2025.2/flamingo(swift)) - https://review.opendev.org/966069 (2026.1/gazpacho(keystone)) - https://review.opendev.org/966062 (2026.1/gazpacho(swift)) Credits ~~~~~~~ - kay (CVE PENDING) References ~~~~~~~~~~ - https://launchpad.net/bugs/2119646 Notes ~~~~~ - While the indicated Keystone patches are sufficient to mitigate this vulnerability, corresponding changes for Swift are included which keep its optional S3-like API working. - MITRE CVE Request 1930434 has been awaiting assignment since 2025-09-24, but once completed will result in an errata revision to this advisory reflecting the correct CVE ID. If any other CNA has assigned a CVE themselves in the meantime, please reject it so that we don't end up with duplicates. -- Jeremy Stanley OpenStack Vulnerability Management Team https://security.openstack.org/vmt.html

1 1

OpenStack 2025.2 "Flamingo" is officially released!
by Elõd Illés 01 Oct '25

01 Oct '25

Hello OpenStack community, I'm excited to announce the final releases for the components of OpenStack 2025.2 "Flamingo", which conclude the Flamingo development cycle. You will find a complete list of all components, their latest versions, and links to individual project release notes documents listed on the new release site. https://releases.openstack.org/flamingo/ Congratulations to all of the teams who have contributed to this release! Our next production cycle, 2026.1 "Gazpacho", has already started. We will meet in Paris-Saclay, France, 17–19 October 2025 at the OpenInfra Summit Europe and virtually at October 27-31, 2025 at the Project Team Gathering to plan the work for the upcoming cycle. I hope to see you there! Thanks, Előd Illés on behalf of the Release Management team

1 0

[all][elections][ptl] 2026.1 Gazpacho: PTL Election Conclusion & Results
by Sławek Kapłoński 18 Sep '25

18 Sep '25

Hi, Thank you to the electorate, to all those who voted and to all candidates who put their name forward for Project Team Lead (PTL) in this election. A healthy, open process breeds trust in our decision making capability. Thank you to all those who make this process possible. Now for the results of the PTL election process, please join me in extending congratulations to the following PTLs: * Adjutant - Dale Smith (dalees) * Barbican - Mauricio Harley (mharley) * Blazar - Pierre Riteau (priteau) * Cinder - Jon Bernard (jbernard) * Cloudkitty - Rafael Weingartner () * Cyborg - Li Liu () * Designate - Omer Schwartz () * Glance - Cyril Roelandt () * Heat - Takashi Kajinami (tkajinam) * Horizon - Tatiana Ovchinnikova (tmazur) * Keystone - Artem Goncharov (gtema) * Kolla - Michal Nasiadka (mnasiadka) * Magnum - Dale Smith (dalees) * Manila - Carlos Silva (carloss) * Masakari - sam sue () * Mistral - Arnau Morin (amorin) * Neutron - Brian Haley (haleyb) * Nova - Rene Ribaud (Uggla) * Octavia - Michael Johnson (johnsom) * OpenStack Helm - Vladimir Kozhukalov (kozhukalov) * OpenStackAnsible - Dmitriy Rabotyagov (noonedeadpunk) * OpenStackSDK - Artem Goncharov (gtema) * Puppet OpenStack - Takashi Kajinami (tkajinam) * Quality Assurance - Ghanshyam Maan (gmaan) * Rally - Andrey Kurilin (andreykurilin) * Skyline - Wenxiang Wu (wu_wenxiang) * Storlets - Takashi Kajinami (tkajinam) * Sunbeam - Guillaume Boutry (gboutry) * Swift - Tim Burke (timburke) * Tacker - Yasufumi Ogawa (yasufum) * Telemetry - Matthias Runge (mrunge) * Trove - wu chunyang (wuchunyang) * Zaqar - Hao Wang (wanghao) * Zun - Hongbin Lu () Elections: * Horizon: https://civs1.civs.us/cgi-bin/results.pl?id=E_2cbcfa05fd0ec211 For remaining projects (without PTL candidates), TC will work on the appointment. Election process details and results are also available here: https://governance.openstack.org/election/ Thank you to all involved in the PTL election process, Slawek Kaplonski, on behalf of the OpenStack Technical Election Officials

1 0

[all][elections][tc] 2026.1 Gazpacho Technical Committee Election Results
by Sławek Kapłoński 18 Sep '25

18 Sep '25

Hi, Please join me in congratulating the 4 newly elected members of the Technical Committe (TC). Sylvain Bauza (bauzas) Dr. Jens Harbott (frickler) Tony Breeds (tonyb) Doug Goldstein (cardoe) Full results: https://civs1.civs.us/cgi-bin/results.pl?id=E_6cede1084d4586eb Election process details and results are also available here: https://governance.openstack.org/election/ Thank you to all of the candidates, having a good group of candidates helps engage the community in our democratic process. Thank you to all who voted and who encouraged others to vote. We need to ensure your voice is heard. Thank you for another great round. Slawek Kaplonski, on behalf of the OpenStack Technical Election Officials

1 0

OSSN-0094: Ensuring Volume Safety with Nova and Watcher
by Jay Faulkner 21 Aug '25

21 Aug '25

OSSN-0094: Ensuring Volume Safety with Nova and Watcher == Summary == A vulnerability has been identified in OpenStack Nova and OpenStack Watcher in conjunction with volume swap operations performed by the Watcher service. Under specific circumstances, this can lead to a situation where two Nova libvirt instances could reference the same block device, allowing accidental information disclosure to the unauthorized instance. == Affected Services / Software == Services: Nova,Watcher Releases: all supported releases == Discussion == The issue occurs when Watcher's zone migration strategy performs the following sequence of events: 1. Watcher initiates a volume swap using Nova's internal-only volume swap API 2. Watcher initiates a live migration of the same instance 3. In some error cases connection details may have failed to update storage references. These invalid details are used during the live migration. === Required Access === The swap volume, live migration and all Watcher APIs are admin only so with default policy is only possible to create the inconsistent state described in this OSSN if you have admin rights on the relevant OpenStack project. === Further Watcher Hardening === The Watcher service, when first created, often implemented its own means to perform operations. Many of those operations can now be done natively via other OpenStack services. In the specific context of OSSN-0094, the ability to migrate Cinder volumes between storage backends is such an example. Additionally, the Cinder volume migration in Watcher created a new Keystone user with the admin role assigned for the instance owners' project and then used that user to perform API requests on behalf of the project. This code has been removed. Finally, due to limited error handling and no validation that the objects involved were migrated properly, some error scenarios could have led to a source volume being deleted despite not having been migrated properly. === Resolution === Nova will now reject any request to swap a volume that has an empty migration status, effectively restricting the usage of this API to Cinder. This brings the API validation in line with the documentation. Watchers internal implementation of swap volume has been deleted and updated to use Cinder's native volume migration as a replacement. Watcher no longer creates temporary Keystone users in normal operation. === Patches === Patches for Nova and Watcher have been backported to all supported stable branches and committed to master branch. stable/2025.1: * Watcher: https://review.opendev.org/c/openstack/watcher/+/957770 * Nova: https://review.opendev.org/c/openstack/nova/+/957759 stable/2024.2: * Watcher: https://review.opendev.org/c/openstack/watcher/+/957773 * Nova: https://review.opendev.org/c/openstack/nova/+/957762 stable/2024.1: * Watcher: https://review.opendev.org/c/openstack/watcher/+/957774 * Nova: https://review.opendev.org/c/openstack/nova/+/957764 == Recommended Actions == * Operators using Watcher's zone migration strategy should apply the provided Watcher and Nova patches as soon as possible. * Operators should refrain from using the swap volume migration action in Watcher. The compatibility code for swap volume that uses a Cinder-based migration may be removed in a future API version. * Operators should audit all users with the admin role and ensure no temporary Watcher-created users remain. * Operators using custom policy for volume attachment (''/servers/{server_id}/os-volume_attachments/{volume_id}'') or live migration API should review the state of existing instances which have had volume migrations. Any instance in an inconsistent state can be resolved by hard rebooting the instance using Nova's API. == Contacts / References == * Author: Sean Mooney <smooney(a)redhat.com>, Jay Faulkner <jay(a)jvf.cc> * This OSSN : https://wiki.openstack.org/wiki/OSSN/OSSN-0094 * Original LaunchPad Bug : https://bugs.launchpad.net/nova/+bug/2112187 * Mailing List : [Security] tag on openstack-discuss(a)lists.openstack.org * OpenStack Security Project : https://launchpad.net/~openstack-ossg * CVE: None

1 0