June 2026 - OpenStack-announce - lists.openstack.org

[OSSA-2026-007] OpenStack Keystone: LDAP identity backend does not convert enabled attribute to boolean (CVE PENDING)
by Goutham Pacha Ravi 05 Aug '26

05 Aug '26

================================================================================== OSSA-2026-007: LDAP identity backend does not convert enabled attribute to boolean ================================================================================== :Date: April 14, 2026 :CVE: CVE-2026-pending Affects ~~~~~~~ - Keystone: >=8.0.0 <25.0.1, >=26.0.0 <26.1.1, >=27.0.0 <27.0.1, >=28.0.0 <28.0.1 Description ~~~~~~~~~~~ Benedikt Trefzer and Andrew Bogott independently reported a vulnerability in the Keystone LDAP identity backend. When the user_enabled_invert configuration option was False (the default), Keystone did not correctly interpret the LDAP enabled attribute, causing users disabled in LDAP to be treated as enabled and allowed to authenticate. Deployments using the LDAP identity backend without user_enabled_invert=True or user_enabled_emulation are affected. Patches ~~~~~~~ -https://review.opendev.org/982409 (2024.2/dalmatian) -https://review.opendev.org/982408 (2025.1/epoxy) -https://review.opendev.org/982407 (2025.2/flamingo) -https://review.opendev.org/958205 (2026.1/gazpacho) Credits ~~~~~~~ - Benedikt Trefzer from Cirrax GmbH (CVE-2026-pending) - Andrew Bogott from Wikimedia Foundation (CVE-2026-pending) - Grzegorz Grasza from Red Hat (CVE-2026-pending) References ~~~~~~~~~~ -https://launchpad.net/bugs/2121152 -https://launchpad.net/bugs/2141713 Notes ~~~~~ - To work around this vulnerability, set user_enabled_invert=True and use an LDAP attribute with inverted semantics such as nsAccountLock, or use user_enabled_emulation with group-based enabled status. - A CVE request was filed with MITRE on 2026-04-10. - The fix was merged on the master branch before the stable/2026.1 branch was cut, so no specific stable/2026.1 patch exists. The fix is included in the gazpacho (29.0.0) release. -- Goutham Pacha Ravi (gouthamr) OpenStack Vulnerability Management Team

1 1

[OSSA-2026-024] OpenStack Swift: Swift proxy-server SSRF via header injection (CVE-2026-50221)
by Goutham Pacha Ravi 23 Jun '26

23 Jun '26

OpenStack Security Advisory: OSSA-2026-024 CVE: CVE-2026-50221 Title: Swift proxy-server SSRF via header injection Affects: Swift >=2.0.0 <2.35.3, >=2.36.0 <2.36.2, >=2.37.0 <2.37.2 Description: Tim Shephard from roiai.ca reported a server-side request forgery (SSRF) vulnerability in Swift's proxy-server. An authenticated user can cause Swift object servers to issue outbound HTTP requests to attacker-specified hosts, potentially exposing internal infrastructure details. All deployments running Swift 2.0.0 or later are affected. Patches: 2026.2/hibiscus (development): https://review.opendev.org/994449 2026.1/gazpacho: https://review.opendev.org/994450 2025.2/flamingo: https://review.opendev.org/994451 2025.1/epoxy: https://review.opendev.org/994452 Credits: Tim Shephard from roiai.ca (CVE-2026-50221) References: https://security.openstack.org/ossa/OSSA-2026-024.html https://launchpad.net/bugs/2150261 http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2026-50221 Regards, Goutham Pacha Ravi OpenStack Vulnerability Management Team https://security.openstack.org/vmt.html

1 0

[OSSN-0097] Horizon RC file generation does not escape special characters in project names
by Goutham Pacha Ravi 19 Jun '26

19 Jun '26

