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

[all][elections][ptl] 2027.1 Project Team Lead Election Conclusion and Results
by Ian Y. Choi 26 Aug '26

26 Aug '26

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 : Callum Dickinson * Barbican : Mauricio Harley * Blazar : Matt Crees * Cinder : Brian Rosmaita * Cloudkitty : Rafael Weingartner * Cyborg : Sean Mooney * Designate : Omer Schwartz * Heat : Takashi Kajinami * Horizon : Tatiana Ovchinnikova * Keystone : Artem Goncharov * Kolla : Michal Nasiadka * Magnum : Michal Nasiadka * Manila : Carlos Silva * Mistral : Arnaud Morin * Neutron : Brian Haley * Nova : René Ribaud * Octavia : Gregory Thiemonge * OpenStack Charms : Felipe Reyes * OpenStack Helm : Vladimir Kozhukalov * OpenStackAnsible : Dmitriy Rabotyagov * OpenStackSDK : Artem Goncharov * Puppet OpenStack : Takashi Kajinami * Quality Assurance : Ghanshyam Maan * Rally : Andrey Kurilin * Storlets : Takashi Kajinami * Sunbeam : Hemanth Kumar Nakkina * Swift : Tim Burke * Tacker : Yasufumi Ogawa * Telemetry : Juan Larriba * Trove : Erkin Mussurmankulov * Vitrage : Dmitriy Rabotyagov * Watcher : Douglas Viroel * Zaqar : Hao Wang * Zun : Ivan Anfimov Elections: (None) Election process details and results are also available here: https://governance.openstack.org/election/ Thank you to all involved in the PTL election process,

1 0

[OSSA-2026-037] OpenStack Keystone: Inconsistent scope enforcement for delegated tokens (CVE-2026-pending)
by Goutham Pacha Ravi 25 Aug '26

25 Aug '26

============================================================================== OSSA-2026-037: Inconsistent scope enforcement for delegated tokens in Keystone ============================================================================== :Date: August 25, 2026 :CVE: CVE-2026-pending, CVE-2026-pending Affects ~~~~~~~ - Keystone: >=13.0.0 <27.0.3, >=28.0.0 <28.0.3, >=29.0.0 <29.0.3 Description ~~~~~~~~~~~ Grzegorz Grasza (Red Hat) reported that OpenStack Keystone did not consistently block delegated tokens from creating new long-lived credentials or authorizing new delegations. Tim Shephard (roiai.ca) separately reported that delegated tokens could be submitted to the token-method authentication path to escape their project scope. A token scoped through an OAuth1 access token, an application credential, or a trust could create new long-lived credentials or authorize new delegations that persist independently of, and outlive, the credential used to obtain them. Separately, tokens obtained through any of these delegation mechanisms could be submitted to the token-method authentication path for reauthentication. When an application credential token was presented with no explicit scope, Keystone would issue a new token scoped to the credential owner's default project rather than the project for which the credential was issued, escaping the intended project boundary. All Keystone deployments that permit delegated authentication through OAuth1 access tokens, application credentials, or trusts are affected. Patches ~~~~~~~ - https://review.opendev.org/1002307 (2025.1/epoxy) - https://review.opendev.org/1002308 (2025.1/epoxy) - https://review.opendev.org/1002305 (2025.2/flamingo) - https://review.opendev.org/1002306 (2025.2/flamingo) - https://review.opendev.org/1002303 (2026.1/gazpacho) - https://review.opendev.org/1002304 (2026.1/gazpacho) - https://review.opendev.org/1002301 (2026.2/hibiscus (development)) - https://review.opendev.org/1002302 (2026.2/hibiscus (development)) Credits ~~~~~~~ - Grzegorz Grasza from Red Hat - Tim Shephard from roiai.ca References ~~~~~~~~~~ - https://launchpad.net/bugs/2153453 - https://launchpad.net/bugs/2158538 - http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2026-pending - http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2026-pending Notes ~~~~~ - Two CVEs have been requested from MITRE for these vulnerabilities and are pending assignment. - The two patch sets are interdependent and must be applied together. The token reauthentication guard introduced by the second patch depends on the delegation classification logic and the new ``[auth] additional_primary_auth_methods`` configuration option introduced by the first. Packaging or applying a subset is not supported. - After upgrading, Keystone treats any authentication method not built in to Keystone as a delegated credential and rejects it from guarded operations (managing trusts, application credentials, and OAuth1 access tokens, and token reauthentication). Deployments running a custom or third-party authentication plugin must add it to ``[auth] additional_primary_auth_methods`` or those authentication flows will fail. - This advisory does not address a related weakness in EC2 credential (``ec2credential``) handling, which is being tracked and fixed in public and will be covered by a separate OpenStack Security Note (OSSN). - A related fix to the Keystone Tempest plugin test suite was proposed at https://review.opendev.org/1002296 -- Goutham Pacha Ravi OpenStack Vulnerability Management Team https://security.openstack.org/vmt.html

