- Yaook - lists.alasca.cloud

[Security Advisory][cinder] Cross-project information disclosure in Cinder Messages API (CVE-2026-93856)

by Jonas Schäfer

Hi everyone, The YAOOK project just published a security advisory: https://yaook.cloud/security-advisories-cve-2026-93856/ Images are being pushed and will be available within then next few minutes. ## What is CVE-2026-93856 and how does it affect YAOOK? CVE-2026-93856 is a vulnerability in OpenStack cinder which allows an authenticated attacker with the “reader” or “member” role assigned to read Cinder messages from projects where they don’t have permissions. ## Is my cluster vulnerable? The following images are vulnerable: cinder images before 2.0.194. If an affected image is used in your cluster for the cinder-api deployment, the cluster is vulnerable. The fixed image has been built in a private pipeline [1] which has been published alongside this advisory to prove the image provenance. ## Upgrading A new stable release will be published according to the release cycle and hotfix releases will be produced starting now. You can upgrade to that release simply by updating your operators. If you want to patch cinder ahead of the next regular YAOOK release, you can set the YAOOK_OP_VERSIONS_OVERRIDE variable in your Cinder operator container to pull the image before the YAOOK comprehensive release is ready. The best way to do this is to set the following in the values.yaml of your cinder-operator (make sure to merge this correctly with an existing values.yaml, if you have that). operator: extraEnv: - name: YAOOK_OP_VERSIONS_OVERRIDE value: | { "registry.yaook.cloud/yaook/cinder-2024.1": "registry.yaook.cloud/yaook/cinder-2024.1:2.0.194", "registry.yaook.cloud/yaook/cinder-2024.2": "registry.yaook.cloud/yaook/cinder-2024.2:2.0.194", "registry.yaook.cloud/yaook/cinder-2025.1": "registry.yaook.cloud/yaook/cinder-2025.1:2.0.194", "registry.yaook.cloud/yaook/cinder-2025.2": "registry.yaook.cloud/yaook/cinder-2025.2:2.0.194", "registry.yaook.cloud/yaook/cinder-2026.1": "registry.yaook.cloud/yaook/cinder-2026.1:2.0.194" } If you are not using Helm, you can add the environment variable to the env section of your cinder-operator’s Deployment’s pod template. kind regards, Jonas Schäfer [1]: https://gitlab.com/yaook-security/images/cinder/-/pipelines/ 2967220013 -- Jonas Schäfer CTO Business Unit Cloud Cloud&Heat Technologies GmbH Königsbrücker Straße 96 | 01099 Dresden +49 351 479 367 37 jonas.schaefer(a)cloudandheat.com | www.cloudandheat.com Green, Open, Efficient. Your Cloud Service and Cloud Technology Provider from Dresden. https://www.cloudandheat.com/ Commercial Register: District Court Dresden Register Number: HRB 30549 VAT ID No.: DE281093504 Managing Director: Nicolas Röhrs Authorized signatory: Dr. Marius Feldmann

Oct. 20, 2026

ALASCA Summit 2026

by Stefan Hoffmann

Hi, I'd like to invite you to the ALASCA Summit this year. With the motto "With C – as in Community. Breaking down technical silos united for a digitally sovereign Europe." We can meet as Yaook and ALASCA community and join technical deep dives, hands on workshops and panel discussions. There is also a Yaook workshop and talk (by me, yeah!) This time we also have a joined OpenInfra Track, supported by the OpenInfra foundation, with topics related to OpenStack etc. Further information can be found at https://alasca.cloud/alasca-summit-2026/ Please register, if you plan to join us: https://alasca.cloud/alasca-summit-2026/alasca-summit-2026-tickets/ Best Stefan -- Stefan Hoffmann DevOps Engineer Cloud&Heat Technologies GmbH Königsbrücker Straße 96 | 01099 Dresden +49 351 479 367 36 stefan.hoffmann(a)cloudandheat.com |www.cloudandheat.com Green, Open, Efficient. Your Cloud Service and Cloud Technology Provider from Dresden. https://www.cloudandheat.com/ Commercial Register: District Court Dresden Register Number: HRB 30549 VAT ID No.: DE281093504 Managing Director: Nicolas Röhrs Authorized signatory: Dr. Marius Feldmann