OSSN-0097: Horizon RC file generation does not escape special characters in project names == Summary == Horizon generates shell scripts for OpenStack RC file downloads with user-provided values in double-quoted strings without escaping shell metacharacters. A domain manager can set a project name containing $() or backtick sequences that execute arbitrary commands when a user sources the RC file. == Affected Services / Software == - horizon: >=8.0.0 <25.3.3, >=25.4.0 <25.5.3, >=25.6.0 <25.7.4 == Discussion == A domain manager who can rename a project can inject commands that run in the shell of any user who downloads and sources the RC file for that project. == Recommended Actions == Upgrade to a version of horizon containing the fix. As a workaround, inspect downloaded RC files before sourcing them, or use clouds.yaml for CLI authentication instead. === Patches === The following reviews contain the fix for this issue: 2026.2/hibiscus (master): https://review.opendev.org/c/openstack/horizon/+/990661 2026.1/gazpacho: https://review.opendev.org/c/openstack/horizon/+/991038 2025.2/flamingo: https://review.opendev.org/c/openstack/horizon/+/991039 2025.1/epoxy: https://review.opendev.org/c/openstack/horizon/+/991040 == Credits == Tim Shephard, roiai.ca == Contacts / References == * Authors: Goutham Pacha Ravi, Red Hat * This OSSN: https://wiki.openstack.org/wiki/OSSN/OSSN-0097 * Original Launchpad bug: https://launchpad.net/bugs/2152240 * Mailing List : [security-sig] tag on openstack-discuss(a)lists.openstack.org * OpenStack Security : https://security.openstack.org/ * CVE: none

1 1

[OSSN-0100] Ironic: Command Injection in IPA (CVE-2026-43003)
by Jay Faulkner 16 Jun '26

16 Jun '26

Command Injection in IPA via chroot Execution of Tenant-Controlled binaries --- ### Summary ### Tuomo Tanskanen (Ericsson Software Technology) and Dmitry Tantsur (Red Hat) from the Metal3.io Security Team reported a vulnerability in Ironic Python Agent (IPA) when deploying a partition image that lacks boot artifacts. A malicious partition image can include crafted grub-install binary or other arbitrary binaries in the chroot path which IPA executes on the provisioning network host. This affects all partition images that require Ironic to manage the bootloader installation (BIOS-booted nodes without boot artifacts). The practical impact is limited; the attacker needs the ability to supply a partition image for bare-metal deployment and at the point of exploitation, IPA holds only an outdated agent_token and a heavily redacted node object. Whole disk images are not affected and partition images that include their own EFI boot artifacts at /boot and /efi are also not affected as Ironic copies them without executing grub-install. ### Affected Services / Software ### - ironic: <29.0.6, >=30.0.0 <32.0.2, >=33.0.0 <35.0.2, >=36.0.0 <37.0.0 - ironic-python-agent: <10.2.3, >=11.0.0 <11.2.1, >=11.3.0 <11.5.1 ### Discussion ### As it is not feasible to secure execution of a bootloader install binary due to technical limitations, the Ironic team has chosen to make this feature optional and disabled by default in the current development version. Backported versions of this change do not enable this restriction by default to avoid breaking existing installations. The vulnerable code path has existed for the entirety of the history of Ironic Python Agent, however, there are safeguards in place to prevent escalation of privileges from the provisioning network. Additionally, prior to Ironic 17.0.0, only cloud administrators could supply images for deployment, limiting the impact of this issue. ### Recommended Actions ### Apply the provided Ironic and Ironic-Python-Agent patches. Evaluate your use cases; flip ``CONF.agent.enable_bios_bootloader_install`` to ``False`` on Ironic conductors once confirming you are not using any partition images relying on a bootloader installation. #### Patches #### The following reviews contain the fix for this issue: ##### Ironic ##### 2026.2/hibiscus (development): https://review.opendev.org/c/openstack/ironic/+/990724 2026.1/gazpacho: https://review.opendev.org/c/openstack/ironic/+/991179 2025.2/flamingo: https://review.opendev.org/c/openstack/ironic/+/993685 2025.1/epoxy: https://review.opendev.org/c/openstack/ironic/+/993684 2024.1/caracal (unmaintained): https://review.opendev.org/c/openstack/ironic/+/993686 2023.1/antelope (unmaintained): https://review.opendev.org/c/openstack/ironic/+/993687 bugfix/33.0: https://review.opendev.org/c/openstack/ironic/+/993682 bugfix/34.0: https://review.opendev.org/c/openstack/ironic/+/993683 bugfix/37.0: Ironic 37.0.0 is not vulnerable. ##### Ironic Python Agent ##### 2026.2/hibiscus (development): https://review.opendev.org/c/openstack/ironic-python-agent/+/987391 2026.1/gazpacho: https://review.opendev.org/c/openstack/ironic-python-agent/+/993016 2025.2/flamingo: https://review.opendev.org/c/openstack/ironic-python-agent/+/993020 2025.1/epoxy: https://review.opendev.org/c/openstack/ironic-python-agent/+/993024 2024.1/caracal (unmaintained): https://review.opendev.org/c/openstack/ironic-python-agent/+/993025 2023.1/antelope (unmaintained): https://review.opendev.org/c/openstack/ironic-python-agent/+/993026 bugfix/11.3: https://review.opendev.org/c/openstack/ironic-python-agent/+/993464 bugfix/11.4: https://review.opendev.org/c/openstack/ironic-python-agent/+/993463 bugfix/11.6: IPA 11.6.0 is not vulnerable. ### Credits ### Dmitry Tantsur, Red Hat Tuomo Tanskanen, Ericsson Software Technology Metal3.io Security Team ### Contacts / References ### Authors: - Jay Faulkner, G-Research Open Source Software (GR-OSS) This OSSN: https://wiki.openstack.org/wiki/OSSN/OSSN-0100 Original Launchpad bug: https://bugs.launchpad.net/ironic-python-agent/+bug/2148310 Mailing List : [security-sig] tag on openstack-discuss(a)lists.openstack.org OpenStack Security : https://security.openstack.org/ CVE: CVE-2026-43003