1 1

[OSSA-2026-036] OpenStack Aodh and Watcher: Aodh cross-project alarm enumeration and Watcher webhook authorization bypass (CVE-2026-pending)
by Goutham Pacha Ravi 20 Aug '26

20 Aug '26

============================================================================================ OSSA-2026-036: Aodh cross-project alarm enumeration and Watcher webhook authorization bypass ============================================================================================ :Date: August 19, 2026 :CVE: CVE-2026-pending Affects ~~~~~~~ - Aodh: >=10.0.0 <20.0.1, ==21.0.0, ==22.0.0 - Watcher: >=4.0.0 <14.1.2, >=15.0.0 <15.1.2, >=16.0.0 <16.0.2 Description ~~~~~~~~~~~ Chen YuXiang of the Institute of Computing Technology, Chinese Academy of Sciences reported that OpenStack Aodh does not enforce project scope on the alarm listing API when the ``all_projects`` query parameter is supplied with a false value. A non-admin user holding only the reader role can list alarms belonging to other projects, optionally targeting a specific project, exposing alarm metadata such as webhook action URLs, signal endpoints, and project identifiers. All Aodh deployments are affected. The same reporter found that OpenStack Watcher does not apply authorization to its webhook trigger endpoint. Any authenticated user who learns an audit's webhook URL, for example from the Aodh alarm metadata leaked above, can start an ``EVENT`` audit and its associated action plan regardless of their own project or role. All Watcher deployments are affected. Patches ~~~~~~~ - https://review.opendev.org/1001503 (2025.1/epoxy (aodh)) - https://review.opendev.org/1001509 (2025.1/epoxy (watcher)) - https://review.opendev.org/1001502 (2025.2/flamingo (aodh)) - https://review.opendev.org/1001508 (2025.2/flamingo (watcher)) - https://review.opendev.org/1001501 (2026.1/gazpacho (aodh)) - https://review.opendev.org/1001507 (2026.1/gazpacho (watcher)) - https://review.opendev.org/1001500 (2026.2/hibiscus (development) (aodh)) - https://review.opendev.org/1001505 (2026.2/hibiscus (development) (watcher)) Credits ~~~~~~~ - Chen YuXiang from Institute of Computing Technology, Chinese Academy of Sciences References ~~~~~~~~~~ - https://launchpad.net/bugs/2161276 - https://launchpad.net/bugs/2161771 - http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2026-pending Notes ~~~~~ - A CVE identifier was requested from MITRE for the aodh vulnerability on 2026-08-03. The CVE will be added to this advisory by errata once assigned. -- Goutham Pacha Ravi OpenStack Vulnerability Management Team https://security.openstack.org/vmt.html

1 1

[security-sig][OSSN-0108] Multiple authentication vulnerabilities in Ceph
by Goutham Pacha Ravi 20 Aug '26

20 Aug '26

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 and CVE-2026-54330). All OpenStack services using CephX keyrings are affected. Ceph servers should be upgraded and their CephX keyrings should be rotated. The CephX keyrings used by OpenStack should be rotated only after Ceph client software on every OpenStack server is upgraded and then virtual machines need 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 allowed_ciphers auth_allowed_ciphers 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 auth_allowed_ciphers 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(a)lists.openstack.org OpenStack Security : https://security.openstack.org/ Ceph Advisory: https://ceph.io/en/news/blog/2026/v20-2-4-v19-2-6-combo-released/ CVE: CVE-2025-30156, CVE-2026-39944, CVE-2026-50152, CVE-2026-54330