Oct. 5, 2026

[Security Advisory][glance] Multiple SSRF vulnerabilities (CVE-2026-71196, CVE-2026-71197, CVE-2026-71198)

by Stefan Hoffmann

Hi Yaook users, OpenStack published three CVEs for glance. Sergey Kanibor and Abhishek Kekane reported three related SSRF vulnerabilities in Glance's web-download import method and HTTP image location APIs. The web-download import ships with insecure default filtering that permits authenticated users to fetch arbitrary internal URLs including cloud metadata endpoints. Additionally, the URI validator does not resolve DNS before applying host filters, enabling bypass via attacker-controlled domains and DNS rebinding. The HTTP image location API lacks host filtering entirely when the HTTP store is enabled. Fetched content is stored as image data and can be downloaded, turning blind SSRF into full-read exfiltration. The following images are vulnerable: * glance images before 1.1.165 * yaook release before 3.4.0 If this image is used in your cluster for the glance deployment, the cluster is vulnerable. The fixed image has been built in a private pipeline[2] which has been published alongside this advisory[1] to prove the image provenance. We recommend to add a YAOOK_OP_VERSIONS_OVERRIDE[3] variable to your glance operator container to pull the image before the YAOOK comprehensive release is ready. |operator: extraEnv: - name: YAOOK_OP_VERSIONS_OVERRIDE value: | { "registry.yaook.cloud/yaook/glance-2024.1": "registry.yaook.cloud/yaook/glance-2024.1:1.1.165", "registry.yaook.cloud/yaook/glance-2024.2": "registry.yaook.cloud/yaook/glance-2024.2:1.1.165", "registry.yaook.cloud/yaook/glance-2025.1": "registry.yaook.cloud/yaook/glance-2025.1:1.1.165", "registry.yaook.cloud/yaook/glance-2025.2": "registry.yaook.cloud/yaook/glance-2025.2:1.1.165", "registry.yaook.cloud/yaook/glance-2026.1": "registry.yaook.cloud/yaook/glance-2026.1:1.1.165" }| More info can be found in our security advisory[1]. Regards Stefan [1] https://yaook.cloud/security-advisories-cve-2026-71196-71197-71198/ [2] https://gitlab.com/yaook-security/images/glance/-/pipelines/2813498997 [3] https://docs.yaook.cloud/user/references/env-reference.html#envvar-YAOOK_OP… -- Stefan Hoffmann DevOps Engineer Cloud&Heat Technologies GmbH Königsbrücker Straße 96 | 01099 Dresden +49 351 479 367 36 stefan.hoffmann(a)cloudandheat.com |www.cloudandheat.com Green, Open, Efficient. Your Cloud Service and Cloud Technology Provider from Dresden. https://www.cloudandheat.com/ Commercial Register: District Court Dresden Register Number: HRB 30549 VAT ID No.: DE281093504 Managing Director: Nicolas Röhrs Authorized signatory: Dr. Marius Feldmann

Sept. 3, 2026

Re: [Security Advisory][keystone] CVE-2026-pending Launchpad bug 2153453 and 2158538

by Stefan Hoffmann