1 0

[OSSA-2026-023] Ironic: Sensitive properties returned unredacted in POST and PATCH HTTP responses (CVE-2026-54421)
by Jay Faulkner 16 Jun '26

16 Jun '26

======================================================================================== OSSA-2026-023: Sensitive properties returned unredacted in POST and PATCH HTTP responses ======================================================================================== :Date: June 16, 2026 :CVE: CVE-2026-54421 Affects ~~~~~~~ - Ironic: >=17.0.0 <29.0.6, >=30.0.0 <32.0.2, >=33.0.0 <35.0.2, >=36.0.0 <37.0.1 Description ~~~~~~~~~~~ Tuomo Tanskanen (Ericsson Software Technology) and Dmitry Tantsur (Red Hat) of the Metal3.io Security Team discovered a vulnerability in Ironic API RBAC handling, where a user with a valid token and credentials to send a POST or PATCH request to ``/v1/volume/targets`` can have potentially sensitive properties returned in the response unredacted, such as iSCSI credentials. Patches ~~~~~~~ - https://review.opendev.org/c/openstack/ironic/+/992335 (2023.1/antelope (unmaintained)) - https://review.opendev.org/c/openstack/ironic/+/992333 (2024.1/caracal (unmaintained)) - https://review.opendev.org/c/openstack/ironic/+/992326 (2025.1/epoxy) - https://review.opendev.org/c/openstack/ironic/+/992325 (2025.2/flamingo) - https://review.opendev.org/c/openstack/ironic/+/992321 (2026.1/gazpacho) - https://review.opendev.org/c/openstack/ironic/+/990430 (2026.2/hibiscus (development)) - https://review.opendev.org/c/openstack/ironic/+/992323 (Bugfix/33.0) - https://review.opendev.org/c/openstack/ironic/+/992322 (Bugfix/34.0) Credits ~~~~~~~ - Tuomo Tanskanen from Ericsson Software Technology - Dmitry Tantsur from Red Hat References ~~~~~~~~~~ - https://bugs.launchpad.net/ironic/+bug/2155049 - http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2026-54421 Notes ~~~~~ - The vulnerable code path has existed since Ironic 9.0.0 (OpenStack Pike), however, this could only be considered an escalation of privileges after Ironic 17.0.0 (OpenStack Wallaby), when Ironic introduced the ability for project-scoped users to interact via the owner/lessee model. - Branches for 2024.1 (caracal) and 2023.1 (antelope) are unmaintained. Patches are provided as a courtesy. Releases 2023.2 (bobcat) and 2024.2 (dalmatian) are end of life and have not had patches provided. See https://releases.openstack.org for more information on supported releases. - Ironic bugfix branch patches will be available in git for interested operators. We will not perform an additional release from these branches.

1 0

[OSSA-2026-022] OpenStack Nova: Nova scheduler hint injection bypasses Placement resource claims and scheduling constraints (CVE-2026-46448)
by Goutham Pacha Ravi 16 Jun '26

16 Jun '26

========================================================================================================== OSSA-2026-022: Nova scheduler hint injection bypasses Placement resource claims and scheduling constraints ========================================================================================================== :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 ~~~~~~~~~~~ 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) 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

1 0

[OSSA-2026-017] Ironic: Script injection during node boot via linux command line override (CVE-2026-46447)
by Jay Faulkner 15 Jun '26

15 Jun '26