1 0

[OSSA-2026-008] ERRATA 2: Ironic Command Injection in IPMI Console Implementations
by Jay Faulkner 19 Aug '26

19 Aug '26

======================================================================= OSSA-2026-008: Command Injection in Ironic IPMI Console Implementations ======================================================================= :Date: April 27, 2026 :CVE: CVE-2026-42510 Affects ~~~~~~~ - Ironic: >=4.3.0 <26.1.6, >=27.0.0 <29.0.5, >=30.0.0 <32.0.1, >=33.0.0 <35.0.1 Description ~~~~~~~~~~~ Dmitry Tantsur and Tuomo Tanskanen from the Metal3.io Security Team reported a vulnerability in Ironic's IPMI console backends. A project manager for the project marked as a ``node.owner`` can inject arbitrary commands which a conductor executes on console activation. No console backends are enabled by default in Ironic. Only installations which have set ``[conductor]/enabled_console_interfaces`` to enable either ``ipmitool-shellinabox`` or ``ipmitool-socat`` are vulnerable. Errata ~~~~~~ - **Errata 1:** When the original advisory was published a CVE number was not assigned. CVE-2026-42510 was assigned on 2026-04-29. - **Errata 2:** The original fix shell-quoted the console command, but socat executes it directly without a shell and so treated the quoted command line as a single program name. Deployments using the ipmitool-socat console interface lose console functionality entirely as a result, though the vulnerability itself is not reintroduced. The Errata 2 patches provide an additional fix which escapes the command for socat's own address syntax. Patches ~~~~~~~ - **Original** https://review.opendev.org/c/openstack/ironic/+/986418 (2023.1/antelope (unmaintained)) - **Errata 2** https://review.opendev.org/c/openstack/ironic/+/1000990 (2023.1/antelope (unmaintained)) - **Original** https://review.opendev.org/c/openstack/ironic/+/986417 (2024.1/caracal (unmaintained)) - **Errata 2** https://review.opendev.org/c/openstack/ironic/+/1000989 (2024.1/caracal (unmaintained)) - **Original** https://review.opendev.org/c/openstack/ironic/+/986363 (2024.2/dalmatian) - **Original** https://review.opendev.org/c/openstack/ironic/+/986362 (2025.1/epoxy) - **Errata 2** https://review.opendev.org/c/openstack/ironic/+/1000986 (2025.1/epoxy) - **Original** https://review.opendev.org/c/openstack/ironic/+/986361 (2025.2/flamingo) - **Errata 2** https://review.opendev.org/c/openstack/ironic/+/1000985 (2025.2/flamingo) - **Original** https://review.opendev.org/c/openstack/ironic/+/986235 (2026.1/gazpacho) - **Errata 2** https://review.opendev.org/c/openstack/ironic/+/1000984 (2026.1/gazpacho) - **Errata 2** https://review.opendev.org/c/openstack/ironic/+/999701 (2026.2/hibiscus) Credits ~~~~~~~ - Dmitry Tantsur from Metal3.io Security Team - Tuomo Tanskanen from Metal3.io Security Team References ~~~~~~~~~~ - https://launchpad.net/bugs/2148331 - http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2026-42510 Notes ~~~~~ - A CVE request was filed with MITRE on 2026-04-27. - Patches for unmaintained branches are provided as a courtesy. - The ``ipmitool-shellinabox`` console interface is already scheduled for removal from Ironic for lack of security support for shellinabox. Security sensitive operators are strongly encouraged to stop use of this console interface immediately. - **Errata 2** The console regression affects the 26.1.6, 29.0.5, 29.0.6, 32.0.1, 35.0.1, 36.0.0, 37.0.0 and 38.0.0 releases; stable/2024.2 has since been retired, so 26.1.6 can only be corrected by applying the additional fix locally. OSSA History ~~~~~~~~~~~~ - 2026-08-19 - Errata 2 - 2026-04-29 - Errata 1 - 2026-04-27 - Original Version

1 0

[OSSA-2026-035] OpenStack Octavia: Unauthorized QoS policy deletion lock (CVE pending)
by Jeremy Stanley 17 Aug '26

17 Aug '26