Hint: The today published Yaook release (3.3.1) does not have the fixes included. So the override is still needed. On 8/25/26 17:35, Stefan Hoffmann via Announce wrote: > > Hi Yaook users, > > OpenStack published CVEs for keystone. > > Grzegorz Grasza (Red Hat) and Tim Shephard (roiai.ca) independently > identified that OpenStack Keystone does not consistently enforce scope > restrictions on tokens obtained via > delegated authentication methods (ec2credential, application > credential, OAuth1 access tokens). The underlying issue is the same: > delegated tokens can perform operations or reach projects beyond their > intended scope. Two separate CVEs have been requested for distinct > attack vectors that share this root cause. > > Delegation bypass in trust, OAuth1, and application credential > operations (CVE-2026-pending, LP#2153453): > Tokens obtained via EC2 credential authentication can create new > application credentials and authorize OAuth1 request tokens, > bootstrapping new delegations that persist independently of the > original credential and survive its revocation. Both EC2 and OAuth1 > tokens can create trusts that delegate roles beyond the requesting > token’s scope, because trust role validation checks the trustor’s full > role assignments rather than the token’s scoped roles. > > Token reauthentication escape (CVE-2026-pending, LP#2158538): > Tokens obtained via application credential or EC2 credential > authentication can escape their intended project scope through > token-method reauthentication. An application-credential token scoped > to one project can be exchanged via POST /v3/auth/tokens with no > explicit scope, causing Keystone to issue a new token scoped to the > owner’s default project. For EC2-derived tokens the bypass is broader: > because they carry no delegation markers, they can rescope to any > project where the underlying user has role assignments. > > The following images are vulnerable: > > * keystone images before 3.0.94 > * yaook release before 3.4.0 > > If this image is used in your cluster for the keystone deployment, the > cluster is vulnerable. > > The fixed image has been built in a private pipeline[2] which has been > published alongside this advisory[1] to prove the image provenance. > > We recommend to add a YAOOK_OP_VERSIONS_OVERRIDE[3] variable to your > keystone operator container to pull the image before the YAOOK > comprehensive release is ready. > > |operator: extraEnv: - name: YAOOK_OP_VERSIONS_OVERRIDE value: | { > "registry.yaook.cloud/yaook/keystone-2024.1": > "registry.yaook.cloud/yaook/keystone-2024.1:3.0.94", > "registry.yaook.cloud/yaook/keystone-2024.2": > "registry.yaook.cloud/yaook/keystone-2024.2:3.0.94", > "registry.yaook.cloud/yaook/keystone-2025.1": > "registry.yaook.cloud/yaook/keystone-2025.1:3.0.94", > "registry.yaook.cloud/yaook/keystone-2025.2": > "registry.yaook.cloud/yaook/keystone-2025.2:3.0.94", > "registry.yaook.cloud/yaook/keystone-2026.1": > "registry.yaook.cloud/yaook/keystone-2026.1:3.0.94" }| > > More info can be found in our security advisory[1]. > > Regards > Stefan > > > [1] https://yaook.cloud/security-advisories-ossa-2026-037/ > [2] > https://gitlab.com/yaook-security/images/keystone/-/pipelines/2789490776 > [3] > https://docs.yaook.cloud/user/references/env-reference.html#envvar-YAOOK_OP… > > > > -- > Stefan Hoffmann > DevOps Engineer > > Cloud&Heat Technologies GmbH > Königsbrücker Straße 96 | 01099 Dresden > +49 351 479 367 36 > stefan.hoffmann(a)cloudandheat.com |www.cloudandheat.com > > Green, Open, Efficient. > Ihr Cloud-Service- und Cloud-Technologie-Provider aus Dresden. > https://www.cloudandheat.com/ > > Commercial Register: District Court Dresden > Register Number: HRB 30549 > VAT ID No.: DE281093504 > Managing Director: Nicolas Röhrs > Authorized signatory: Dr. Marius Feldmann > > _______________________________________________ > Announce mailing list --announce(a)lists.alasca.cloud > To unsubscribe send an email toannounce-leave(a)lists.alasca.cloud -- Stefan Hoffmann DevOps Engineer Cloud&Heat Technologies GmbH Königsbrücker Straße 96 | 01099 Dresden +49 351 479 367 36 stefan.hoffmann(a)cloudandheat.com |www.cloudandheat.com Green, Open, Efficient. Ihr Cloud-Service- und Cloud-Technologie-Provider aus Dresden. https://www.cloudandheat.com/ Commercial Register: District Court Dresden Register Number: HRB 30549 VAT ID No.: DE281093504 Managing Director: Nicolas Röhrs Authorized signatory: Dr. Marius Feldmann

Aug. 27, 2026

[Security Advisory][keystone] CVE-2026-pending Launchpad bug 2153453 and 2158538

by Stefan Hoffmann

Hi Yaook users, OpenStack published CVEs for keystone. Grzegorz Grasza (Red Hat) and Tim Shephard (roiai.ca) independently identified that OpenStack Keystone does not consistently enforce scope restrictions on tokens obtained via delegated authentication methods (ec2credential, application credential, OAuth1 access tokens). The underlying issue is the same: delegated tokens can perform operations or reach projects beyond their intended scope. Two separate CVEs have been requested for distinct attack vectors that share this root cause. Delegation bypass in trust, OAuth1, and application credential operations (CVE-2026-pending, LP#2153453): Tokens obtained via EC2 credential authentication can create new application credentials and authorize OAuth1 request tokens, bootstrapping new delegations that persist independently of the original credential and survive its revocation. Both EC2 and OAuth1 tokens can create trusts that delegate roles beyond the requesting token’s scope, because trust role validation checks the trustor’s full role assignments rather than the token’s scoped roles. Token reauthentication escape (CVE-2026-pending, LP#2158538): Tokens obtained via application credential or EC2 credential authentication can escape their intended project scope through token-method reauthentication. An application-credential token scoped to one project can be exchanged via POST /v3/auth/tokens with no explicit scope, causing Keystone to issue a new token scoped to the owner’s default project. For EC2-derived tokens the bypass is broader: because they carry no delegation markers, they can rescope to any project where the underlying user has role assignments. The following images are vulnerable: * keystone images before 3.0.94 * yaook release before 3.4.0 If this image is used in your cluster for the keystone deployment, the cluster is vulnerable. The fixed image has been built in a private pipeline[2] which has been published alongside this advisory[1] to prove the image provenance. We recommend to add a YAOOK_OP_VERSIONS_OVERRIDE[3] variable to your keystone operator container to pull the image before the YAOOK comprehensive release is ready. |operator: extraEnv: - name: YAOOK_OP_VERSIONS_OVERRIDE value: | { "registry.yaook.cloud/yaook/keystone-2024.1": "registry.yaook.cloud/yaook/keystone-2024.1:3.0.94", "registry.yaook.cloud/yaook/keystone-2024.2": "registry.yaook.cloud/yaook/keystone-2024.2:3.0.94", "registry.yaook.cloud/yaook/keystone-2025.1": "registry.yaook.cloud/yaook/keystone-2025.1:3.0.94", "registry.yaook.cloud/yaook/keystone-2025.2": "registry.yaook.cloud/yaook/keystone-2025.2:3.0.94", "registry.yaook.cloud/yaook/keystone-2026.1": "registry.yaook.cloud/yaook/keystone-2026.1:3.0.94" }| More info can be found in our security advisory[1]. Regards Stefan [1] https://yaook.cloud/security-advisories-ossa-2026-037/ [2] https://gitlab.com/yaook-security/images/keystone/-/pipelines/2789490776 [3] https://docs.yaook.cloud/user/references/env-reference.html#envvar-YAOOK_OP… -- Stefan Hoffmann DevOps Engineer Cloud&Heat Technologies GmbH Königsbrücker Straße 96 | 01099 Dresden +49 351 479 367 36 stefan.hoffmann(a)cloudandheat.com |www.cloudandheat.com Green, Open, Efficient. Ihr Cloud-Service- und Cloud-Technologie-Provider aus Dresden. https://www.cloudandheat.com/ Commercial Register: District Court Dresden Register Number: HRB 30549 VAT ID No.: DE281093504 Managing Director: Nicolas Röhrs Authorized signatory: Dr. Marius Feldmann

Aug. 25, 2026

[DEPRECATION] OpenStack support for 2024.1 / caracal at yaook

by Stefan Hoffmann

Hi yaook-users, we would like to remove support for OpenStack version 2024.1/caracal soon. If you have any concerns or still use this version, please comment to https://gitlab.com/yaook/operator/-/work_items/692 Best regards Stefan -- Stefan Hoffmann DevOps Engineer Cloud&Heat Technologies GmbH Königsbrücker Straße 96 | 01099 Dresden +49 351 479 367 36 stefan.hoffmann(a)cloudandheat.com | www.cloudandheat.com Green, Open, Efficient. Ihr Cloud-Service- und Cloud-Technologie-Provider aus Dresden. https://www.cloudandheat.com/ Commercial Register: District Court Dresden Register Number: HRB 30549 VAT ID No.: DE281093504 Managing Director: Nicolas Röhrs Authorized signatory: Dr. Marius Feldmann

Aug. 14, 2026

[Security Advisory][designate] CVE-2026-71193 and CVE-2026-71194

by Stefan Hoffmann

Hi Yaook users, OpenStack published two CVEs for designate. One is a vulnerability in OpenStack Designate zone scheduling. An authenticated tenant can bypass zone ownership checks by scheduling a zone to a different pool, creating overlapping zones that hijack or deny service to another tenant's DNS records. Any user with the default create_zone policy can exploit this when the AttributeFilter scheduler is enabled. Only deployments using the AttributeFilter scheduler with multiple pools are affected. The other CVE is a related vulnerability in the Designate mDNS handler during triage. The mDNS handler performs pool-blind record lookups that fail when colliding zones exist across pools, causing deterministic DNS query failures. The NOTIFY handler path is reachable via unauthenticated UDP. The following images are vulnerable: * designate images before 1.0.29 * yaook release before 3.3.0 If this image is used in your cluster for the designate deployment, the cluster is vulnerable. The fixed image has been built in a private pipeline[2] which has been published alongside the advisory[1] to prove the image provenance. We recommend to add a YAOOK_OP_VERSIONS_OVERRIDE[3] variable to your Designate operator container to pull the image before the YAOOK comprehensive release is ready. |operator: extraEnv: - name: YAOOK_OP_VERSIONS_OVERRIDE value: | { "registry.yaook.cloud/yaook/designate-2024.1": "registry.yaook.cloud/yaook/designate-2024.1:1.0.29", "registry.yaook.cloud/yaook/designate-2024.2": "registry.yaook.cloud/yaook/designate-2024.2:1.0.29", "registry.yaook.cloud/yaook/designate-2025.1": "registry.yaook.cloud/yaook/designate-2025.1:1.0.29", "registry.yaook.cloud/yaook/designate-2025.2": "registry.yaook.cloud/yaook/designate-2025.2:1.0.29", "registry.yaook.cloud/yaook/designate-2026.1": "registry.yaook.cloud/yaook/designate-2026.1:1.0.29" }| More info can be found in our security advisory[1]. Regards Stefan [1] https://yaook.cloud/security-advisories-cve-2026-71193-71194/ [2] https://gitlab.com/yaook-security/images/designate/-/pipelines/2746847469 [3] https://docs.yaook.cloud/user/references/env-reference.html#envvar-YAOOK_OP… -- Stefan Hoffmann DevOps Engineer Cloud&Heat Technologies GmbH Königsbrücker Straße 96 | 01099 Dresden +49 351 479 367 36 stefan.hoffmann(a)cloudandheat.com |www.cloudandheat.com Green, Open, Efficient. Ihr Cloud-Service- und Cloud-Technologie-Provider aus Dresden. https://www.cloudandheat.com/ Commercial Register: District Court Dresden Register Number: HRB 30549 VAT ID No.: DE281093504 Managing Director: Nicolas Röhrs Authorized signatory: Dr. Marius Feldmann

Aug. 11, 2026

Re: [Announce] [Security Advisory][neutron] CVE-2026-55707

by Stefan Hoffmann

A small correction: you need to update the Neutron operator, not Keystone. On 7/29/26 17:03, Stefan Hoffmann via Announce wrote: > Hi Yaook users, > > OpenStack published a CVE for neutron. > > Tim Shephard reported that a project member can use PUT > /v2.0/subnetpools/{id}/onboard_network_subnets to onboard subnets from > another project's shared network into the caller's own subnetpool. The > API only checks that the supplied network_id is visible to the caller. > If the network is RBAC or globally shared, the check passes, and > Neutron updates every matching subnet on that network to use the > caller-controlled subnetpool. If the caller's subnetpool is associated > with an address scope, the victim router interface is synced with the > attacker-controlled address scope. > > This lets a shared-network consumer mutate another project's > persistent subnet state and alter L3 routing, NAT, and address-scope > behavior for victim routers. > > The following images are vulnerable: > neutron images before 1.0.206 > yaook release before 3.1.1 > If this image is used in your cluster for the neutron-api deployment, > the cluster is vulnerable. > The fixed image has been built in a private pipeline[2] which has been > published alongside this advisory[1] to prove the image provenance. > > We recommend to immediately add a YAOOK_OP_VERSIONS_OVERRIDE[3] > variable to your Keystone operator container to pull the image before > the YAOOK comprehensive release is ready. > > operator: > extraEnv: > - name: YAOOK_OP_VERSIONS_OVERRIDE > value: | > { > "registry.yaook.cloud/yaook/neutron-2023.2": > "registry.yaook.cloud/yaook/neutron-2023.2:1.0.206", > "registry.yaook.cloud/yaook/neutron-2024.1": > "registry.yaook.cloud/yaook/neutron-2024.1:1.0.206", > "registry.yaook.cloud/yaook/neutron-2024.2": > "registry.yaook.cloud/yaook/neutron-2024.2:1.0.206", > "registry.yaook.cloud/yaook/neutron-2025.1": > "registry.yaook.cloud/yaook/neutron-2025.1:1.0.206", > "registry.yaook.cloud/yaook/neutron-2025.2": > "registry.yaook.cloud/yaook/neutron-2025.2:1.0.206", > "registry.yaook.cloud/yaook/neutron-2026.1": > "registry.yaook.cloud/yaook/neutron-2026.1:1.0.206" > } > > More info can be found in our security advisory[1]. > > Regards > Stefan > > [1] https://yaook.cloud/security-advisories-cve-2026-55707/ > [2] > https://gitlab.com/yaook-security/images/neutron/-/pipelines/2699882611 > [3] > https://docs.yaook.cloud/user/references/env-reference.html#envvar-YAOOK_OP… > > > _______________________________________________ > Announce mailing list -- announce(a)lists.alasca.cloud > To unsubscribe send an email to announce-leave(a)lists.alasca.cloud -- Stefan Hoffmann DevOps Engineer Cloud&Heat Technologies GmbH Königsbrücker Straße 96 | 01099 Dresden +49 351 479 367 36 stefan.hoffmann(a)cloudandheat.com | www.cloudandheat.com Green, Open, Efficient. Ihr Cloud-Service- und Cloud-Technologie-Provider aus Dresden. https://www.cloudandheat.com/ Commercial Register: District Court Dresden Register Number: HRB 30549 VAT ID No.: DE281093504 Managing Director: Nicolas Röhrs Authorized signatory: Dr. Marius Feldmann

July 30, 2026

[Security Advisory][neutron] CVE-2026-55707

by Stefan Hoffmann

Hi Yaook users, OpenStack published a CVE for neutron. Tim Shephard reported that a project member can use PUT /v2.0/subnetpools/{id}/onboard_network_subnets to onboard subnets from another project's shared network into the caller's own subnetpool. The API only checks that the supplied network_id is visible to the caller. If the network is RBAC or globally shared, the check passes, and Neutron updates every matching subnet on that network to use the caller-controlled subnetpool. If the caller's subnetpool is associated with an address scope, the victim router interface is synced with the attacker-controlled address scope. This lets a shared-network consumer mutate another project's persistent subnet state and alter L3 routing, NAT, and address-scope behavior for victim routers. The following images are vulnerable: neutron images before 1.0.206 yaook release before 3.1.1 If this image is used in your cluster for the neutron-api deployment, the cluster is vulnerable. The fixed image has been built in a private pipeline[2] which has been published alongside this advisory[1] to prove the image provenance. We recommend to immediately add a YAOOK_OP_VERSIONS_OVERRIDE[3] variable to your Keystone operator container to pull the image before the YAOOK comprehensive release is ready. operator: extraEnv: - name: YAOOK_OP_VERSIONS_OVERRIDE value: | { "registry.yaook.cloud/yaook/neutron-2023.2": "registry.yaook.cloud/yaook/neutron-2023.2:1.0.206", "registry.yaook.cloud/yaook/neutron-2024.1": "registry.yaook.cloud/yaook/neutron-2024.1:1.0.206", "registry.yaook.cloud/yaook/neutron-2024.2": "registry.yaook.cloud/yaook/neutron-2024.2:1.0.206", "registry.yaook.cloud/yaook/neutron-2025.1": "registry.yaook.cloud/yaook/neutron-2025.1:1.0.206", "registry.yaook.cloud/yaook/neutron-2025.2": "registry.yaook.cloud/yaook/neutron-2025.2:1.0.206", "registry.yaook.cloud/yaook/neutron-2026.1": "registry.yaook.cloud/yaook/neutron-2026.1:1.0.206" } More info can be found in our security advisory[1]. Regards Stefan [1] https://yaook.cloud/security-advisories-cve-2026-55707/ [2] https://gitlab.com/yaook-security/images/neutron/-/pipelines/2699882611 [3] https://docs.yaook.cloud/user/references/env-reference.html#envvar-YAOOK_OP… -- Stefan Hoffmann DevOps Engineer Cloud&Heat Technologies GmbH Königsbrücker Straße 96 | 01099 Dresden +49 351 479 367 36 stefan.hoffmann(a)cloudandheat.com | www.cloudandheat.com Green, Open, Efficient. Ihr Cloud-Service- und Cloud-Technologie-Provider aus Dresden. https://www.cloudandheat.com/ Commercial Register: District Court Dresden Register Number: HRB 30549 VAT ID No.: DE281093504 Managing Director: Nicolas Röhrs Authorized signatory: Dr. Marius Feldmann

July 29, 2026

[Security Advisory][nova] CVE-2026-46448

by Stefan Hoffmann

Hi yaook users, yesterday OpenStack published a security advisory for nova. 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. The following images are vulnerable: nova images before 1.1.141 yaook release before 2.3.2 Hints on upgrading are written at our security advisory[1] Best regards Stefan [1] https://yaook.cloud/security-advisories-cve-2026-46448/ -- Stefan Hoffmann DevOps Engineer Cloud&Heat Technologies GmbH Königsbrücker Straße 96 | 01099 Dresden +49 351 479 367 36 stefan.hoffmann(a)cloudandheat.com | www.cloudandheat.com Green, Open, Efficient. Ihr Cloud-Service- und Cloud-Technologie-Provider aus Dresden. https://www.cloudandheat.com/ Commercial Register: District Court Dresden Register Number: HRB 30549 VAT ID No.: DE281093504 Managing Director: Nicolas Röhrs Authorized signatory: Dr. Marius Feldmann

June 17, 2026