================================================================================ OSSA-2026-017: Script injection during node boot via linux command line override ================================================================================ :Date: June 03, 2026 :CVE: CVE-2026-46447 Affects ~~~~~~~ - Ironic: >=17.0.0 <26.1.7, >=27.0.0 <29.0.6, >=30.0.0 <32.0.2, >=33.0.0 <35.0.2 Description ~~~~~~~~~~~ Dmitry Tantsur (Red Hat) and Tuomo Tanskanen (Ericsson Software Technology) from the Metal3.io Security Team reported a vulnerability in Ironic's kernel command line override code. A user with access to add or modify ``node.driver_info`` or ``node.instance_info`` can create a crafted value to enable iPXE script execution during the boot process. Patches ~~~~~~~ - https://review.opendev.org/c/openstack/ironic/+/991387 (2023.1/antelope (unmaintained)) - https://review.opendev.org/c/openstack/ironic/+/991383 (2024.1/caracal (unmaintained)) - https://review.opendev.org/c/openstack/ironic/+/991380 (2025.1/epoxy) - https://review.opendev.org/c/openstack/ironic/+/991377 (2025.2/flamingo) - https://review.opendev.org/c/openstack/ironic/+/991374 (2026.1/gazpacho) - https://review.opendev.org/c/openstack/ironic/+/991365 (2026.2/hibscus (development)) - https://review.opendev.org/c/openstack/ironic/+/991371 (Bugfix/33.0) - https://review.opendev.org/c/openstack/ironic/+/991368 (Bugfix/34.0) Credits ~~~~~~~ - Dmitry Tantsur from Red Hat - Tuomo Tanskanen from Ericsson Software Technology References ~~~~~~~~~~ - https://bugs.launchpad.net/ironic/+bug/2150624 - http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2026-46447 Notes ~~~~~ - Releases 2024.1 (caracal) and 2023.1 (antelope) are unmaintained. Patches are provided as a courtesy. Releases 2023.2 (bobcat) and 2024.2 (dalmation) are end of life and have not had patches provided. See https://releases.openstack.org for more information on supported releases. - Ironic bugfix branch patches will be available in git for interested operators. We will not perform an additional release from these branches. - This fix removes the ability to put some valid -- but unlikely -- special characters into kernel command line overrides. There is an escape hatch for impacted clouds; setting ``CONF.conductor.disable_kernel_parameter_parsing`` to true will restrict Ironic to only blocking the most dangerous, nonsensical special characters at the cost of being less security hardened against future attacks.

1 1

[OSSN-0099] Denial of Service in Ironic under reduced process stack size (CVE-2026-50589)
by Jay Faulkner 05 Jun '26

05 Jun '26

Denial of Service in Ironic under reduced process stack size --- ### Summary ### An unauthenticated malicious user could submit a specially crafted JSON string to certain endpoints on the API service or the JSON-RPC endpoint if enabled, and cause a service crash until the service is restarted. This was due to the memory allocation exceeding the stack size of the Python runtime due to Ironic's reduced default stack size prior to the initial payload validation. ### Affected Services / Software ### - ironic: >=32.0.0, <37.0.0 ### Discussion ### The Ironic project has introduced a customized size check middleware which looks for excessive and invalid recursive JSON data structures while also enforcing path awareness and endpoint size limits based upon the intended patterns of interaction with Ironic. ### Recommended Actions ### Apply the provided Ironic patches. Review the newly provided configuration variables defaults in context of your cluster. Several options were added related to permitted JSON body sizing. The defaults should be sufficient for most clouds but can be adjusted: - '[api]/max_json_body_depth', default 25, will reject requests with JSON documents with more recursion depth than this. - '[api]/max_json_body_size', default 1024, is the maximum size, in KiB, the API service will accept for any endpoint except the node provision state and continue_inspection endpoints. Requests with a larger content-length will receive an HTTP 413 response. - '[api]/max_json_body_size_provision', default 65536 (64MiB), is the max size, in KiB, for the node provision state endpoint. The larger default is due to the need to accomodate configdrives or deploy_steps. - '[api]/max_json_body_size_inspection', default 16384 (16MiB), is the max size, in KiB, for the continue_inspection endpoint. The larger default is due to the need to accomodate inspection data from the ramdisk, which can include system logs and data larger than normal API requests. Operators unable or unwilling to patch their Ironic installations can work around the issue by increasing the process stack size by setting the environment variable 'IRONIC_THREAD_STACK_SIZE=8388608' before starting Ironic services. #### Patches #### The following reviews contain the fix for this issue: 2026.2/hibiscus (master): https://review.opendev.org/c/openstack/ironic/+/991717 2026.1/gazpacho: https://review.opendev.org/c/openstack/ironic/+/991854 2025.2/flamingo: https://review.opendev.org/c/openstack/ironic/+/991858 bugfix/34.0: https://review.opendev.org/c/openstack/ironic/+/991856 bugfix/33.0: https://review.opendev.org/c/openstack/ironic/+/991857 ### Credits ### Dmitry Tantsur, Red Hat Tuomo Tanskanen, Ericsson Software Technology Metal3.io Security Team ### Contacts / References ### Authors: - Jay Faulkner, G-Research Open Source Software (GR-OSS) - Julia Kreger, Red Hat This OSSN: https://wiki.openstack.org/wiki/OSSN/OSSN-0099 Original Launchpad bug: https://bugs.launchpad.net/ironic/+bug/2154288 Mailing List : [security-sig] tag on openstack-discuss(a)lists.openstack.org OpenStack Security : https://security.openstack.org/ CVE: CVE-2026-50589