==================================================== OSSA-2026-035: Unauthorized QoS policy deletion lock ==================================================== :Date: August 13, 2026 :CVE: PENDING Affects ~~~~~~~ - Octavia: <16.0.2, ==17.0.0, ==18.0.0 Description ~~~~~~~~~~~ Chen YuXiang with the Institute of Computing Technology, Chinese Academy of Sciences, reported a vulnerability in Octavia quality of service (QoS) policy authorization. By associating another project's QoS policy with an amphora, an authenticated user may prevent deletion of that policy. All Octavia deployments are affected. Patches ~~~~~~~ - https://review.opendev.org/1000296 (2025.1/epoxy) - https://review.opendev.org/1000295 (2025.2/flamingo) - https://review.opendev.org/1000094 (2026.1/gazpacho) - https://review.opendev.org/998935 (2026.2/hibiscus (development)) Credits ~~~~~~~ - Chen YuXiang from Institute of Computing Technology, Chinese Academy of Sciences References ~~~~~~~~~~ - https://launchpad.net/bugs/2161500 - http://cve.mitre.org/cgi-bin/cvename.cgi?name=PENDING Notes ~~~~~ - A CVE assignment was requested from MITRE on 2026-08-05 (request 2079027); this advisory will be updated with the ID in an errata publication once it becomes available. -- Jeremy Stanley OpenStack Vulnerability Management Team https://security.openstack.org/vmt.html

1 1

[OSSN-0107] Ironic-Python-Agent: Container HardwareManager Security Model Misimplemented
by Jay Faulkner 13 Aug '26

13 Aug '26

Ironic Python Agent Container HardwareManager Security Misimplemented --- ### Summary ### Ironic Python Agent's ContainerHardwareManager plugin, shipped in 2025.2, was merged with a misimplemented security model. Ironic developers have pushed an updated version of this feature, including patches for Ironic and Ironic Python Agent, with properly implemented security controls. These patches will not be universally backported as they are not backwards-compatible. ### Affected Services / Software ### - ironic-python-agent: >=11.0.0, <12.0.1 ### Discussion ### The Ironic Python Agent uses plugins called HardwareManagers (HWMs) to expose new in-band steps for Ironic cleaning, servicing, or deployment. In the 2025.2 release, a Container HWM was added, giving operators who added a container runner (such as ``podman`` or ``docker``) to their ramdisk the option to download and execute containers as Ironic steps. This initial implementation had several security flaws and was implemented in such a way that we could not backport fixes without breaking existing deployments. These issues included ignoring the value of the ``[container]/allow_arbitrary_containers`` safety mechanism. ### Recommended Actions ### * Operators who are using OpenStack-supplied ramdisks are not vulnerable. These images, for the impacted releases, do not come with ``podman`` or ``docker`` installed, disabling the feature. You are secure without taking any action and will upgrade into the fixed version in OpenStack 2026.2 or later. * Operators who are using ramdisks with ``docker`` or ``podman`` installed, for example, via the ``ironic-python-agent-podman`` element in ``ironic-python-agent-builder`` but are not interested in the Container HWM should add ``deploy.container_clean_step`` and ``deploy.generic_container_step`` to ``[api]/disallow_service_steps``, ``[api]/disallow_clean_steps``, and ``[api]/disallow_deploy_steps``. This will disable the insecure code. Patches to add the ``disallow_*_steps`` options are available in OSSA-2026-025. * Operators currently using the Container HWM or who wish to use it should backport the patches from https://review.opendev.org/q/hashtag:%22container-hwm-patches%22 to the branch they are currently using. Then, evaluate your use case against the updated documentation https://docs.openstack.org/ironic/latest/admin/container-based-steps.html to ensure the changes were not breaking for any existing deployment. ### Credits ### - Tuomo Tanskanen, Ericsson Software Technology (Metal3.io Security Team) - Riccardo Pittau, Red Hat (Metal3.io Security Team) ### Contacts / References ### Authors: - Jay Faulkner, G-Research OSS This OSSN: https://wiki.openstack.org/wiki/OSSN/OSSN-0107 Original Launchpad bug: https://bugs.launchpad.net/ironic/+bug/2160143 Mailing List : [security-sig] tag on openstack-discuss(a)lists.openstack.org OpenStack Security : https://security.openstack.org/ CVE: none

1 0

[OSSN-0106] Ironic API ramdisk endpoints require network-level access controls
by Jay Faulkner 11 Aug '26

11 Aug '26

Ironic API ramdisk endpoints require network-level access controls --- ### Summary ### The Ironic Bare Metal API combines authenticated endpoints for client use with unauthenticated endpoints for coordination with the Ironic Python Agent ramdisk into a single API service. Depending on the deployment architecture, this can expose security risks if the unauthenticated endpoints are reachable from untrusted networks. ### Affected Services / Software ### - ironic: >=6.2.0 - /v1/lookup and /v1/heartbeat: API version 1.22 (Newton, ironic 6.2.0) - /v1/continue_inspection: API version 1.84 (2024.2) ### Discussion ### Ironic has three endpoints which allow unauthenticated access: - ``GET /v1/lookup`` - ``POST /v1/heartbeat/{node_ident}`` - ``POST /v1/continue_inspection`` These endpoints are a documented aspect of Ironic's architecture and are covered in the Ironic security guide. They already have significant security controls to mitigate risk, such as bootstrapping into credentials via the agent token mechanism (mandatory since the Victoria release), callback URL validation, and defaulting to limiting access to nodes whose provisioning state requires use of them. Regardless of authentication methodology, operators in multi-tenant or untrusted environments should deploy a split-horizon API configuration where the unauthenticated endpoints are not reachable from public or tenant networks. Using Keystone does not eliminate the need for this network-level separation. Previously, Ironic only provided policy-based overrides to disable these endpoints, which required Keystone and left operators using HTTP basic auth or noauth without an equivalent control. A new ``[api]enable_ramdisk_endpoints`` configuration option is being added to allow any operator, regardless of authentication methodology, to disable these endpoints on a per-service basis. For full details on the security model around these endpoints, refer to the Ironic security guide: https://docs.openstack.org/ironic/latest/admin/security.html ### Recommended Actions ### Operators using Ironic in a multi-tenant or untrusted environment should configure the Ironic API so that the unauthenticated endpoints are only accessible from networks where the Ironic Python Agent ramdisk operates. This can be achieved in several ways depending on infrastructure setup: 1. Run separate public-facing and ramdisk-facing Ironic API services. WARNING: Disabling the ramdisk endpoints without maintaining a separate API service that the Ironic Python Agent can reach will break all deployment, cleaning, inspection, rescue, and servicing workflows. These endpoints must remain available to the ramdisk on at least one API service. On the public-facing service, disable the ramdisk endpoints using one of the following methods: * Set ``[api]enable_ramdisk_endpoints`` to ``False`` in ironic.conf (anticipated in the 2026.2 Hibiscus cycle, ironic 39.0.0; available earlier by applying the linked patch). * For Keystone-authenticated deployments, add the following to policy.yaml:: "baremetal:node:ipa_heartbeat": "!" "baremetal:driver:ipa_lookup": "!" "baremetal:driver:ipa_continue_inspection": "!" When using this architecture, the ``[deploy]external_callback_url`` setting can direct the agent callback URL to the internal API service, and the ``[service_catalog]endpoint_override`` setting can override Ironic's own internal endpoint resolution, if required. 2. Use a fronting HTTP proxy, WSGI runner, or other external method to restrict access to ``/v1/lookup``, ``/v1/heartbeat``, and ``/v1/continue_inspection`` to only networks which run the Ironic Python Agent. This method requires no Ironic code changes. 3. Ensure ``[api]restrict_lookup`` remains set to its default value of ``True``. Disabling this setting removes state-based filtering on the lookup endpoint and significantly broadens exposure. ### Credits ### - Tuomo Tanskanen, Ericsson Software Technology (Metal3.io Security Team) - Dmitry Tantsur, Red Hat (Metal3.io Security Team) ### Contacts / References ### Authors: - Julia Kreger, Red Hat - Jay Faulkner, G-Research OSS This OSSN: https://wiki.openstack.org/wiki/OSSN/OSSN-0106 Original Launchpad bugs: - https://bugs.launchpad.net/ironic/+bug/2162821 - https://bugs.launchpad.net/ironic/+bug/2162818 Proposed enhancement: https://review.opendev.org/c/openstack/ironic/+/999897 Mailing List : [security-sig] tag on openstack-discuss(a)lists.openstack.org OpenStack Security : https://security.openstack.org/ CVE: none