1 0

[OSSA-2026-021] OpenStack Neutron: Neutron port RBAC policy bypass allows project managers to set trusted device owners on shared networks (CVE-2026-pending)
by Goutham Pacha Ravi 05 Jun '26

05 Jun '26

====================================================================================================================== OSSA-2026-021: Neutron port RBAC policy bypass allows project managers to set trusted device owners on shared networks ====================================================================================================================== :Date: June 04, 2026 :CVE: CVE-2026-pending Affects ~~~~~~~ - Neutron: >=25.0.0 <25.2.4, >=26.0.0 <26.0.4, >=27.0.0 <27.0.3, ==28.0.0 Description ~~~~~~~~~~~ Tim Shephard from roiai.ca reported a policy enforcement bypass in Neutron's default port RBAC rules. A project manager can create or update a port on a shared network owned by another project and set ``device_owner`` to a trusted network-service value such as ``network:dhcp``. Depending on backend and deployment, this can bypass anti-spoofing and security group protections. This is a regression of CVE-2015-5240 (OSSA-2015-018) introduced by the manager role support change. Deployments running Neutron 25.0.0 or later are affected. Patches ~~~~~~~ - https://review.opendev.org/991523 (2025.1/epoxy) - https://review.opendev.org/990356 (2025.2/flamingo) - https://review.opendev.org/990353 (2026.1/gazpacho) - https://review.opendev.org/990273 (2026.2/hibiscus) Credits ~~~~~~~ - Tim Shephard from roiai.ca (CVE-2026-pending) References ~~~~~~~~~~ - https://launchpad.net/bugs/2152115 - http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2026-pending Notes ~~~~~ - A CVE request has been filed with MITRE (CAN-2026-2030702). - This is a regression of CVE-2015-5240 (OSSA-2015-018). -- Goutham Pacha Ravi OpenStack Vulnerability Management Team https://security.openstack.org/vmt.html

1 1

OSSN-0098: Mistral workflow execution context exposes Keystone auth token
by Goutham Pacha Ravi 03 Jun '26

03 Jun '26

OSSN-0098: Mistral workflow execution context exposes Keystone auth token == Summary == Eduardo Gonzalez Gutierrez reported that Mistral stores the Keystone authentication token in the workflow execution context. Any user who can create or inspect workflow executions can retrieve active tokens via YAQL or Jinja2 expressions and use them to perform actions as the workflow initiator. Deployments where untrusted users can create or execute workflows are affected. == Affected Services / Software == * mistral: <=22.0.0 == Discussion == When a workflow execution starts, Mistral copies the full Keystone authentication context into the execution's stored context. This includes the auth_token and service_catalog. The fix masks these fields and is only applied to the master branch. Backporting to stable branches would break workflows that rely on the $.openstack.auth_token context variable. == Recommended Actions == Operators running stable branches of Mistral should: * Restrict who can create and inspect workflow executions using Mistral's policy configuration. * Audit workflow definitions for references to $.openstack.auth_token. * Upgrade to the next major release of Mistral when available, which will include the fix. The fix masks auth_token and service_catalog in the workflow execution context. It is applied to the master branch only. * 2026.2/hibiscus (master): [https://review.opendev.org/c/openstack/mistral/+/991391 Gerrit 991391] == Credits == Eduardo Gonzalez Gutierrez (Independent) Arnaud Morin, OVHCloud == Contacts / References == * Authors: Goutham Pacha Ravi, Red Hat * This OSSN: https://wiki.openstack.org/wiki/OSSN/OSSN-0098 * Original Launchpad bug: [https://launchpad.net/bugs/2146554 LP#2146554] * Mailing List: [security-sig] tag on openstack-discuss(a)lists.openstack.org * OpenStack Security: https://security.openstack.org/ * CVE: none

1 0