1 0

[OSSN-0105] OpenStack Glance legacy Tasks import bypasses image import URI filtering
by Goutham Pacha Ravi 11 Aug '26

11 Aug '26

OSSN-0105: OpenStack Glance legacy Tasks import bypasses image import URI filtering --- ### Summary ### The deprecated Glance /v2/tasks API accepts type=import tasks that bypass import_filtering_opts, allowing an admin to fetch internal URLs from the Glance service network (SSRF). The tasks API has been admin-only since Xena and deprecated for several releases. ### Affected Services / Software ### - glance: >=30.0.0 <30.3.0, >=31.0.0 <31.1.1, ==32.0.0 ### Discussion ### The legacy tasks import path uses a permissive URI validator that only checks for http:// or https:// prefixes, bypassing the host and port restrictions enforced by the modern web-download import. ### Recommended Actions ### Disable the legacy tasks API via policy if you are not using it. Otherwise, upgrade Glance to a version containing the fix. #### Patches #### The following reviews contain the fix for this issue: 2026.2/hibiscus (development): https://review.opendev.org/993588 2026.1/gazpacho: https://review.opendev.org/994466 2025.2/flamingo: https://review.opendev.org/994592 2025.1/epoxy: https://review.opendev.org/1000061 ### Credits ### Tim Shephard, roiai.ca ### Contacts / References ### Authors: - Goutham Pacha Ravi, Red Hat This OSSN: https://wiki.openstack.org/wiki/OSSN/OSSN-0105 Original Launchpad bug: https://bugs.launchpad.net/glance/+bug/2152110 Mailing List : [security-sig] tag on openstack-discuss(a)lists.openstack.org OpenStack Security : https://security.openstack.org/ CVE: none

1 0

[OSSA-2026-034] OpenStack Designate: Cross-tenant DNS zone overlap and mDNS DoS via pool scheduling (CVE-2026-71193, CVE-2026-71194)
by Goutham Pacha Ravi 11 Aug '26

11 Aug '26

============================================================================= OSSA-2026-034: Cross-tenant DNS zone overlap and mDNS DoS via pool scheduling ============================================================================= :Date: August 11, 2026 :CVE: CVE-2026-71193, CVE-2026-71194 Affects ~~~~~~~ - Designate: >=1.0.0 <20.0.2, ==21.0.0, ==22.0.0 Description ~~~~~~~~~~~ Tore Anderson of Redpill Linpro AS reported that OpenStack Designate does not enforce cross-pool zone ownership checks when scheduling a zone to a non-default pool via the attribute filter. A tenant can create a sub-zone, super-zone, or duplicate of another tenant's zone by targeting a different pool, enabling DNS hijack or denial of service. Independently, Omer Schwartz of Red Hat identified that the mDNS handler performs pool-blind record lookups, causing a deterministic denial of service when colliding zones exist across pools. All deployments using multiple Designate pools are affected. Patches ~~~~~~~ - https://review.opendev.org/1000475 (2025.1/epoxy) - https://review.opendev.org/1000474 (2025.2/flamingo) - https://review.opendev.org/1000473 (2026.1/gazpacho) - https://review.opendev.org/1000471 (2026.2/hibiscus (development)) Credits ~~~~~~~ - Tore Anderson from Redpill Linpro AS - Omer Schwartz from Red Hat References ~~~~~~~~~~ - https://launchpad.net/bugs/2160533 - http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2026-71193 - http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2026-71194 Notes ~~~~~ - The stable branch patches depend on two prerequisite backports (mDNS split-horizon pool scoping, Change 998005/998006 and their stable equivalents) that were merged before disclosure. Operators applying the fix to releases older than the next point release should ensure those prerequisite commits are present. - Operators should audit existing zones for cross-tenant collisions that may have been created before the fix. A detection tool will be proposed as a separate public patch. -- Goutham Pacha Ravi OpenStack Vulnerability Management Team https://security.openstack.org/vmt.html

1 0